crypto.stackex has an interesting discussion on EtM and MtE: http://crypto.stackexchange.com/questions/202/should-we-mac-... One interesting take away was, Bruce Schneier is of opinion that MtE (Cryptographic Doom acc to Moxie) is more practical than EtM.
Interesting to note that different security protocols on the Internet prefer different schemes:
1. SSH does Encrypt and MAC
2. SSL uses MtE
3. IPSec prefers EtM
Also see: Authenticating users over REST http://restcookbook.com/Basics/loggingin/ which glances at the details not covered by the blog post (using nonce to prevent replay attacks, for instance).
Bruce Schneier was wrong about MtE. This isn't so much a matter of opinion as it is (a) the currently prevailing theory in academic cryptography, at least when it comes to generic composition, and (b) the clear verdict of the last 10 years of crypto vulnerabilities.
Just writing this to be clear: it's not a debate. Ignore Schneier on this. In his defense: the most notable things he wrote about MtE were written before this was well-understood.
Yep. "Generic composition" (taking independently designed MACs and cipher modes and rolling your own AE) is my cop-out in case 'pbsd shows up to correct me.
Generally, though, and without intending snark:
If you're discussing MTE v ETM, and Bruce Schneier comes up, the answer is ETM.
Encrypt-Then-MAC just makes sense. If the first thing you do when you receive a blob of encrypted data is check that it's authentic (in constant-time!), the attack surface is greatly reduced.
Our strategy (designed for a "remember me" checkbox) is actually a little more cautious than a simple nonce, in that we actually generate two tokens:
One is a selector (used to retrieve a record from the database, which is an operation that cannot be performed in constant time), while the other is a validator.
We store an SHA256 hash of the validator in the database. When the auto-login is invoked, we pull the hash and destination user ID from the database (based on the selector), the compare
if (hash_equals(hash('sha256', $verifier), $storedHash)) {
$_SESSION['userid'] = $storedUserId;
$this->generateAndStorePersistentToken(storedUserId);
}
Interesting to note that different security protocols on the Internet prefer different schemes:
Also see: Authenticating users over REST http://restcookbook.com/Basics/loggingin/ which glances at the details not covered by the blog post (using nonce to prevent replay attacks, for instance).