推 yehzu:推Q_Q 05/28 23:59
推 ahpc82:推concise 05/29 00:00
推 steve1012:猛~ 05/29 00:03
推 KbearXD:推憲鍋~~~ 05/29 00:05
推 r67842007:快推～不然人家以為我們看不懂～（雖然真的不懂ＱＱＱ 05/29 00:05
推 pml0415:推concise 05/29 00:05
推 MIKEmike07:推這篇 05/29 00:06
推 jttte:推!!! 05/29 00:07
推 tony79:憲哥!! 05/29 00:07
推 cocolab:推! 跪惹 05/29 00:10
推 gj942l41l4:跪了 05/29 00:10
推 strike5566:推 05/29 00:10
推 obrightness:大概看一下就看出這麼多了XD 05/29 00:12
推 ccwang002:猛~~ 05/29 00:13
推 ga800360:先給跪了 05/29 00:14
推 MrOrz:推 vulnerability，也推最後結論! 05/29 00:15
推 terrence000:hello world~ 05/29 00:16
推 alon21034:推結論! 05/29 00:17
推 albertkingdo:憲哥! 05/29 00:17
推 ts00834811:猛 05/29 00:18
推 yanshencun:大推餡鍋~ 05/29 00:18
推 qcl:推！ 05/29 00:18
推 seanlatias:跪著推文啊~~ 05/29 00:23
推 hanmicky36:concise.js 05/29 00:27
推 b2power: 05/29 00:28
推 LCR918:憲哥大猛 05/29 00:31
推 Murasaki0110:已跪 05/29 00:35
推 kn930121:剛我室友問我為什麼跪著用PTT 05/29 00:35
推 moonlitebony:憲鍋~~~~! 05/29 00:35
推 summitstudio:專業好文推～ 05/29 00:37
推 Faraday:朝聖大神 05/29 00:45
推 XDucka:已跪 05/29 00:46
推 shepinkgirl:餡鍋~~~~~~~~~~~~~ 05/29 00:51
推 bosszshsieh:推 05/29 00:58
推 sammon:推 05/29 01:00
推 jim1029:推 05/29 01:06
推 joel1211:已跪 05/29 01:07
→ tbbhwinh:RSC大大說的沒問題跑哪去了?? 05/29 01:13
推 ouyipee:推 05/29 01:14
推 TGPP:推推 05/29 01:14
推 henry1915:快推啊 但是真的看不懂QAQ 05/29 01:15
推 doomhydra:推 05/29 01:16
推 Ofianse:開放出來 大家都會幫忙 05/29 01:33
沒錯，如果沒有 open source 的話，各種問題就更難被修正。
這種嚴肅的大工程最需要一些有志之士聚集起來檢視、討論、協同開發。
推 RPedsel:應該不是不知道問題 但在資源時間各種有限下生不出來... 05/29 01:33
這就是我覺得主要問題之 3. 「開發可能沒有得到足夠多人的協助...」 T__T
推 tbbhwinh:時間當然有限，因為選前一個月迅速通過(遠望 05/29 01:36
※ 編輯: concise (140.112.30.44), 05/29/2014 01:41:22
推 benck: 05/29 01:53
推 donkilu:一個月真的太短了，況且真正進行好像才十天 05/29 01:55
推 donkilu:這比台灣公司的慣老闆還慘... 05/29 01:57
推 zenixls2:把決策到發包過程都PO出來讓大家檢視嘛 05/29 01:58
推 han960691:了解到詳情後說聲抱歉 時間不夠作不出好產品身有同感0rz 05/29 01:59
→ han960691:開發者讓大家一起協作創造出更好的民主參與模式吧! 05/29 02:00
推 donkilu:開發時間短的不可思議，工程師非戰之罪，決策者則應該道歉 05/29 02:04
→ zenixls2:學弟，搞不好你在fb上面招兵買馬一下能有更多人幫忙 05/29 02:07
推 suhorng:恩, 十天要生出來... 05/29 02:20
→ breeze4103:已下跪 太神啦 05/29 02:32
推 patrick0606:推專業~ 突然想馬上學pho了QAQ 05/29 03:52
→ patrick0606:是php.....手機輸入法不要賣萌>< 05/29 03:53
若是剛開始接觸 programming ，希望學習之路愉悅一點，隆重向您推薦 Python 小蟒蛇。
當然，如果就是想成為硬底子 hacker ，那就不需要任何 preferences 了XD 不管是從
python, js, ruby, php, perl, bash 還是 java/c#, c/c++, obj-c 抑或 lisp, haskell
開始，選誰來學習都可以。
※ 編輯: concise (140.112.30.44), 05/29/2014 04:12:28
推 larikl:朝聖！ 05/29 04:52
推 nmlw:推！ 05/29 08:02
推 radar735:朝聖推ORZ 05/29 08:29
推 RSChiang:推Python (yay) 05/29 10:20
推 sillusnowolf:朝聖QQ 05/29 10:27
推 jacky7987:推推 幫推PythonXD 05/29 10:32
推 EGOPLANA:1 2 5 看不懂推XDD 05/29 10:33
推 yangwen5301:為什麼不設個投票機採封閉式網路？ 05/29 11:10
→ yangwen5301:這樣也不用花大量時間在網際網路安全上 05/29 11:13
→ yangwen5301:唯一對外窗口是計中學生資料庫，刷學生證領票 05/29 11:15
合情合理的「電子投票」絕對不能完全只在封閉網路內運行，這樣子就是徹底的黑箱了。
一定要是經過仔細設計、實作，將可驗証性、安全性等重要條件都達成，並且在開放的
網路上可以被存取才行。
※ 編輯: concise (140.112.30.44), 05/29/2014 11:26:18
推 butterfly21:朝聖推<(_ _)> 05/29 11:40
推 wheels:無限期支持開放github給大家改 05/29 12:06
推 kuoly1:朝聖跪 這太BN了 05/29 12:48
→ yangwen5301:封閉網路不等於黑箱，駭客外有駭客 05/29 13:26
→ yangwen5301:因為你設計一套系統，除非程式碼開源，但你也無法證明 05/29 13:37
→ yangwen5301:你灌的城市是同一支，同時間你也僅僅將你想公佈的部分 05/29 13:38
→ yangwen5301:透過網際網路傳給大眾，我如果要證明程式沒問題 05/29 13:39
→ yangwen5301:那如果我要證明沒問題，我不是要入侵伺服檢查？ 05/29 13:39
→ yangwen5301:那跟我把程式碼開源，采封閉式網路防駭不是更好？ 05/29 13:41
→ yangwen5301:你同時要強調連網安全性，又要證明自己的程式是公平的 05/29 13:47
→ yangwen5301:這中間有點矛盾啊 05/29 13:47
你好，我覺得你的邏輯比較混亂。
也許你誤會了密碼學者對於真正的「電子投票」的定義。
最核心的關鍵不在於軟體，軟體是為了人的便利而生的。
電子投票的核心是密碼學家們提出的包含各種協議、利用公鑰密碼技術作數位簽章的
Protocols（我們 5/28 完全沒有看到這些東西），而不在於軟體本身。那樣的 Protocol
經過數學證明出來的的強屬性（例如可以抵擋 A 攻擊、可以抵擋 B 攻擊，可以提供 C
可驗證性、可以提供 D 使用者隱私特性）是基於定義清楚明確的 threat model 下
的嚴格推導，而不是隨隨便便定性的描述。一個協議的公平性是可以被證明的。
當我們所有人決定好今天的投票要採取什麼協議以後，
此時軟體實作才會開始，軟體實作的價值在於它提供人們一個方便的 interface。
其實呢，就算沒有軟體，我們人類也可以紙筆計算操作 public-key cryptosystem
內的算術。在一些最基本的前提（亂數產生是夠亂的、人們可以確定 authority 的
public key 的正確性、etc）都達成之下，就算使用 insecure communication channel
也沒有問題。而且就算其他人用了擅自亂修改的軟體，因為數學上的限制，使他想要
作弊也無法。
電子投票的核心就是應該這樣子。
你必須要將安全性拆解成很多元件，每一個小元件對他們考慮合宜的 threat model
並且作嚴格的安全分析。
而我要強調的並不是網路到底是開放式的還是封閉式的，
我要指出的是一個「可信的」「電子投票」根本就不可能是「黑箱操作」所能達成的。
一個安全的 protocol 是由 N 方共同協議的，這樣子他才有可能有 trust 。
如果一個系統的執行方式、使用者的操作機器完全都由「某一方」所掌握，
這樣子的系統是絕對沒有可信度的。
舉例來說，我們常常使用 ATM 提款機、悠遊卡儲值這一類的系統，
雖然這樣子的系統絕大部分都是在「黑箱」內，但是人們還是有可以掌握的部分：
你手上的晶片卡的密碼學運算是可以由你掌控的。（你可以把晶片磨開、可以對他送
request 觀察他的 behavior 是否如 "open" 的 protocol 所定義的那樣子。
這件事情不能證明？這件事情普通人做不到？不，這件事情很多專家在做，
你可以請他們幫你做，或者多花點小錢買讀卡機上網下載一些 open-source project
來測試） 這樣子的系統就不是我所說的「徹底的黑箱」。
又舉例來說，最傳統的「紙張」投票方式，也並不全然是黑箱，
他的 trust 是基於彌封、開票過程，多人一起監督檢視的。
如果存在一個荒謬的選舉投票流程，是連彌封、開票的監督，
都不允許有其他單位介入，那就是我所謂的「徹底的黑箱」。
總而言之，如果一個協議，沒有密碼學的安全性證明 support 它，
或者使用者根本沒有可以掌握的部分，那樣的「徹底的黑箱」世界，
什麼東西都不可信，就會如 Richard Stallman 先生所說的，電子投票不可能成立。
而關於駭客的問題，這就是我這一篇文章開頭就擺上 vimeo 影片的原因了
千萬不要以為只在封閉網路內運行的系統，就不會被 attacker 盯上。（
像是投票系統，選民觸碰平板的那幾秒鐘，他就在「封閉網路」內了，如果
選民就是惡意的攻擊者，怎麼辦？）
就算是完全「徹底黑箱」的系統，只在封閉的網路內運行，還是可以被駭客入侵的。
歷史告訴我們這類事情的發生，是無關 open-source 、也無關 open protocol 的，
有太多例子不勝枚舉，不要以為 close-source 或者 private cloud 就可以擋住駭客。
這些安全性問題引爆的嚴重程度，永遠只受限於攻擊者的想像力。
※ 編輯: concise (140.112.30.44), 05/29/2014 14:58:02
※ 編輯: concise (140.112.30.44), 05/29/2014 15:00:31
推 shaform:同意這篇的看法，應該要使用密碼學的方法做出可以由 05/29 15:04
→ shaform:第三方證明投票的公正性 05/29 15:04
→ shaform:而就算整個伺服器上跑的程式都被替換成作弊程式 05/29 15:06
→ shaform:也會因為數學上的特性以致於會被發現程式做出造假的結果 05/29 15:06
→ shaform:當然前提是整個密碼系統沒有被破解 05/29 15:06
→ shaform:而因為以上的事情不太可能由一個廠商在10天內作到 05/29 15:07
推 yehzu:大推補充 05/29 15:13
推 lan1994:推密碼學，並相信以後台大有能力做出完整的投票系統 05/29 16:26
→ marrvosal:你第4點後面寫的應是網路投票而非單純的電子投票了 05/29 16:29
→ marrvosal:網路投票方面有其許多困難處 05/29 16:29
→ marrvosal:雖然他主要是做在紙本投票上面 05/29 16:32
→ shaform:這個設計是就算投票機本身作弊都會被檢查出來 05/29 16:35
→ shaform:不過以上兩個和其他的設計適不適用可能還是得由相關領域 05/29 16:36
→ shaform:專家現身說法 05/29 16:36
→ marrvosal:以上設計拿來套用最大的問題是可能沒有什麼人想去驗證 05/29 16:42
→ marrvosal:任何系統都會遇到這個問題 05/29 16:43
推 audreytang:掛在現有的 blockchain 系統上，也是協助驗證的方式， 05/29 18:22
→ audreytang:之前參與的 LiquidFeedback 團隊正著手移植到 bitcoin 05/29 18:23
→ audreytang:網路上，另外 Ethereum / BitCongress 也可參考，至少 05/29 18:23
→ audreytang:可以分擔一部份的驗證功能，不用全靠中央式的信任。 05/29 18:24
→ yangwen5301:感謝你的說明，其實就我所學的我會認為信任密碼學，不 05/29 19:58
→ yangwen5301:如直接從硬體上做限制，我是不太信任軟體的人，最好投 05/29 19:58
→ yangwen5301:票機使用的語言越簡單越好 05/29 19:59
→ yangwen5301:而且如果要從信任開始講起，在採用任何形式的投票時後 05/29 20:01
→ yangwen5301:就先要找到第三方可信任的公證單位，無關乎程式型態 05/29 20:01
→ yangwen5301:就像沒有wifi沒組的電腦絕對不能無線上網一樣，架構簡 05/29 20:04
推 shaform:其實密碼學就是想解決如果軟體、硬體、官方都無法信任 05/29 20:04
→ yangwen5301:單，變因也越少，要去多考慮的部分也越少 05/29 20:04
→ shaform:的時候該怎麼辦，所以才需要用數學證明在邏輯上 05/29 20:04
→ shaform:如果有任何人做弊（投票機自己作弊、官方作弊、駭客作弊 05/29 20:05
→ shaform:會被檢查出來 05/29 20:05
→ yangwen5301:抱歉，講錯，不是密碼學是軟體的安全金鑰 05/29 20:07
→ shaform:當然實際上也只能作到把有任何人成功作弊的機率減小 05/29 20:07
→ shaform:只信任硬體的缺點就在於如果公正單位本身作弊，毫無牽制 05/29 20:08
→ shaform:的方法 05/29 20:08
→ yangwen5301:摁，看來我誤會原PO的意思了，他應該是想強調如何舉辦 05/29 20:10
→ yangwen5301:一個公正且成立的電子投票系統，我想說的是就電子投票 05/29 20:11
→ yangwen5301:系統，有更加方便且較為容易掌控狀況的選擇，至於要討 05/29 20:12
→ yangwen5301:論到單位本身舞弊，或是不公正，傳統投票也會有其問題 05/29 20:12
→ yangwen5301:另外我想說的是，就同樣是網際網路以及區網，駭客在破 05/29 20:15
→ yangwen5301:解上難度絕對有差，假設同樣的安全系統一個在開放環境 05/29 20:15
→ yangwen5301:下，他可以再任意地方連線操作，但是區域網路他必須要 05/29 20:16
→ yangwen5301:到機器上操作，就被破解的機率本身就減少許多了 05/29 20:16
yangwen5301 您好，謝謝你不吝於提供多方面的看法、討論。
關於「網路開放性」會對「安全程度」直接造成程度上的影響，你的看法是完全正確的。
如果，
存在有兩個系統，一個擺在開放網路上，一個擺在特定區域網路內，
他們能夠提供「相同的功能」，而且「理論上」他們「同樣安全」。
那麼，我們絕對就應該採用後者、區域網路內的那一個系統，
因為它的 attacking surfaces 較少。
然而一個合理的電子投票系統，終究要有一些 public API ，這些必定要讓大家可以
access 的 endpoints 就要愈簡單明瞭愈好。如你所說的，程式語言應撰寫得簡單易讀。
而且這種 public API 處，只要是會接受 input data ，就該嚴格地過濾、審視才行。
而其他只跟 server 有關的內部運算，當然就應該全面地只允許內網的存取，根本就
不必、也不應該公開。這是 common sense。愈是減少一個系統 publicly accessible 的
那些使用者不需存取的部分，這個系統就愈不容易出包。
這時候就可以被問一個問題：
那為什麼電子投票系統的主辦方『終究要有一些 public API 』呢？
因為實務上，就是幾乎沒有「所有計算都在區網內完成」這樣子的「多方」可信賴系統。
此處的重點不是區網、或公網。重點是一個協議的完成需要許多步驟，
這些步驟不可以完全只由「某一方」（例如選舉主辦方）就可以做到。
我們至少還是要有別的「信賴的基礎」才行。
例如一張晶片卡上的密碼運算、或者電腦上數位簽章的生成。
這個額外的「信賴」，是不可以只用「他人的」計算平台就做到的。
舉例來說，現實世界最傳統的身份驗證也許是簽名加蓋章。
王小明拿起一張合約以後，必須要「由他自己」來完成「簽字」與「蓋章」，
接著才會把這一張紙放進這個 blackboxed system 內，讓它去做別的事情。
這個櫃檯、這個接口就是王小明作為使用者所需要的「public API」。
反過來說，王小明走到服務人員櫃檯處，只經過簡單地寒暄問暖，就由服務人員來
單方面地就能夠「代替他」產生『此人是王小明，王小明今天想要轉帳...』之斷言。
那這個系統就沒有 (不需要) 任何實質上的 public API 。只要它想要，這個官方
它什麼都可以自己單方面地就做到。今天我們簡易版的電子投票其實有點像是這樣。
→ yangwen5301:今天使用瀏覽器作為媒介，就還要連瀏覽器可能存在的漏 05/29 20:20
→ yangwen5301:洞加以考慮，有可能駭客根本不是從破解網站本身安全性 05/29 20:21
→ yangwen5301:下手，而是從瀏覽器的漏洞進入 05/29 20:21
你好，在嚴肅地密碼分析一個系統的安全性、在制定 threat model 時，就會把你提到的
『終端的軟硬體被 compromised/hijacked (到什麼程度) 時會對安全造成怎樣的影響？』
這個問題定清楚了。
我們應該要採取那些，就算一個使用者的終端裝置（作業系統、瀏覽器）被破解到某程度
也不會影響安全性的協定。
而且要注意的是，值得被考慮 threats 必須要合理，不能無限上綱而忽略了邏輯。
舉例來說，如果一個使用者的瀏覽器被置換了、或者一個裝置上的作業系統被 root 了，
那「這一個人」就已經沒救了，我們根本不需要考慮他個人投票到底還有沒有隱私、
還能不能正常地運行，因為他使用這台電腦不管做什麼事情，都可以被第三隻手操弄；
這就像是一個人想要向一個暗戀已久的女生告白， (人性就是想要上網
但是他性格太害羞，就找他的好朋友來幫忙傳話， (但因為人類無法讀懂電磁波/
電壓，所以就找電腦幫忙
他和這個女孩子之間所有的「通信」 (想要上網做任何事情
都是經由這位親切的好朋友之手。 (都經由這台電腦/瀏覽器
如果有一天，這個人不再是好朋友， (如果這電腦已經被植木馬...
那這個單相思的男孩是否能再與該女孩子建立良好的友誼，就已經不值得一談了。
我隨性亂想的比喻也許不適當，但是這應該勉強地有表達出那個意境。
推 tw0517tw:這個有趣 05/29 20:50
※ 編輯: concise (140.112.30.44), 05/29/2014 21:16:11
※ 編輯: concise (140.112.30.44), 05/29/2014 21:23:53
→ yangwen5301:像前幾周IE的安全性漏洞就不是因為遭置換，而是本身就 05/29 21:52
→ yangwen5301:有問題，導致你網站在怎麼安全都沒有用，而當時資安單 05/29 21:52
→ yangwen5301:位也只有告訴民眾先不要使用IE，因為他們僅知道有漏洞 05/29 21:52
→ yangwen5301:但不知道漏洞可以做麼 05/29 21:53
→ yangwen5301:另外謝謝您詳細的說明，在相關領域長知識了:) 05/29 21:53
→ yangwen5301:所以我會認為在投票點設置公正的投票機會比用網頁好上 05/29 22:00
→ yangwen5301:許多 05/29 22:00