3
$\begingroup$

In terms of security, would it be MORE or LESS secure to take, say, an RC4 output (or Serpent) or other, that is encrypted with one key, and to encrypt that output with AES (using a different key)?

> $Data -> Serpent ->  key: $s_key = HASH_HMAC(sha256, "1st Key" .
> $salt1, "HMAC KEY1") = $S_Output
> 
> $S_Output -> Rijndael (AES) -> key: $aes_key = HASH_HMAC(sha256, "2nd
> Key" . $salt1 . $s_key . $salt2, "HMAC KEY2") = $AES_Output

As long as I'm using good hashes as keys, would this be MORE secure than using a single key with AES? Is there a risk of the two ciphers colliding in some fashion? If so, would using a stream cipher instead of another xor-type cipher avoid this?

P.S. THIS IS PSUEDO-CODE -- I will be using truly random salts and keys for my data i.e. mcrypt / openssl

I will be using a software based token system like the RSA SecurID that is on a fingerprint-secured thumbdrive that opens a self-contained browser. Each keyholder has a 512 bit has to open the soft-token automatically. Once the token is posted to the auth site, it gives the pair (two people) 90 min to enter the keys.

Repeat the same thing for user# 2 with the second key.

AND THE REAL KICKER -- aside from the php thumb drive token gen, THIS HAS TO RUN ON PHP, killing the possibility of many other libs that are ideal.

Basically, two biometric token systems + two passphrases within 90 mins decrypts the file. But better to use Serpent + AES, AES + AES, or TWOFISH + AES?

Improve this question
$\endgroup$
5
  • $\begingroup$ You already asked this, and it was already answered. $\endgroup$
    – Stephen Touset
    Commented Dec 18, 2012 at 0:16
  • 1
    $\begingroup$ Also, it wasn't mentioned there, but your key generation is very weak. You should use either a key generated by a cryptographically random source of entropy (e.g., /dev/random), or at the very least use a key stretching function like PBKDF2 with an appropriately-calibrated number of iterations, and a cryptographically random salt. $\endgroup$
    – Stephen Touset
    Commented Dec 18, 2012 at 0:19
  • $\begingroup$ It wasn't completely answered; I am using mcrypt_create_iv / MCRYPT_RAND to generate random entropy, which, I have heard is a good source of data for keys. OpenSSL is another option. No one ever told me if data would collide --- whether it would be easier or harder to decrypt using two systems and dual keys. And no, I'm not confused about public and private keys such as RSA, etc, I'm simply trying to get a straight answer: with proper key entropy, does dual encryption hurt or help. Stephen, you are clearly an expert here, I am not. $\endgroup$
    – Jeremy P
    Commented Dec 18, 2012 at 0:39
  • $\begingroup$ Encryption is reversible so collisions are not an issue, and due to the meet-in-the-middle attack discussed in the earlier answer, it is generally not considered to be stronger (it's equivalent, effectively, to using a key that is a single bit longer). $\endgroup$
    – Stephen Touset
    Commented Dec 18, 2012 at 0:58
  • 3
    $\begingroup$ Please also consider the advice from the other thread that you should absolutely not be trying to use cryptographic primitives on your own. They are trivial to use insecurely and exceedingly difficult to use correctly. Libraries like KeyCzar and NaCl exist that perform the necessary computations for you, and you should absolutely use one of these. $\endgroup$
    – Stephen Touset
    Commented Dec 18, 2012 at 1:11

2 Answers 2

Reset to default
7
$\begingroup$

I don't think it's a bad idea - neither does Bruce Schneier. In his book Applied Cryptography, there is a section called "Cascading Multiple Block Algorithms". He basically states that provided that two distinct algorithms and two independent keys are used, then the result should be at least as difficult to break as the strongest algorithm.

If Alice and Bob do not trust each other’s algorithms, they can use a cascade. If these are stream algorithms, the order doesn’t matter. If they are block algorithms, Alice can first use Algorithm A and then use Algorithm B. Bob, who trusts Algorithm B more, can use Algorithm B followed by Algorithm A. They might even add a good stream cipher between the two algorithms; it can’t hurt and could very well increase security.

Remember that the keys for each algorithm in the cascade must be independent. If Algorithm A has a 64-bit key and Algorithm B has a 128-bit key, then the resultant cascade must have a 192-bit key. If you don’t use independent keys, then the pessimists are much more likely to be right.

Improve this answer
$\endgroup$
4
  • 3
    $\begingroup$ It's important that the keys are actually independent, not just unique. To similar algorithms with related keys could go as far as canceling each other out, resulting in unencrypted plaintext. $\endgroup$
    – Dennis
    Commented Dec 20, 2012 at 4:35
  • $\begingroup$ @Dennis - you're right - good catch. $\endgroup$
    – hunter
    Commented Dec 20, 2012 at 13:32
  • $\begingroup$ Paulo, Hunter, Dennis, and Stephen thanks for clarifying all of this to me. Special thanks to Stephen for practical advice, and to Paulo for explaining how cascading algorithms with different length keys CAN be executed safely. Am I correct in that you need to cascade the key lengths in order (i.e. 64 + 128 + 192) or can they be (128 + 64 + 192)? Also, If AES will be my primary alg, and RC4 will be my intermediary stream cipher, what algs are dissimilar enough to use next to AES? $\endgroup$
    – Jeremy P
    Commented Dec 21, 2012 at 3:07
  • 1
    $\begingroup$ @JeremyP: I don't think you'll get any definitive answers on this subject. It hasn't been studied enough (or at all) - and there are too many variables. Suffice to say, if you plan to go down this path, use the strongest algo first (AES), pay attention to Schneier's comments regarding block/stream algos, and be absolutely sure to use independent keys (and not just unique keys derived from the same source) with each cipher. $\endgroup$
    – hunter
    Commented Dec 21, 2012 at 18:15
3
$\begingroup$

An adversary would have to first break the first scheme and then the second, so in concrete terms there is slightly added security.If it takes time $2^{80}$ to break each scheme independently, it now takes time $2^{81}$ to break both encryptions. So there is minimal added security.

In computational terms, assuming the key-size are similar, this wouldn't add security. Say you are using a key of size $k$ for both and that each scheme can be broken in time $2^k$. To break both you need $2*2^k=2^{k+1}$ time and the same class of adversaries that can break the first can break the second.

Improve this answer
$\endgroup$
10
  • $\begingroup$ Thanks 4544, So if key size is different, there would be an increase in security? $\endgroup$
    – Jeremy P
    Commented Dec 18, 2012 at 0:49
  • $\begingroup$ Well, there would be no significant increased security(for brute force attack) than just using the stronger scheme alone. $\endgroup$
    – user4544
    Commented Dec 18, 2012 at 0:53
  • 1
    $\begingroup$ The effort to brute force any double encryption scheme is O(2^(len(k1)) + 2^(len(k2))). If the key lengths are equal, it is only a factor of two more difficult to brute force, which is an extremely minor increase in security. If the key lengths are unequal, it is more difficult by less than a factor of two of the length of the longer key. $\endgroup$
    – Stephen Touset
    Commented Dec 18, 2012 at 1:13
  • 1
    $\begingroup$ Also, this only really affects brute force attacks, and brute force attacks are essentially the least of your concerns once you have already selected an appropriate key length (e.g., 128-bit or 256-bit symmetric keys). $\endgroup$
    – Stephen Touset
    Commented Dec 18, 2012 at 1:16
  • 1
    $\begingroup$ What if they log in in a different order? Why not just generate two appropriate-length keys, give them to each user, and XOR the two for the "real" key? In any case, it looks like you're trying to reinvent secret sharing. Please be careful — you appear to be homebrewing your own extremely complicated cryptographic protocol. A complicated but badly-implemented protocol is going to be substantially more vulnerable than a simple but correctly-implemented one. $\endgroup$
    – Stephen Touset
    Commented Dec 19, 2012 at 0:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.