OpenSSH 8.4 預設停用 ssh-rsa

前幾天 OpenSSH 8.4 釋出了:「Announce: OpenSSH 8.4 released」。

比較重要的改變是 ssh-rsa 預設變成停用,因為是使用 SHA-1 演算法的關係:

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

官方給了三個方案:

  • The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.
  • The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5.
  • The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7.

掃了一下 ~/.ssh/known_hosts,看起來目前大多都是 ssh-ed25519 了,還有少數還是 ssh-rsa

翻了一下 Ubuntu 這邊的版本,16.04 是 7.2p2,看起來目前有支援的版本都可以用這三個。

官方有提到可以在 command 上強制關閉 ssh-rsa 測試的方法:

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

現在看起來比較麻煩的是 Dropbear 的部份,我自己之前是有包 PPA 來用 (2019.78),但看起來還是不夠新支援 ssh-ed25519 (要今年六月的 2020.79 才支援),所以也許要找時間來把 PPA 更新到 2020.80...

另外一種方法是走 ecdsa-sha2-nistp{256,384,521} 這些演算法,不過從名字就可以知道裡面演算法的由來,卡個 NIST 在那邊看起來就不太舒服,但還是寫一下方法好了:

先用 dropbearkey 產生對應的 ecdsa host key:

sudo dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key -s 256

再來在 /etc/default/dropbear 裡面把 DROPBEAR_EXTRA_ARGS 加上對應的 ecdsa host key 資訊,這邊直接用 -r 是因為他可以重複指定,不會影響到其他的 host key 設定:

# any additional arguments for Dropbear
DROPBEAR_EXTRA_ARGS="-r /etc/dropbear/dropbear_ecdsa_host_key"

然後重跑 dropbear 就可以了。

另外有興趣的人可以用 ssh -Q key 看 openssh client 支援的演算法。

NIST 對密碼學演算法建議的長度 (2020 版)

在「Comparing SSH Encryption Algorithms - RSA, DSA, ECDSA, or EdDSA?」這邊一路翻到「Keylength - NIST Report on Cryptographic Key Length and Cryptoperiod (2020)」這篇,裡面引用的是 NIST 的「NIST Special Publication 800-57 Part 1 Revision 5」。

在 NIST 的文件裡面,不同的演算法散落在不同地方,Keylength 整理起來後比較方便看。

想要特別拉出來講是因為看到 RSA 2048 bits 被放到 112 這個等級 (Security Strength),我一直以為是 128,不過查了一下發現好像以前是就 112 了...

AWS Site-to-Site VPN 支援 AES-GCM 了

AWS 更新了 Site-to-Site VPN:「AWS Site-to-Site VPN now supports additional encryption, integrity and key exchange algorithms」。

這次更新支援了一些新的演算法,其中 AES-GCM 的部份看起來是這次這波最重要的:

Encryption: AES128-GCM-16, AES256-GCM-16.
Integrity: SHA2-384, SHA2-512.
Diffie-Hellman groups: 19, 20, 21.

傳統的方式是 encryption algorithm + hash algorithm 搭配,所以就會出現各種排列組合,而不同的方式在實做上很容易出現安全問題,也就是這篇在討論的:「Should we MAC-then-encrypt or encrypt-then-MAC?」。

AEAD 試著用一包解決,對於實做的安全性好不少...

避開人臉辨識系統的演算法

Hacker News Daily 上看到的專案,針對現在很多演算法可以抓出照片上的人臉進行防禦:「Image "Cloaking" for Personal Privacy」。

這算是 Evasion 的應用,這個專案想要提供演算法,可以在照片上「隱形」,使得演算法偵測不到「人臉」,程式碼可以在 Shawn-Shan/fawkes 這邊翻到,可以看到是在 Python 上用 TensorFlowKeras 實做出來的。

不過會覺得比較有趣的反而不是裡面的方法,而是這篇論文的六個作者:

Shawn Shan†, PhD Student
Emily Wenger†, PhD Student
Jiayun Zhang, Visiting Student
Huiying Li, PhD Student
Haitao Zheng, Professor
Ben Y. Zhao, Professor

† Project co-leaders and co-first authors

從名字上來看五個是華人,而且一路搜下來會發現掛在最後一位的 Ben Y. Zhao 教授在 Quora 上常常回答問題,而且這些問題 (與回答) 還蠻有趣的,可以自己搜看看...

最近討論到的二分搜尋法...

應該是直接在 Hacker News 上看到的東西,有人丟出一個二分搜尋法實做,宣稱比標準實做快不少:「Binary Search: A new implementation that is up to 25% faster (github.com)」。

實做的程式碼放在 GitHub 的「scandum/binary_search」這邊,讀了 source code 後可以看到一臉就要利用現代 CPU 預測平行化的能力加速 XDDD

另外看了 Hacker News 上的討論,這種寫法會透過 CPU 預測平行化的能力善用記憶體頻寬,這應該是測起來比較快的主因。

不過這只算是個開頭,丟出一些方向讓社群可以研究,實際上還是得看看負面影響的部份,像是比較舊的 CPU 會不會有很重的 penalty (overhead),以及其他類型 CPU 上的情況...

Python 上的 OCR

這個 OCR 專案是在 Python 包好,讓你很快就可以上手用:「Easy OCR」。

從結果的 screenshot 可以看到輸出的內容很簡單,就是座標與 OCR 出來的內容:

然後支援的語言很多:

We are currently supporting following 42 languages.

Afrikaans (af), Azerbaijani (az), Bosnian (bs), Simplified Chinese (ch_sim), Traditional Chinese (ch_tra), Czech (cs), Welsh (cy), Danish (da), German (de), English (en), Spanish (es), Estonian (et), French (fr), Irish (ga), Croatian (hr), Hungarian (hu), Indonesian (id), Icelandic (is), Italian (it), Japanese (ja), Korean (ko), Kurdish (ku), Latin (la), Lithuanian (lt), Latvian (lv), Maori (mi), Malay (ms), Maltese (mt), Dutch (nl), Norwegian (no), Polish (pl), Portuguese (pt),Romanian (ro), Slovak (sk) (need revisit), Slovenian (sl), Albanian (sq), Swedish (sv),Swahili (sw), Thai (th), Tagalog (tl), Turkish (tr), Uzbek (uz), Vietnamese (vi)

有些參數可以調整,但預設值似乎就跑得不錯了...

處理很久前用 OpenSSL 加密的備份資料

因為想要翻一些舊的文章 (小說),想把以前 BBS 的備份拉出來看看裡面有沒有,結果發現 OpenSSL 解半天都解不開,還跑去玩了 bruteforce-salted-openssl 這個專案:

Try to find the password of a file that was encrypted with the 'openssl' command.

後來也是因為這個專案提醒,發現 openssl enc 指令在 OpenSSL 1.0.x (以及之前) 預設是用 MD5 當 digest algorithm,而 1.1.x 換成了 SHA-256,而我的備份資料應該是在 0.9.x 的年代就生出來了...

指定 -md md5 後就正常解出來了:

openssl enc -bf -d -md md5 -in ooxx.tar.gz.bf -out ooxx.tar.gz

另外一個收穫是 CPU 溫度降了不少:因為跑 bruteforce-salted-openssl 的時候 CPU 到 80 度,感覺撞到安全值卡在 4.0Ghz,所以就把 CPU 電壓降了 0.1V,看起來溫度低了不少 (少了五度),但跑起來還是 4.0Ghz...

講求速度的 Cryptographic Hash Function:BLAKE3

今年年初發表的 cryptographic hash function,重點在於速度:「The BLAKE3 cryptographic hash function」。

在 1 thread 的情況下就遠遠拉開目前的 cryptographic hash function:

因為速度是主打項目,所以提供的範例已經是使用 x86 與 ARM 的 SIMD 加速的版本,另外也可以透過平行化加速。

所以是要拼 de-facto standard 嗎,不知道 browser 這邊有沒有機會採用,雖然在現在都是使用 AEAD cipher 的情況下好像沒有太多出場機會...

TCP Congestion Control Algorithm 的選擇

先前 Ubuntu 桌機用 BBR 跑了一陣子,但有遇到一些問題 (可以參考「Dropbox 測試 BBRv2 的結果」這篇),所以暫時換成 Westwood,但還是陸陸續續會看一下各種研究。

剛剛在「[tor-relays] TCP CCA for Tor Relays (and especially Bridges)」這邊看到一個經驗談:

Here are my completely unscientific scribbles of how all the various algorithms behaved. The scenario is uploading for a minute or so, observing the speed in MB/sec visually, then recording how it appeared to change during that minute (and then repeating this a couple of times to be certain).

tcp_bic.ko       -- 6...5...4
tcp_highspeed.ko -- 2
tcp_htcp.ko      -- 1.5...3...2
tcp_hybla.ko     -- 3...2...1
tcp_illinois.ko  -- 6...7...10
tcp_lp.ko        -- 2...1
tcp_scalable.ko  -- 5...4...3
tcp_vegas.ko     -- 2.5
tcp_veno.ko      -- 2.5
tcp_westwood.ko  -- <1
tcp_yeah.ko      -- 2...5...6

上面是「目視法」觀察到的速度 (MB/sec),看了一下維基百科上 TCP-Illinois 的說明,看起來設計的目的是提供給頻寬大、latency 高的情境下:

It is especially targeted at high-speed, long-distance networks.

來跑跑看好了...

Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題,在 BBRv2 有一些改善 (目前還在測試階段,在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明),而 Dropbox 則是跳下去測試,並且公佈結果:「Evaluating BBRv2 on the Dropbox Edge Network」。

Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢,但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到:我自己的 Ubuntu 桌機跑 BBRv1,在我上傳大量資料的時候 (只開一條連線),會導致 PPPoE 的 health check 失敗,於是就斷線了,另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE,也可以看到斷線嘗試重連的訊息,於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高,除了我遇到的問題外,這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平):

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制,可以更清楚知道塞住的情況。

整體上來說應該會好不少,不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1,或是不換,讓 BBRv1 與 BBRv2 共存?