## 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」。 先講一下這次的 bounty program，希望找出下面這些 SHA-1 的 pre-image input (也就是找出 input，使得 SHA1(input) 會等於下面的東西)： 3045AE6FC8422F64ED579528D38120EAE12196D5 BD71344799D5C7FCDC45B59FA3B9AB8F6A948BC5 C49D360886E704936A6678E1139D26B7819F7E90 A335926AA319A27A1D00896A6773A4827ACDAC73 D09E8800291CB85396CC6717393284AAA0DA64BA 金額是 US$12288，但是要五個都找到。

$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.

## SHA-256 的 Length extension attack

Hacker News 上看到「Breaking SHA256: length extension attacks in practice (kerkour.com)」，在講不當使用 SHA-256 會導致 Length extension attack 類的安全漏洞，主要是因為 MD5SHA-1 以及 SHA-2 類的 hash function 最後生出 hash 值時會暴露出 hash function 的內部狀態而導致的問題。

// Process the message in successive 512-bit chunks:
for each 512-bit chunk of padded message do
// ...

// Add this chunk's hash to result so far:
a0 := a0 + A
b0 := b0 + B
c0 := c0 + C
d0 := d0 + D
end for

var char digest[16] := a0 append b0 append c0 append d0 // (Output is in little-endian)

Original Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo
Original Signature: 6d5f807e23db210bc254a28be2d6759a0f5f5d99

Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege

New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x28&waffle=liege
New Signature: 0e41270260895979317fff3898ab85668953aaa2

## Post-Quantum 的 KEM，SIDH/SIKE 確認死亡

I had 4 older AMD R9 390 GPUs laying around (for the nVidia crowd that's basically on a level with a GTX 970) and I thought it could work.

Success! I was able to lower my heat pump's electricity needs by ~50% and half of the costs are also paid for by the mining earnings

## Intel 的 RDRAND 爆炸...

The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, FIPS 140-2, and ANSI X9.82.

As explained in the earlier article, mitigating CrossTalk involves locking the entire memory bus before updating the staging buffer and unlocking it after the contents have been cleared. This locking and serialization now involved for those instructions is very brutal on the performance, but thankfully most real-world workloads shouldn't be making too much use of these instructions.

We disclosed an initial PoC (Proof-Of-Concept) showing the leakage of staging buffer content in September 2018, followed by a PoC implementing cross-core RDRAND/RDSEED leakage in July 2019. Following our reports, Intel acknowledged the vulnerabilities, rewarded CrossTalk with the Intel Bug Bounty (Side Channel) Program, and attributed the disclosure to our team with no other independent finders. Intel also requested an embargo until May 2020 (later extended), due to the difficulty of implementing a fix for the cross-core vulnerabilities identified in this paper.

## 原來 Fully Homomorphic Encryption 已經被解啦...

Hacker News Daily 上看到「IBM Releases Fully Homomorphic Encryption Toolkit for MacOS and iOS; Linux and Android Coming Soon」這個消息，主要是 IBM Research 要放出一些跟 Fully Homomorphic Encryption (FHE) 的 library。

Homomorphic encryption 講的是直接對密文操作：(這邊的 $\cdot$ 是操作，可能是加法，也可能是乘法，或是其他類型)

$C_1 = enc(P_1)$
$C_2 = enc(P_2)$

$enc(P_1 \cdot P_2) = enc(P_1) \cdot enc(P_2) = C_1 \cdot C_2$

(雖然只用了十頁主要還是因為 STOC 篇幅的關係，但扣掉 circuit privacy 的部份，前面在說明建構與證明的過程只用了九頁也是很驚人)