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/
