str4d 🛡️First day of #RealWorldCrypto! Looking forward to some great talks and great discussions.
Find me if you want to chat about cryptographic implementations, zero-knowledge proofs, Rust, or how great it would be if RWC went to New Zealand! 😁
Rowhammer-assisted attack on FrodoKEM's key generation enables a long-term public key to be permanently and undetectably poisoned.
The engineering to get reliable Rowhammer results within an 8ms keygen window is impressive! Requires access to the memory space in which keygen runs, but that is potentially relevant to deployments in cloud systems.
https://iacr.org/submit/files/slides/2023/rwc/rwc2023/100/slides.pptx
Meta: It would be really helpful if the RWC website provided linkable handles into the program so I could directly point to the abstracts. It does at least provide URLs to the talk slides, so that's what I'll link to where relevant.
This was a common thread at yesterday's #RealWorldPQC conference as well: hashing is dominating the costs of post-quantum algorithms! (c/f using classical elliptic-curve crypto, where the cost is usually dominated by point addition and scalar multiplication).
https://iacr.org/submit/files/slides/2023/rwc/rwc2023/68/slides.pdf
Apple describing their #PrivateRelay system (two-hop client IP privacy).
Tunnel establishment looks pretty similar to #Tor: build the first hop, extend new hops through earlier hops.
#I2P by comparision has single-shot tunnel building: it uses nested encryption to send a single message out, each hop stores its reply in its message layer and forwards it on, and the last hop is given a different tunnel to send the reply through to reach the client.
https://iacr.org/submit/files/slides/2023/rwc/rwc2023/IT_1/slides.pdf
Single-shot tunnel building is necessary because #I2P tunnels are unidirectional. Tunnel hops only route half of the communication traffic, making traffic analysis harder. It also means more peers are involved in round-trip traffic, which can create reliability issues.
For #PrivateRelay which is not trying to do any traffic hiding and prioritises performance, using bidirectional tunnels and interactive tunnel building makes sense.
Apple requires clients to be authorized before using #PrivateRelay, but doesn't want to link that authorization to the client's relay activity. That's great! This is what #PrivacyPass enables you to do! More people should do this!
I'm sad that part of that authorization is baked-in geoblocking restrictions, but I'm guessing that was a necessary restriction in order for websites to not block the egress relay IPs (which does occur to #Tor exit nodes).
Stephan Somogyi is giving an excellent talk on "Design, Applied Cryptography, and Humans".
"We should strive to build tools that users can use easily and without training."
"We should be designing to the strengths of the humans."
YES YES YES
More excellent points from Stephan Somogyi:
"Not Edge Cases, but Stress Cases"
"Users who are outside of the middle need to be included in our design thinking."
"Design your cryptosystems for people. Don't just think about pixels and battery, think about how humans drop their phones into water."
Q: When designing, how do you take into account the fact that software is not static, things will change over time and protocols will need to change?
A: It's hard.
One system I'd recommend is the Wireguard paper. They approached the system with very strong opinions.
Having founded opinions, documenting them, seeking feedback, and adequately describing the parameters of your design space, will help you to migrate people off it when the time comes.
Q: (Something about configurability)
A: Having infinite numbers of twiddly knobs that can lead users to sharp edges is not great. However, user research shows that at-risk users need more options, not fewer.
Most people will just use the defaults; they need to be secure, but they also need to not introduce sharp edges for users above the base-line risk.
Part of another Q&A answer:
There is no one at-risk user; there are different kinds of extremes. And any of us can become an at-risk user in around two seconds (see: social media).
A middle / common user can become an extreme user with no warning. Stresses the importance of including extreme users in the design.
lynn@str4d If there is expansion on this, I would love to see real-world examples of this in UX design
Magitism@str4d After 30ish years of web deving, half of it professionally, I have learned one thing: everything is temporary. Build everything to be torn to the foundation and rebuilt in the smallest viable bits. Do so regularly. Attempting to prevent it just makes doing it later more painful.
Dick Smiths Fair Go Supporters