This page covers random notes on applied cryptography collected from various sources, from StackExchange to academic papers.
Use two sources of RNG
s2n-tls uses compartmentalized sources of randomness - one public (i.e. its output can be read by anyone without an impact to security), and one private (i.e. its output should remain secret).
Two components of E2EE confidentiality
Matthew Green defines 2 components of E2EE confidentiality:
- confidentiality of what was sent
- confidentiality of who sent what; this is not the same thing as metadata, which covers the contacts with which I’ve interacted (since a centralized E2EE system has to know who to forward stuff to)
RNG on IoT
This article (and the corresponding DEFCON presentation) talks about the pitfalls of using RNG on IoT devices. The main difference between RNG on a server/PC and that on a IoT device is that the device normally doesn’t have a CSPRNG subsystem to take care of nicely packaging up the RNG sources of the platform and exposing them in a safe, developer-friendly way. For many IoT devices you only have a HAL between you and an RNG chip that’s supposed to be your main source of randomness. The issue then is - these interfaces are really inadequate, safety-wise (mostly in the “difficult to use” sense). The main point: most IoT devices that use this sort of approach might be susceptible to security issues arising from bad usage of RNG chips.
Their conclusions:
- This affects the entire IoT industry
- The IoT needs a CSPRNG subsystem
- RNG code should be considered dangerous to write on your own, just like crypto code
- Never use entropy directly from RNG hardware