## NIST P-curve 的 Seed Bounty Program

Filippo Valsorda 發起了 seed bounty program，針對 NIST P-curve 裡 seed 的部分尋找 SHA-1 的 pre-image：「Announcing the \$12k NIST Elliptic Curves Seeds Bounty」。

```3045AE6FC8422F64ED579528D38120EAE12196D5
BD71344799D5C7FCDC45B59FA3B9AB8F6A948BC5
C49D360886E704936A6678E1139D26B7819F7E90
A335926AA319A27A1D00896A6773A4827ACDAC73
D09E8800291CB85396CC6717393284AAA0DA64BA```

$y^2 = x^3 + ax + b (Weierstrass form)$ $y^2 = x^3 + ax^2 + bx (Montgomery form)$

$y^2 = x^3 + 486662x^2 + x$

To protect against various attacks discussed in Section 3, I rejected choices of A whose curve and twist orders were not {4 · prime, 8 · prime}; here 4, 8 are minimal since p ∈ 1+4Z. The smallest positive choices for A are 358990, 464586, and 486662. I rejected A = 358990 because one of its primes is slightly smaller than 2^252, raising the question of how standards and implementations should handle the theoretical possibility of a user’s secret key matching the prime; discussing this question is more difficult than switching to another A. I rejected 464586 for the same reason. So I ended up with A = 486662.

```3045AE6FC8422F64ED579528D38120EAE12196D5 # NIST P-192, ANSI prime192v1
BD71344799D5C7FCDC45B59FA3B9AB8F6A948BC5 # NIST P-224
C49D360886E704936A6678E1139D26B7819F7E90 # NIST P-256, ANSI prime256v1
A335926AA319A27A1D00896A6773A4827ACDAC73 # NIST P-384
D09E8800291CB85396CC6717393284AAA0DA64BA # NIST P-521```

Apparently, they were provided by the NSA, and generated by Jerry Solinas in 1997. He allegedly generated them by hashing, presumably with SHA-1, some English sentences that he later forgot.

[Jerry] told me that he used a seed that was something like:
SEED = SHA1("Jerry deserves a raise.")
After he did the work, his machine was replaced or upgraded, and the actual phrase that he used was lost. When the controversy first came up, Jerry tried every phrase that he could think of that was similar to this, but none matched.

## NIST 更新了 SHA-1 的淘汰計畫

NISTSHA-1 的新的淘汰計畫出來了：「NIST Retires SHA-1 Cryptographic Algorithm」。

The results presented so far on SHA-1 do not call its security into question. However, due to advances in technology, NIST plans to phase out of SHA-1 in favor of the larger and stronger hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) by 2010.

As today’s increasingly powerful computers are able to attack the algorithm, NIST is announcing that SHA-1 should be phased out by Dec. 31, 2030, in favor of the more secure SHA-2 and SHA-3 groups of algorithms.

“Modules that still use SHA-1 after 2030 will not be permitted for purchase by the federal government,” Celi said.

## SHA-1 在 2022 的破解速度已經降到 ~5.4 GPU years

Remarkably, we can see that in only 5 years, we're down from an attack costing ~110 GPU years to an attack costing ~8 GPU-years in 2020 (thanks to theoretical improvements & newer GPUs) to just ~5.4 GPU years nowadays (thanks to newer, faster GPUs).

In a more realistic way, it would take less than a day to do it on a super-computer such as the one owned by the US Department of Energy's Oak Ridge National Laboratory (ORNL) named "Summit".

## OpenSSH 8.4 預設停用 ssh-rsa

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 -oHostKeyAlgorithms=-ssh-rsa user@host`

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

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

## Django 3.1

SimpleTestCase now implements the debug() method to allow running a test without collecting the result and catching exceptions. This can be used to support running tests under a debugger.

## SHA-1 的 chosen-prefix collision 低於 2^64 了...

chosen-prefix collision 指的是先給定 `p1``p2` (在實際攻擊中，兩組都會是有意義的字串)，然後攻擊的演算法可以算出 `m1``m2`，使得 `hash(p1 // m1) == hash(p2 // m2)`，其中的 `//` 就是字串加法。這樣的是先產生出有意義的字串，於是就可以在真實世界中使用。

2008 年的時候就用這個方法生出一個 sub-CA：

In 2008, researchers used a chosen-prefix collision attack against MD5 using this scenario, to produce a rogue certificate authority certificate. They created two versions of a TLS public key certificate, one of which appeared legitimate and was submitted for signing by the RapidSSL certificate authority. The second version, which had the same MD5 hash, contained flags which signal web browsers to accept it as a legitimate authority for issuing arbitrary other certificates.[14]

## 實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

• 在 cipher 類的測試我只測了 AES (目前的主流)，小的 block (16/64/256 bytes) 時 AMD 會輸一些，但大的 block (1024/8192/16384 bytes) 反而會贏不少。
• 在 hash 類的測試中，跑 MD5 時 Linode 則是輸一些，但 SHA1 反而是贏一些，然後 SHA256 時效能好到爆炸贏了一倍 XDDD
• 在 public key 類的測試我測了 RSA，則是 Linode 輸的蠻慘的...

## GitHub 移除 HTTPS 中的 TLSv1/TLSv1.1，以及 SSH 中 SHA1 相關的協定

GitHub 完全移除掉 TLSv1/TLSv1.1 以及 SSH 中 SHA1 相關的協定了：「Weak cryptographic standards removed」。其中 TLSv1 與 TLSv1.1 的部份也可以從 SSL Report: github.com 這邊看到：

## GitHub 停用過時加密演算法的計畫

• February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
• February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms

## GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法

Since the announcement, we have been focusing on the impact of disabling the diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 key exchanges for SSH. As of last week, we have enabled diffie-hellman-group-exchange-sha256. This key exchange method is widely supported and will allow most legacy clients to seamlessly transition away from diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1.

This is a very small percentage of traffic, but we would like to see if we can reduce the incompatible traffic percentage even further before disabling support for the older key exchange algorithms on February 1, 2018.