News for hackers. Stuff that matters.
Re:The Cryptographic Doom Principle by revelation on Saturday January 10, 2015 @01:50PM (#8867507)
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.
Re:The Cryptographic Doom Principle by ambrop7 on Saturday January 10, 2015 @03:16PM (#8867771)
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.)
Re:The Cryptographic Doom Principle by dsacco on Sunday January 11, 2015 @09:29AM (#8870046)
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.

Re:The Cryptographic Doom Principle by jbaudanza on Saturday January 10, 2015 @02:23PM (#8867614)
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.