Messages in this thread | | | Date | Sun, 16 May 2004 20:46:32 +0300 | From | Jari Ruusu <> | Subject | Re: [PATCH 2/2] Support for VIA PadLock crypto engine |
| |
Fruhwirth Clemens wrote: > Your countermeasures to optimized dictionary attacks are suboptimal. The > following code is from your util-linux patch: > > aes_encrypt(&ctx, &loopinfo.lo_encrypt_key[ 0], &loopinfo.lo_encrypt_key[ 0]); > aes_encrypt(&ctx, &loopinfo.lo_encrypt_key[16], &loopinfo.lo_encrypt_key[16]); > /* exchange upper half of first block with lower half of second block */ > memcpy(&tempkey[0], &loopinfo.lo_encrypt_key[8], 8); > memcpy(&loopinfo.lo_encrypt_key[8], &loopinfo.lo_encrypt_key[16], 8); > memcpy(&loopinfo.lo_encrypt_key[16], &tempkey[0], 8); > > Symmetric block ciphers can't be used as hashing per se.
You nipped away part of code that does hashing.
> Neither seems the > swapping scheme you're using to be a standard hash construction for ciphers.
Swapping upper half of first block with lower half of second block between multiple iterations of encryption is correct way to extend block length.
> I suggest to read "Applied Cryptography", Bruce Schneier, "18.11 One-Way > hash functions using symmetric block algorithms" as an introduction to that > topic.
May I suggest that you read and understand the code before publishing incorrect conclusions.
> To avoid this troubles all together, I recommend to use a standard > MAC instead.
Recommended way of setting up encryption keys in loop-AES, is to use gpg encrypted key file with random keys. gpg does all that salted+iterated key setup without any user intervention. That quoted part of code is there for backward compatibility.
> > > You have been campaigning with FUD > > > against cryptoloop/dm-crypt for too long now. There are NO exploitable > > > security holes in neither dm-crypt nor cryptoloop. > > > > In the past you, Fruhwirth, have demonstrated that you don't understand what > > the security holes are. The fact that you still don't seem to undertand, > > does not mean that the holes are not there. > > Everyone attending a rhetoric seminar learns, "If you run out of > arguments, attack the person itself". The attacks, you're speaking of in > the next paragraph, apply to the key deduction. That's very different > from IV deduction.
You said that I was spreading FUD. I said you are wrong. Fortunately at least some of mainline kernel dudes seem to understand:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107713612713381&w=2
> > Optimized dictionary attack is exploitable. Ok, it requires major government > > size funding, but what do you think NSA guys get paid for? > > > > Watermark attack is exploitable using zero budget. > > As I said, not cryptoloop's responsibility.
Optimized dictionary attack can be prevented using better mount and losetup programs. Mainline util-linux is still backdoored.
Watermark attack is very much cryptoloop's and dm-crypt's responsibility.
> Please read my mails carefully. See the following paragraph: > > > > There is room for improving both IV deducation schemes, but it's a > > > theoretic weakness, one which should be corrected nonetheless.
As long as there are only promises, and unfixed exploitable vulnerabilities remain in mainline cryptoloop+util-linux and dm-crypt+cryptsetup, people continue to be scammed to using backdoored crypto.
> > One cryptoloop developer > > somehow managed to convince util-linux maintaner to drop those > > countermeasures against optimized dictionary attacks. To protect the guilty, > > I won't name his name here, but search linux-crypto archives for 14 Mar 2003 > > 11:12:13 -0800 posting if you want know his name. > > You are talking about util-linux again. Rusuu, don't try to fool the > audience by arguing for something totally different. Further if you try to > provide evidence for something, provide an URL to back your claims. I wasn't > able to find any mails in the archives dealing with that topic.
Wrong list, sorry. It was CC'd to cryptoapi-devel:
http://www.kerneli.org/pipermail/cryptoapi-devel/2003-March/000506.html
-- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |