3
$\begingroup$

I'm making a digital-asset manager written in ActionScript 3, it will be used to manage highly sensitive information. I'm using the AS3Crypto library (which has quite a good reputation) to implement AES encryption.

When I encrypt data using the AS3Crypto library, using AES-CBC, and a 256-bit key, I'm able to successfully decrypt it with php/mcrypt using the same key/iv. That is to say, the AS3Crypto implementation seems fine.

When I use a key longer than 256-bits, I'm able to successfully encrypt it and decrypt it with the AS3Crypto library. Changing just 1 character in key causes the decryption to fail, indicating that the full key is indeed being used, and not truncated to 256-bit. However, when I try to decrypt the cipher with mcrypt, it fails (unsurprisingly, as the specification for AES states a maximum key-size of 256-bits).

My questions are, taking the below assumptions into consideration, will using a key longer than 256-bits introduce some sort of vulnerability into the encryption? And if not, will using a longer key theoretically increase resistance from brute-force attacks?

Assumptions:

  • I understand that a 256-bit key is sufficiently strong
  • encryption will only take place client-side with the AS3Crypto library, and hence doesn't necessarily need to be compatible with other implementations
  • the key is a string containing random alpha-numeric characters, and is not derived from a PBKDF
  • even if using a key longer than 256-bit is overkill, the extra security that it might offer would be appreciated
Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ There have been previous questions which show just how incredibly unnecessary a >256-bit key is for AES. In summary, the way it was explained to me was that our sun doesn't even have enough energy in an entire a year to get us close to cracking 256-bit encryption. It's a physics restriction in addition to the computationally expensive restriction. $\endgroup$ – JZeolla Dec 19 '12 at 14:36
  • 1
    $\begingroup$ @Steel City Hacker: please note my assumptions: "I understand that a 256-bit key is sufficiently strong", "even if using a key longer than 256-bit is overkill, the extra security that it might offer would be appreciated". The question was about whether using a longer key could weaken the algorithm, and whether a longer key could theoretically improve resistance to brute-force attacks (say, for example, in the era of quantum computing) - it was not asking whether 256-bits is sufficient. $\endgroup$ – hunter Dec 19 '12 at 14:50
  • $\begingroup$ Yeah, I gotcha. I just wanted to make sure it was clear because "sufficiently strong" seems to be an understatement. In my opinion, if you were concerned with brute-force attacks (To the tune of >256 bit AES not being enough), and you are concerned with quantum computing throwing a brick at typical prime-based discrete encryption, I would move to something like lattice-based crypto. cims.nyu.edu/~regev/papers/pqc.pdf I am unable to answer your question directly, which is why I left a comment and didn't author an answer. $\endgroup$ – JZeolla Dec 19 '12 at 15:23
7
$\begingroup$

There is no obvious extension of AES for larger key sizes. At best, AS3Crypto may be hashing the key to 256-bits for you, but the risk that AS3Crypto is doing something horribly insecure in that case is astronomically larger than any benefit that you could gain by having a larger key size.

$2^{256}$ is so huge that the only way that it could ever be brute-forced is by finding a significant AES weakness that would likely make all AES key sizes vulnerable in any case.

Even though you currently don't have any need to use anything other than AS3Crypto, that might change and it would be nice not to have a non-standard cipher in place.

Lastly, if you really do want to exceed AES-256 security (and you are probably fooling yourself, as I think you know), you would be better off XORing with a completely different cipher like Salsa20. Tahoe-LAFS (which is written by people who know what they are doing, crypto-wise) has taken this approach as they are aiming for 100 year security: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography.

Improve this answer
$\endgroup$
6
  • $\begingroup$ I would say that, at best, AS3Crypto is using the provided key in it's entirety. From reading the code here, it looks like that's what it's doing. I understand that this is an unusual implementation, but given that it's compatible with mcrypt when using a 256-bit key, I would imagine that it's safe. All I want to know is whether it continues being safe with a longer key. Thanks for the Tahoe-LAFS link - interesting! $\endgroup$ – hunter Dec 19 '12 at 15:49
  • 2
    $\begingroup$ Via that link, on line 251 (code.google.com/p/as3crypto/source/browse/trunk/as3crypto/src/…) the code is setting the number of rounds based on the size of the key. There is other logic in that function that assumes a standard key length. I think that fact that it doesn't check the key length is a bug and, by using a non-standard one, you're using a custom variant of AES that has never been studied. $\endgroup$ – agl Dec 19 '12 at 16:08
  • $\begingroup$ Yes, using a non-standard key-length is unadvisable - agreed. Thanks so much for looking at the code. Yes, the variable Nr (num rounds) is derived from the key-length, as with the standard 128, 192, and 256-bit variants (which result in 10, 12, and 14 rounds respectively). It stands to reason that a longer key would result in more rounds (as it does in the standardised version of the algorithm). However, where is the other logic in that code that assumes a standardised key length? Data is still encrypted in 128-bit blocks with the derived number of rounds. Is there something I missed? $\endgroup$ – hunter Dec 19 '12 at 16:36
  • $\begingroup$ 256 key length not long enough!? I hope it is, I just advised people to move to it in case of quantum computing. As it stands it would take 50 Titans 3×10^51 years to exhaust the key space. Also there is practically never any guarantee anything you do yourself won't create a side channel attack or worse. $\endgroup$ – Nathan Cooper Dec 20 '12 at 10:54
  • 2
    $\begingroup$ hunter: r.e. the other code that's assuming things about the key length: I was looking at things like line 264: if( Nk > 6 && idx % Nk == 4 ). I understand what it's doing for standard values for Nk (where Nk is the number of 32-bit words in the key), but it's clearly not just the obvious extension of AES for longer keys. $\endgroup$ – agl Dec 22 '12 at 1:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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