Home » Posts tagged "channel" (Page 3)

對 ECDSA 實體非破壞性的 Side Channel 攻擊

用很簡單的設備透過 Side Channel 攻擊取得 ECDSA private key:「ECDSA Key Extraction from Mobile Devices via Nonintrusive Physical Side Channels」。這次 Side Channel 只需要簡單的線圈,透著一塊玻璃也 okay:

文章裡面提到是 Tracker Pre,查了一下二手價是 USD$80:

這邊抓出了 ADD 產生出的訊號:

然後就可以利用這些訊號重建出 private key:

After observing the elliptic-curve DOUBLE and ADD operations during a few thousand signatures, the secret signing key can be completely reconstructed.

下面中獎的 library 有點多,可以看到主要是以 constant-time implementation 或是 side-channel mitigation technique 來解這個問題。

2015 年的 Turing Award 由 Whitfield Diffie 與 Martin E. Hellman 獲得

紐約時報看到今年的 Turing AwardWhitfield DiffieMartin 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,因為不使用 Z_{2^p}Z_p (field) 而是使用 Elliptic curve (group),而大幅降低了可被拿來攻擊的特性,而使得 key 的長度可以比 RSA 小很多。

上一個因密碼學拿到 Turing Award 的是 2012 年得獎的 Silvio MicaliShafi Goldwasser,他們所音發展出來的用以對密碼系統驗證的數學方法而得獎。

而更有名的應該是 2002 年 Ronald L. RivestAdi ShamirLeonard M. Adleman 因為 RSA 演算法而得獎的事情。

在愈來愈多新聞揭露安全與隱私問題後 (尤其是政府對人民的監控),密碼學愈來愈被重視。之前在密碼學領域做出重大貢獻的人也陸陸續續得獎...

限制 WeeChat 中 buffers.pl 的寬度

WeeChat 上的 buffers.pl 是個很好用的套件,可以在側邊列出 channel,像是這樣:


其中一個特點是,左側的 channel list 會自動伸展到目前最長的 channel name。由於我用 WeeChat 連 Slack 提供的 IRC Gateway,加上最近提供多人交談的功能,就產生出這樣的 channel name:


解法是限制側邊的寬度,用 /set buffers.look.name_size_max 32 後再 /save 存起來就可以了。是在「[buffers.pl] name_size_max adding crop suffix too soon in certain cases」這邊找到的關鍵字。

Amazon 之前放出的 s2n 的安全性問題

Amazon 之前放 s2n 出來當作 TLS protocol 的方案,於是就有人摸出東西來:「Lucky Microseconds: A Timing Attack on Amazon's s2n Implementation of TLS」。

即使是經過外部資安檢證,仍然還是有找到問題。這次找到的問題是 timing attack 類在 CBC-mode 下的 plaintext recovery:

At the time of its release, Amazon announced that s2n had undergone three external security evaluations and penetration tests. We show that, despite this, s2n - as initially released - was vulnerable to a timing attack in the case of CBC-mode ciphersuites, which could be extended to complete plaintext recovery in some settings.


Our attack has two components. The first part is a novel variant of the Lucky 13 attack that works even though protections against Lucky 13 were implemented in s2n. The second part deals with the randomised delays that were put in place in s2n as an additional countermeasure to Lucky 13. Our work highlights the challenges of protecting implementations against sophisticated timing attacks.

最後還是酸了一下 Amazon:

It also illustrates that standard code audits are insufficient to uncover all cryptographic attack vectors.

Amazon 的官方說明則在「s2n and Lucky 13」這邊可以看到。

Slack 支援多人討論群組

Slack 宣佈支援多人討論群組了:「Group Messages Come to Slack」。之前要找一群人討論事情必須要開一個 Private Channel,但每次開 channel 都要想一個名字出來很討厭,後來都用 #test_201510290916 這種沒有意義的名字,而現在可以直接拉人進來了:

另外一個是跟著的改變:「Private Groups become Private Channels」。

With the introduction of group DMs, which will cover many of the use cases that previously required private groups, we’ve transformed private groups into the brand new “private channels”. Private channels will be shown mixed in with your existing open channels alphabetically, with small lock icons next to the private ones. When the time comes to create a new channel, you’ll find a new public/private toggle on the configuration screen.

原先的 Private Channel 就跟 Public Channel 混在一起了...

在 iOS 上不使用 Facebook App 時要完全砍掉 process

在「The Background Data and Battery Usage of Facebook’s iOS App」這邊提到 Facebook AppiOS 上使用了非常吃電的技巧來強制背景更新。

作者猜測,如果你把 Facebook App 設定成不允許背景更新,那麼 Facebook App 會利用 iOS 在「播放音樂」可以在背景執行來進行更新:(所以只是打開播放的 channel,但是沒有聲音)

My guess is that Facebook is hijacking audio sessions on iOS by keeping silent audio in the background whenever a video plays in the app. And because, by default, videos on Facebook auto-play on both Wi-Fi and Cellular and few people ever bother to turn it off, that means there's a high chance the Facebook app will always find a way to play a video, keep audio in the background, and consume energy to perform background tasks.


I'm not alone in noticing the mysterious "Facebook audio" background consumption, and video auto-play seems to me the most likely explanation at this point. I don't know if turning off auto-play may fix the problem, but I'd recommend doing that anyway to save data.

印象中我們家的 zonble 也有提過類似的事情,當時他好像還有抱怨不知道 Facebook App 在搞什麼鬼... Anyway,這就可以理解作者提到為什麼這麼吃電:

On my girlfriend's iPhone, for instance, iOS 9 reports 5 hours of on-screen usage for the last 7 days, and another 11 hours of background audio usage with Background App Refresh turned off.

我的想法是,如果不用的時候就按兩下 home 鍵把 Facebook App 整個踢出去,或者就如同作者建議用 Safari 開行動版本:

I wonder if Apple should consider additional battery controls to take action against shady practices like invisible background audio. What Facebook is doing shows a deep lack of respect for iOS users. I continue to recommend using Safari instead.

寄信到 Slack 裡的 Channel

Slack 的新功能,可以寄信到 Slack 的 Channel 裡:「Email, meet Slack. Slack, email.」。


Today we’re launching a new feature: all teams on the Standard or Plus plans can have email directed into Slack channels.



MILL:在 C 裡面實作 Go-style 的 concurrency

看到「Go-style concurrency in C」這個專案,在 C 上實作 Go-style 的 concurrency,包括了 channel 的設計。原始程式碼可以在 GitHub 上的「sustrik/mill」看到。

在「mill.c」可以看到實作細節,另外也可以看到 yield() 的設計。


This is a proof of concept project that seems to work with x86-64, gcc and Linux. I have no idea about different environments. Also, the project is in very early stage of development and not suitable for actual usage.

在瀏覽器上面用 JavaScript 進行 Side-channel attack

用 JavaScript 就可以攻擊 L3 cache,進而取得資料:「JavaScript CPU cache snooper tells crooks EVERYTHING you do online」。

論文出自「The Spy in the Sandbox – Practical Cache Attacks in Javascript」(PDF) 這篇。

不需要任何外掛或 exploit,就純粹是利用 cache 反應時間的 side-channel attack。另外由於 AMD 的 cache 架構不同,這次的攻擊實作僅對 Intel 有效:

The Intel cache micro-architecture isinclusive– all elements in the L1 cache must also exist in the L2 and L3 caches. Conversely, if a memory element is evicted fromthe L3 cache, it is also immediately evicted from the L2 and L1 cache. It should be noted that the AMD cachemicro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable tothat platform.