On Thursday, October 31, 2013 at 10:06 AM, "Johan Wevers"
<[email protected]> wrote:
>However, encrypting a message with AES with key1 and then
>encrypting it again with key2 (key1 unrelated to key2) can't make it less
>secure
>since any attacker can encrypt the intercepted encrypted message again
>with little effort. That would be like saying that base-64 encoding the
>message would reduce security.
=====
If the keys are different, and the algorithms different, then it would seem
that there is a major advantage to re-encrypting the ciphertext,
('cascading' is the term Truecrypt uses for this.)
The advantage is,
that if it should ever be possible to brute force the keyspace of one key, then
NONE of the possible elements of the keyspace (including the *correct* key)
will result in an identifiable *correct* plaintext. It will only result in
random ciphertext.
(This is different than ROT(10) followed by ROT(16), because it can be broken
by brute forcing ROT(x, ; 0<x<26), which will result in a correct plaintext.)
=====
>Of course there is one well-known encryption product that offers
>this option: TrueCrypt allows one to stack encryption algorithms. But
>then, the design decisions of TrueCrypt are not really known.
=====
Truecrypt allows only AES, Twofish, and Serpent for encryption and cascading.
(Whether this is because there is a potential flaw in using other algorithms,
or whether it is simply too much work for the developers to provide cascading
for all algortihms, I do not know.)
Here is the description in the Truecrypt documentation:
http://www.truecrypt.org/docs/cascades#Y0
=====[begin quote]=====
AES-Twofish-Serpent
Three ciphers in a cascade [15, 16] operating in XTS mode (see the section
Modes of Operation). Each 128-bit block is first encrypted with Serpent
(256-bit key) in XTS mode, then with Twofish (256-bit key) in XTS mode, and
finally with AES (256-bit key) in XTS mode. Each of the cascaded ciphers uses
its own key. All encryption keys are mutually independent (note that header
keys are independent too, even though they are derived from a single password –
see the section Header Key Derivation, Salt, and Iteration Count). See above
for information on the individual cascaded ciphers.
Serpent-AES
Two ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes
of Operation). Each 128-bit block is first encrypted with AES (256-bit key) in
XTS mode and then with Serpent (256-bit key) in XTS mode. Each of the cascaded
ciphers uses its own key. All encryption keys are mutually independent (note
that header keys are independent too, even though they are derived from a
single password – see the section Header Key Derivation, Salt, and Iteration
Count). See above for information on the individual cascaded ciphers.
Serpent-Twofish-AES
Three ciphers in a cascade [15, 16] operating in XTS mode (see the section
Modes of Operation). Each 128-bit block is first encrypted with AES (256-bit
key) in XTS mode, then with Twofish (256-bit key) in XTS mode, and finally with
Serpent (256-bit key) in XTS mode. Each of the cascaded ciphers uses its own
key. All encryption keys are mutually independent (note that header keys are
independent too, even though they are derived from a single password – see the
section Header Key Derivation, Salt, and Iteration Count). See above for
information on the individual cascaded ciphers.
Twofish-Serpent
Two ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes
of Operation). Each 128-bit block is first encrypted with Serpent (256-bit key)
in XTS mode and then with Twofish (256-bit key) in XTS mode. Each of the
cascaded ciphers uses its own key. All encryption keys are mutually independent
(note that header keys are independent too, even though they are derived from a
single password – see the section Header Key Derivation, Salt, and Iteration
Count). See above for information on the individual cascaded ciphers.
=====[end quote]=====
A potentially discomforting point in how Truecrypt does this, is that they
state, that the different cascaded header keys are derived from a single
password.
It may well be that, as Robert intuitively felt, an avenue of attack on the
password and subsequently derived keys, might be far more feasible than trying
to brute force a keyspace, and therefore rendering the resulting ciphertext
more vulnerable than if it were encrypted only once.
vedaal
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
