I think reading this helps me imagine a version of the future I'd actually like to live in. A version where technology is used well (rather than preaching for abstinence from technology) and where values other than "intelligence" (in whatever guise) are on an equal footing.

Even writing that makes me feel naive (and to an extent I know it is) but I think it would be inconsistent for someone who cheers for humanity's efforts to solve/chip away at "impossible" problems (like LLMs were thought to be not so long ago) to shirk from the challenge of making the world better for _everyone_.

From the UK NCSC [1]:

> QKD does not provide authentication, nor do any other quantum techniques. Therefore, in practice, QKD must be combined with other cryptographic services to provide security against the threat from quantum computing, and therefore should not be relied on as a mechanism that provides substantial security value. [...] The NCSC will not support the use of QKD for government or military applications. PQC is the best mitigation to the threat to cryptography from quantum computers.

And the German BSI (and partners)[2]:

> Together with European partner agencies from France, the Netherlands and Sweden, the BSI has published a Position Paper on QKD. The paper concludes that QKD can only be used in niche use cases due to its technological limitations and that QKD is not yet sufficiently mature from a security perspective. Therefore, in light of the necessary migration to quantum-safe schemes, the clear priority should be the migration to post-quantum cryptography.

This is despite different choices for which PQC algorithms to use. E.g. NIST (and many others including the UK) have gone initially with ML-KEM for key exchange, while Germany/BSI have selected FrodoKEM and Classic McEliece.

[1] https://www.ncsc.gov.uk/paper/quantum-networking-technologie... [2] https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisati...

Venue should not imply credibility but in this case it would certainly help bring the proper scrutiny.

[1] https://eprint.iacr.org/

Comments URL: https://news.ycombinator.com/item?id=45091943

Points: 2

# Comments: 0

I think that's probably because the NIST competition [1] to choose their standard algorithms really started to heat up then.

NIST has a very large gravity well in the academic and industrial cryptographic community, so as soon as it became clear which algorithms NIST would pick (they chose Kyber / ML-KEM and Dilithium / ML-DSA), the (cryptographic) world felt it could start transitioning with much more certainty and haste.

1. https://csrc.nist.gov/projects/post-quantum-cryptography/pos...

Comments URL: https://news.ycombinator.com/item?id=40739806

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=35999473

Points: 2

# Comments: 0

This wasn't my understanding at all. The specific issue in isogeny based cryptography which the attack exploits has been a source of worry in the cryptographic community for a while, and is exactly why NIST put SIKE in the "for further consideration & crypt-analysis" category when making their standardization decisions.

Comments URL: https://news.ycombinator.com/item?id=32341852

Points: 12

# Comments: 1

You'd basically be building a cryptographic module (industry standard term, with a lot of specs and requirements to go a long with it), which is no small undertaking in terms of correctness, never mind security. The "basic" cryptographic routines aren't easy either. You're talking ECC and some other symmetric primitives. Secure & efficient ECC implementation is an entire discipline on it's own.

I have reservations about the phrase "don't roll your own cryptography" for lots of reasons, but this would be taking rolling your own to the extreme. With all the associated risks.

Absolutely possible and a very cool project, but yeah, it's hard to understate the complexity / requirements of a full cryptographic module on top of the cryptographic primitives it needs to support. I actually really like that this person took an existing commercial TPM and could integrate it into their own PCB this way, I think that's a good compromise between building your own TPM with an Arduino, and having to pay lots of money for an out-of-the-box TPM.

Comments URL: https://news.ycombinator.com/item?id=31292970

Points: 2

# Comments: 1

The trouble comes when you need to share access to a memory mapped peripheral among multiple threads/processes/users etc. It can be done, but it's usually easier to manage CPU registers than peripheral devices for things like crypto operations in larger systems. Plus, you have to do access control to the peripheral (so other processes don't try and steal your key), if its all within the security boundary of a "normal" process, you get that (mostly) for free.

All of the above has caveats and exceptions, but generally (ARM, SPARC, x86, now RISC-V) take this approach.

- Scalar crypto: https://github.com/riscv/riscv-crypto/releases

- Vectors: https://github.com/riscv/riscv-v-spec/releases

- Bitmanip: https://github.com/riscv/riscv-bitmanip/releases

The more general bitmanip extensions contain other things useful for e.g. address arithmetic. These are somewhat orthogonal to scalar crypto.

> instead of requiring the rest of the world to waste transistors for something that's useless.

I'm sure Chinese manufacturers might feel the same about NIST standards.

I'm biased, but the spec is supposed to be very accessible to people without a cryptography background. There's a section on who the intended audience is and what assumptions are made about their background. I'd really recommend it.

> The SM3/4 were unfamiliar to me - apparently it is a hash function & block cipher used in Chinese WiFi variant.

SM3/4 are required for use in certain places in China. RISC-V is popular in China, hence their inclusion in the RISC-V spec. My expectation is that SM3/4 will not likely ever be adopted outside China.

> Physical entropy source (with some variants to accommodate low profile variants)

There are no "variants" of the entropy source. There is one entropy source interface definition which is designed to scale across the many RISC-V implementation profiles. It's very different to x86/RDRAND which lots of people are used to.

Comments URL: https://news.ycombinator.com/item?id=28394597

Points: 78

# Comments: 18

Comments URL: https://news.ycombinator.com/item?id=27324076

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=26066991

Points: 1

# Comments: 0