lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 17:59:14 +0000
From: Greg Zaverucha <>
To: "" <>
Subject: RE: [PHC] Passwords15 BSidesLV talks

Jeremy, you understand correctly, and Dennis' summary is accurate. 

With EtM, the attacker can test a password either by decrypting the whole ciphertext, or checking the MAC.  In both cases he has to make a pass over the whole ciphertext.  In the MtE variant, the MAC is encoded and encrypted, so the attacker must make two passes over the ciphertext.  But with MtE the defender must decrypt before checking the MAC, which can lead to problems. So that's why I wanted to consider both variants. 


-----Original Message-----
From: Dennis E. Hamilton [] 
Sent: Saturday, August 15, 2015 10:32 AM
Subject: RE: [PHC] Passwords15 BSidesLV talks

My understanding of the ANT scheme described at <>.

The key to this scheme is that an Encode is such that, without Decode, a decryption does not reveal enough about known-plaintext characteristics to signal to an attacker that they are on the wrong track or not.  In particular, it is not enough to use a single decrypted-trial block to determine that the trial key is incorrect.  

This is a big deal in document formats and document container systems that have predictable early structure, as in OOXML, ODF, and EPUB documents (where the ODF case is fairly notorious because it encrypts document components individually and implementations have tended to include known, fixed boilerplate components that are independent of document content and there are other structural clues such as expecting XML and HTML forms).

For encrypt-then-MAC, there is the problem that testing a key for failing to verify the MAC becomes the next attacker opportunity for "rapid" key-trial rejection, especially for short ciphertexts.  Even though the defender only has to do this once (with a correct, known key) and the attacker is not quite so fortunate, the problem is that we're still talking about password-based encryption and the fundamental weakness of that remains so long as defender encryption-decryption must remain practical.  

The short-message case seems bothersome all around, although one could crank up the work-factor parameters of the key derivation operation given a short plaintext.  But that is not much compared to making the key extremely strong and never reused instead [;<).

 - Dennis

 -----Original Message-----
From: Jeremy Spilman []
Sent: Saturday, August 15, 2015 08:23
Subject: Re: [PHC] Passwords15 BSidesLV talks

A question I wanted to ask at the talk but didn't get the chance...

I guess with Encrypt-then-MAC an attacker can still just check the MAC but that would involve;

a) calculating the MAC key, which is typically chained off the encryption key possibly with additional work factor

b) streaming the entire cipher text through the hash function

Whether this is faster than skipping the MAC key derivation and hash step and going straight to decrypting the entire ciphertext and applying the ANT I guess could vary. But in any case it's a better lower bound than decrypting just one block.

Is that right?

[ ... ]

Powered by blists - more mailing lists