The Cryptographic Doom Principle | Hacker News Reader

The Cryptographic Doom Principle

thoughtcrime.org

120 pointsRexxar15 comments

This is from 2011. Still a really good (and short) read :)

The URL from this submission ends with /?, so HN wasn't able to dedupe it from the earlier submission: https://news.ycombinator.com/item?id=6153834

What does OpenPGP do? If you have the MAC in plaintext, wouldn't anyone be able to determine who encrypted the message?

It calls it a modification detection code, but it does "Authenticate Then Encrypt":

https://tools.ietf.org/html/rfc4880#section-5.13

It also does digital signatures (but those are different than a MAC, they verify the identity of the sender).

The MAC takes a shared secret as input, so it should only reveal anything to parties that possess that secret.

I've always enjoyed Moxie's blog posts. This one is probably my favorite.

AEAD, EtM, or bust.

I wonder if AtE with MD5 with secret prefix as MAC can be exploited, as in say SSLv2.

Or don't bother with this and generate random tokens, which should cover about 99 percent of cases where a clueless developer would run into the problems here. Leave the cryptography to those that actually know they need cryptography.

What do you do with the random tokens after you've generated them?

The author's proposed solution of "Encrypt then authenticate" seems pretty reasonable.

You sound like a web developer who thinks that 99% of cryptographic problems have to do with a web application discriminating between sessions. (I'm just guessing about the context of your comment since you didn't provide any.)

Generating random tokens is cryptography. It just happens to be done more by non-cryptographers, which doesn't necessarily mean they're better at it (hint: they aren't).

You can perform cryptanalysis on random tokens and if the RNG (or PRNG) isn't seeded properly, you get a replay attack. This is not to mention: aside from attacks, you have further crypto to do aside from the generation: how do you verify the token?

If you roll your own RNG/PRNG and token generation, it is probably just as broken as the block cipher you tried to roll yourself as well. Using standard libraries and well-audited tools brings ciphertext authentication into the same realm of usability for developers that token generation is in.

For the other clueless readers:

MAC: http://en.wikipedia.org/wiki/Message_authentication_code

[Please spell out your acronyms the first time, nerds]

To be fair, the first use was a link to the wikipedia article, the style just doesn't give you any indication of that.

If I recall, underlining links led to heated debates in some circles, but it's really, really nice to have some visual signal to set off links for readers. If it wasn't obvious why already, this is a great case.

> To be fair, the first use was a link to the wikipedia article, the style just doesn't give you any indication of that.

Huh? it's a different color.

Huh, yeah, they are two different shades of gray. Completely missed that, so I'm still for more contrast in links. I guess if I'm forced to rate Moxie Marlinspike on presentation, maybe he gets docked a point.

It all feels a bit like rating chef Jonathan Benno on shoelace cleanliness though.

At first glance, I just thought the slightly different shade was for emphasis, rather than indicating a link.

Who in their right mind would debate against underlined hyperlinks? Either underlined or blue, and bolded. Keep it at that accepted standard. Such senseless bikeshedding. If your design breaks user expectations then it's almost certainly bad design.

Reply on news.ycombinator.com