Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptographic Right Answers

latacora.singles

Post reply on HN
Print view View original

91–100 of 243 posts

Re: Cryptographic Right Answers

#91

Post by loeg »

masklinn wrote: post #37
keithwinstein wrote: post #13

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom. (1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that…

> It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't. It could even do that for urandom already. IIRC that's what BSDs do.

> It could even do that for urandom already.

It could, in the sense that anything is possible, but that isn't the behavior the Linux kernel community has chosen. And they are pretty good about not changing published interfaces at this point. At least getrandom(2) provides the sane behavior (and does not require an fd or filesystem namespace access).

> IIRC that's what BSDs do.

Yep, at least FreeBSD.

Re: Cryptographic Right Answers

#92

Post by loeg »

ryan-c wrote: post #58
loeg wrote: post #18

Two nits: > Don’t built elaborate password-hash-agility schemes. build* And what's the asterisk on > Avoid: … IPSEC.* ?

IPSec has a boatload of possible configurations, many of which are not secure. It's kind of a tire fire.

Sure, I'd just like it clarified on the article.

Re: Cryptographic Right Answers

#94

Post by tptacek »

schoen wrote: post #88
tptacek wrote: post #2

Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…

I ask experts about this every few years, but I don't seem to write down what they tell me and I've encountered a bit of a range of opinion, but: What's bad about cipher cascades? (No, I don't current encourage people to use them and I tell people that there's some expert sentiment discouraging them; I want to remember the basis of that sentiment.)

The dangerous part about implementing payload encryption isn't the cipher; mainstream modern ciphers are quite strong and bear few caveats. What's dangerous about encrypting are the constructions you use to apply ciphers to actual data (the "modes", though this is a terrible term that needs to go away).

Cascading ciphers does nothing to address the dangerous part of encrypting (order of operations for authenticating, authenticating all the security-sensitive components of the message, validating authenticators safely, randomizing encryption, safely handling truncation of authentication tags, providing adequate headroom for nonces, &c &c). In fact, since the best modern authenticated encryption constructions tend to be built up from a single cipher core (usually AES), cascades make encrypting safely harder.

You could "cascade" authenticated constructions, but different constructions have different failure modes. The poly MAC constructions fail and cough up authentication keys. Some gracefully handle truncation and some don't. Some constructions fail somewhat resiliently if nonces get repeated; some explode; some purport not to seriously fail at all. Some of them can reliably be implemented in software on any platform, but the binary field stuff really wants hardware extended carryless multiplication or you get new side channels. These things aren't designed to snap together in cascades and smushing them together doesn't make a lot of design sense.

It's hard to get this stuff right even when you're making the conventional, boring choices. Cascades involve a lot of "not boring" stuff, and the payoff for that not-boringness is arguably homeopathic.

Re: Cryptographic Right Answers

#95

Post by piracykills »

Curious - why is argon2 still second to scrypt on this list?

I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography:

https://blog.filippo.io/restic-cryptography/

If anyone sees a reason why Tarsnap would be better (other than Percival's brand), I'd be quite interested.

Re: Cryptographic Right Answers

#97

Post by jamesdsadler »

Can anyone recommend some good cryptography books/links for someone that would like get up to speed on best practices for building secure systems? Ideally the full gamut of beginner to advanced.

What are the classic/authoritative texts in this space?

Re: Cryptographic Right Answers

#98

Post by bsder »

tptacek wrote: post #2

Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…

Um, how about elaborating on embedded?

> you can use STROBE and a sound, modern, authenticated encryption stack entirely out of a single SHA-3-like sponge constructions.

Or I can go grab TweetNaCl. Is there any reason to use something else?

> Speaking of AKEs, there are, like, 30 different password AKEs you could choose from.

Each with it's own specific (often multiple) footguns. I haven't found any good AKE implementation that I trust for embedded devices.

Re: Cryptographic Right Answers

#99

Post by lvh »

piracykills wrote: post #95

Curious - why is argon2 still second to scrypt on this list? I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography: https://blog.filippo.io/restic-cryptography/ If anyone sees a reason why Tarsnap would be better (other than Percival's brand), I'd be quite interested.

This is relevant:

> But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.

It’s not so much a strict order of preference as it is a preference, any preference, so as to still be recommending things. Argon2 and scrypt are too close to call.

Re: Cryptographic Right Answers

#100

Post by piracykills »

lvh wrote: post #99
piracykills wrote: post #95

Curious - why is argon2 still second to scrypt on this list? I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography: https://blog.filippo.io/restic-cryptography/ If anyone sees a reason why Tarsnap would be better (other than Percival's brand), I'd be quite interested.

This is relevant: > But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use. It’s not so much a strict order of preference as it is a preference, any preference, so as to still be recommending things.…

I'm under the impression Argon2 is at least marginally better than scrypt as it has heavily analyzed side channel mitigations and such. Is scrypt better in some other way?
Post reply on HN