[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loop-AES and Twofish on 64-bit CPU

Christian Kujau wrote:

On Sun, 28 May 2006, Gisle Sïlensminde wrote:

Gisele, I was under the assumption that the OP know that it takes more than just "ciphers" to be "secure", so I just wanted to say (again):

-> "decreased security" *just because* of 2 ciphers would mean that we could break ciphers by chaining them together often enough?

(I'm Gisle, not Gisele)

I don't want to assume such knowledge, as many security experts in major corporations has failed on this point. The idea of double encryption "just in case" is often a sign of lack of knowledge in cryptography. The cipher is probably the least likely part to be broken, and doubling it will double the CPU usage for little gain in security.

"possibility for an attack"? so, do you mean if it's labelled
"comes with double-encryption (only 49,99 ;))"
more people would attack the ciphertext?

Maybe not because the double encryption, but with _that_ advertisement I would know it was snake oil. ;-)

I mean that another component in the system is introduced, and this part, as any other part of the system may have flaws. An important principle in the design of such systems, is to keep them as simple as possible, but not simpler. That makes them easier to evaluate.

may introduce a weakness that let an attacker exploiting the fact that
the two ciphers use the same key or some other attack that you could not


different ciphers, different keys, methinks. otherwise we really had problems like known-ciphertext attacks or sth. like that. again: if "more ciphers" do mean "decreased encrpytion", then I'd be really curious about
the how-many-ciphers-to-break-this issue ;)


While the two ciphers may not use the same key, it is likely that such a system will still only use one passphrase or other means of authentication from the user, and that may introduce a weakness that can be exploited if not done right. It may not make more people attack the ciphertext, but one smart guy may find a way to exploit the weakness in the modified key handling scheme introduced.

In this sense, the difference on user level details, like the difference between a user passphrase and a usb-stick
scheme, can have large impact on the security of the system, and both must be analyzed separatly for security.

My point with the examples of weaknesses in "famous" protocols like SSL and WEP in my last posting, was to illustrate that even some of the best fails, and that design of cryptosystems is hard. Most of these flaws was either not necessary (the cipher suit approch was introduced of political reasons), or overlooked aspects of the system (the random generator). What I mean is that the system should be simple, and that all aspect, like user authentication, seeding etc must be included in the analysis. Furthermore, all assumptions should be stated explicitly in the design.

analyzed AES than the loop-aes system, so I would be more worried about how loop-aes is designed than the strength of the cipher.


hm, makes sense too. we just have to enlarge the loop-aes userbase and get it all reviewed...

Exactly.

A first step could be to describe loop-aes and cryptoloop, like done for the random-device in the paper I linked to.



-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/