Raspberry Pi Ltd 在 LSE 上市了,代碼 RPI:「Raspberry Pi IPO」。
LSE 上的資料在「RASPBERRY PI HOLDINGS PLC」這邊,但這網頁開的速度... 有點... 感人?
上市後公司的走向通常都會有不少變化,接著看看 Raspberry Pi 6 的計畫吧?雖然 N100 的實用度會更好...
幹壞事是進步最大的原動力
Raspberry Pi Ltd 在 LSE 上市了,代碼 RPI:「Raspberry Pi IPO」。
LSE 上的資料在「RASPBERRY PI HOLDINGS PLC」這邊,但這網頁開的速度... 有點... 感人?
上市後公司的走向通常都會有不少變化,接著看看 Raspberry Pi 6 的計畫吧?雖然 N100 的實用度會更好...
先前在「Cloudflare 的 Email Routing 功能可以讓一般人用 (包括免費帳號)」這邊有提到,因為 Google Workspace 要廢掉免費版本,所以 Cloudflare 推出了 E-mail forwarding 的方案讓大家用,所以一種簡單的解決方法就是註冊另外一個免費的 Gmail 帳號,然後用 Cloudflare 把信件 forward 到新的帳號裡。
但如果想要避開 Google 的服務的話,在 Hacker News 上的「Ask HN: Best hosted alternative to Google Workspace for email?」這邊就有討論不少可能的替代方案,主要是付費的為主。
討論裡常被提起的方案:
我自己是很愛 Fastmail,他的 webmail 界面速度很快 (即使 www.fastmail.com 需要連到美國的伺服氣上),而且鍵盤快速鍵與 Gmail 幾乎相同,所以學習成本很低,就把其中一個 domain 掛上去用,然後把一些服務的註冊 email 都往這邊掛。
而費用的部份,除了可以月繳外,年繳與三年繳都有另外再給 discount (30GB 版本是 US$5/mo、US$50/y 與 US$140/3y),第一次用一年後,後面就是刷三年了...
如果有在用 Office 的話,Microsoft 365 應該也是個選擇方案,不過我對 Outlook 的 folder-based 的設計邏輯用不慣...
然後是 iCloud+,看討論裡面提到穩定度似乎不太行,但也有人用的好好的,我自己是只有拿來同步 Apple 裝置用,沒有用到郵件服務的部份...
另外是自己有架設 Email service,話說這年頭自己搞 Email system 超麻煩的,對於沒搞過的人 SPF 與 DKIM 加上 DMARC 絕對會搞死自己,乖乖丟雲端服務比較省事,我純粹是要保持多路暢通而已...
在 TorrentFreak 上看到 15 年前的 torrent,現在還活著:「World’s Oldest Torrent Still Alive After 15 Years」。
當年一開始出來的時候還是有 tracker 架構,不是完全的 p2p,但即使如此,對於當時檔案傳輸的幫助超大。現在在 bootstrap 後 (像是抓個前面提到的 fan-made torrent) 就可以靠 Peer exchange 與 DHT 達到 tracker-less 了。
而在遊戲界領域裡,Blizzard 也曾經採用了這個方式提供 patch 以降低伺服器端的頻寬壓力。不過後來好像是靠 CDN,就不用 P2P 的方式了?畢竟後來 CDN 競爭激烈不少,這類靜態檔案下載的技術大家都很成熟,對於有量的公司可以直接談個還不錯的價錢,而 P2P 還是有可能會受到干擾,走 HTTP (以及後來的 HTTPS) 還是遊戲公司的首選。
算是網路歷史上少數真正分散式的架構... 不會受到 vendor 喊停就不見。
Amazon 的其中一個辦公室拿隔壁 data center 的廢熱借來當自己辦公室的空調:「Amazon to use data centre waste heat to warm corporate offices」,原始報導在「The super-efficient heat source hidden below Amazon's Seattle headquarters」。除了嘗試省電省成本以外,對企業形象也比較好...
隔壁 Westin Building Exchange 的地址是「2001 6th Ave #300, Seattle, WA 98121」,辦公室則是在「2040 6th Ave, Seattle, WA 98121」,無論是從地址上看,或是 Google Maps 上可以看,都可以看出來兩棟就在旁邊而已,拉管線就簡單很多了。
預定二十五年省 80M 度電,所以一年大約是 3.2M 度,以「Seattle, WA Electricity Rates | Electricity Local」這邊給的數字來算,商業用店每度是 USD$0.068,每年大約省下 USD$217,600 (所以每年大約可以省下台幣六百萬),以 3800 人的辦公室來說其實有點微妙,不過以 PR 的角度還看其實就很划算了 XDDD:
It is expected, over the course of 25 years, to save approximately 80 million kWh of electricity use by Amazon.
不知道這套系統花多少錢...
最近在 The Workplace Stack Exchange 上還蠻火紅的一篇文章:「Is it unethical for me to not tell my employer I’ve automated my job?」。
作者的全職工作是從系統上抓資料出來,貼到 spreadsheet 上 (也許是 Excel?),這份工作的薪資還不錯,然後作者寫程式自動化掉後發現他每禮拜只需要做一兩個小時了:
There might be amendments to the spec and corresponding though email etc, but overall, I spend probably 1-2 hours per week on my job for which I am getting a full time wage.
然後在糾結要不要跟雇主講,跑上來發文 XDDD 有興趣的人可以去圍觀看一看下面的回應...
從紐約時報看到今年的 Turing Award 由 Whitfield Diffie 與 Martin E. Hellman 獲得:「Cryptography Pioneers Win Turing Award」。在 Turing Award 官網上也可以看到對應的說明。
Diffie–Hellman key exchange 是全世界第一個 (1976 年) 在公開頻道上建立 shared secret 的演算法,直到現在都還廣泛的被使用,可以防禦被動式的監聽攻擊:
The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel.
現在這個演算法用在 PFS (Perfect forward secrecy),或稱為 FS (Forward secrecy),確保 public key 被破解前的連線記錄不會輕易被破解,於是更確保了資料的安全性:
a secure communication protocol is said to have forward secrecy if compromise of long-term keys does not compromise past session keys.
後來這個演算法也被延用到 Elliptic curve 上,也就是 ECDH,因為不使用 或 (field) 而是使用 Elliptic curve (group),而大幅降低了可被拿來攻擊的特性,而使得 key 的長度可以比 RSA 小很多。
上一個因密碼學拿到 Turing Award 的是 2012 年得獎的 Silvio Micali 與 Shafi Goldwasser,他們所音發展出來的用以對密碼系統驗證的數學方法而得獎。
而更有名的應該是 2002 年 Ronald L. Rivest、Adi Shamir、Leonard M. Adleman 因為 RSA 演算法而得獎的事情。
在愈來愈多新聞揭露安全與隱私問題後 (尤其是政府對人民的監控),密碼學愈來愈被重視。之前在密碼學領域做出重大貢獻的人也陸陸續續得獎...
跑 openssl speed ecdh
的時候發現很特別的現象:
Doing 160 bit ecdh's for 10s: 40865 160-bit ECDH ops in 9.99s Doing 192 bit ecdh's for 10s: 34169 192-bit ECDH ops in 9.99s Doing 224 bit ecdh's for 10s: 60980 224-bit ECDH ops in 9.99s Doing 256 bit ecdh's for 10s: 34298 256-bit ECDH ops in 10.00s Doing 384 bit ecdh's for 10s: 9602 384-bit ECDH ops in 10.00s Doing 521 bit ecdh's for 10s: 9127 521-bit ECDH ops in 9.99s
原因是 Google 這篇論文的貢獻:「Fast Elliptic Curve Cryptography in OpenSSL」,開頭就提到:
We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224.
而實際成果:
full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster.
在 OpenSSL 的 CHANGES 也可以看到對應的修改,不只是 NIST-P224 有被改善,其他的 NIST-P256 與 NIST-P521 也都有被改善:
Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs.
頗特別的...
寫這篇順便測試 MathJax 的效果...
因為 NSA 的惡搞,這陣子 PFS (Perfect Forward Secrecy) 突然被拿出來討論:
在講 PFS 前,得先講 Diffie-Hellman key exchange (D-H)。
D-H 是利用這個等式:
$$(g^a)^b \equiv (g^b)^a \mod p$$
其中 \(p\) 是大質數,而 \(g\) 是 \(p\) 的 primitive root (即不存在任何 \(n < p\) 可以使得 \(g^n \equiv 1 \mod p\))。 而因為當 \(p\) 夠大時,要從 \(g^a \mod p\) 計算 \(a\) 就是離散對數問題,而離散對數問題是已知沒有有效率計算的問題,所以我們會假定當 \(p\) 夠大時,傳輸 \(g^a \mod p\) 是無法用合理資源計算得知 \(a\)。
因此,Alice 與 Bob 就可以產生自己的 private secret \(a\) (Alice) 與 \(b\) (Bob),計算出 \(g^a\) 與 \(g^b\) 後公開傳輸給對方,當 Bob 收到 Alice 提供的 \(g^a\) 時就計算 \((g^a)^b \equiv g^{ab} \mod n\),而 Alice 收到 Bob 提供的 \(g^b\) 後可以計算 \((g^b)^a \equiv g^{ba} \equiv g^{ab} \mod n\)。
而攻擊者只拿到公開的 \(g^a\) 與 \(g^b\) 以及 \(g\),無法計算出 \(g^{ab}\),於是就雙方就建立一組 shared secret 了。
回到 SSL/TLS 的問題上,由於 RSA 加解密的速度並不快,所以 SSL/TLS 是在 RSA 的保護下交換 RC4 或是 AES 所需要的金鑰 (key)。
交換 key 這件事情除了可以直接交換以外,還可以利用 D-H 交換。
D-H 交換可以確保當 RSA key 被破解時還要再破每個 session 的 D-H 所產生出來的 key,而直接交換的話,只要破一把 RSA key 就可以解出所有 traffic 了。
而 PFS 會被提出來,是因為目前消息指出 NSA 其實有在錄下 SSL/TLS 流量,等哪天有機會取得 RSA key 的時候 (無論是硬解,或是其他方式),就有機會能夠一次破一卡車資料... (因為目前大部分的 SSL/TLS 流量都沒有上 PFS)
雖然 PFS 會慢一些,不過已經確認 NSA 打算來搞了,所以還是乖乖加上去吧... @_@
28.993 ... murmur.tw/jnlin/5078149
— Jui-Nan Lin (@jnlin) January 3, 2013
這數字看起來跟匯率有關,跑去查 1USD 果然是講這個數字:
突破 29 了啊...
Google 的 OpenID 服務有提供 OpenID Attribute Exchange 1.0 (參考「Federated Login for Google Account Users」這個網頁), 測了一陣子才知道要怎麼透過 Perl 的 Net::OpenID::Consumer 取得資料:
my $csr = Net::OpenID::Consumer->new( ua => LWPx::ParanoidAgent->new, args => {}, consumer_secret => 'secret', required_root => 'http://.../', minimum_version => 2 ); my $claimed_identity = $csr->claimed_identity('https://www.google.com/accounts/o8/id'); $claimed_identity->set_extension_args( 'http://openid.net/srv/ax/1.0', { mode => 'fetch_request', required => 'email', 'type.email' => 'http://axschema.org/contact/email', } ); my $check_url = $claimed_identity->check_url( delayed_return => 1, return_to => 'http://.../...', trust_root => 'http://.../' ); say $check_url;
之前會試不出來,主要是卡在 type.email
忘記加,加上去的時候又打成 email
...