1
$\begingroup$

How could the following scheme be made more resilient to attacks capable of utilizing massive amounts of resources?

Assume all random values are cryptographically secure.

Key derivation: scrypt using a random 16 byte nonce. The work factor is 1048576 which takes a GB of memory and ~3 seconds to compute on a 2500k.

Authentication: HMAC with SHA-512 as the hash function. Authentication key is the SHA-512 of the AES key. HMAC checks are done using equal time compare.

Encryption algorithm: AES-256 in CBC mode using a 16 byte random IV.

Asymmetric keys are used in TLS which allows access of the encrypted data over a network. 4096 bit RSA is used due to ease of generation.

The end result of the cipher text can be described like so:

nonce | iv | cipherText| HMAC Digest

Thanks!

EDIT: Sorry guys I should have described my use case. This is for encrypting a specific file.

The authentication is used to securely ensure that the file hasn't been tampered with as well as check the key before decryption.

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ "HMAC with SHA-512 as the hash function" and "Authentication key is the SHA-512 of the AES key" rings an alarm bell for me. $\:$ An encryption key and a mac key should both be derived from the (main) key in a way that makes them computationally independent of each other; this could be done by having one be HMAC(key,0) and the other be HMAC(key,1). $\;\;\;$ $\endgroup$
    – user991
    Aug 21, 2013 at 0:42
  • $\begingroup$ I believe the reason why the answers you're getting are so all over the place is that you haven't defined the scenario fully. In particular, are you trying to implement a secure communication channel or secure file storage? If the latter, what exactly is the authentication part used for; who's authenticating what to whom, and for what purpose? What kind of resources do the legitimate users and/or servers have? Can your users securely store random encryption keys? Can they store random 256-bit keys at all, even insecurely? $\endgroup$
    – Ilmari Karonen
    Aug 22, 2013 at 14:46

2 Answers 2

Reset to default
5
$\begingroup$

All looks pretty secure except for your auth key derivation. You should use a better key derivation method like HKDF instead of just SHA-512.

I don't think your random nonce is doing anything in this scenario - an attacker who wants to brute-force a weak password wouldn't be slowed down by a nonce transmitted in the clear. Why not just use a randomly-generated AES key and a key exchange scheme? This would really confound an attacker with massive (e.g. nation-state level) resources. The NSA would laugh at your puny attempts to use scrypt to slow down brute-forcing.

EDIT: Wikipedia's article on Diffie-Hellman key exchange should get you started.

Improve this answer
$\endgroup$
5
  • $\begingroup$ At that point the key really doesn't need to be pushed any further by my reckoning. I'm already using scrypt at a very decent work factor to derive the initial key so the usage of SHA-512 is just to ensure a difference between the aes and HMAC keys. The nonces are required by scrypt and CBC mode so I really can't remove them. Could you perhaps link me to an explanation of such a scheme? $\endgroup$
    – Everlag
    Aug 20, 2013 at 22:09
  • 1
    $\begingroup$ CBC mode doesn't require a nonce. I'm saying scrap scrypt entirely and use a truly random key transferred using a key exchange scheme. $\endgroup$
    – pg1989
    Aug 20, 2013 at 22:10
  • $\begingroup$ Sorry, I mixed nonce and iv together. I meant that CBC needs the random IV and that scrypt is the one that requires the nonce. A random key transferred using a key exchange system? I'm not sure I'm on quite the same page as you. Scrypt is used to derive a key from a user. $\endgroup$
    – Everlag
    Aug 20, 2013 at 22:12
  • $\begingroup$ Okay, now I have a better idea of what you are talking about. Could you perhaps point me towards an example/explanation of such a key derivation scheme? It sounds interesting but I'd need more info to see if it is even possible to implement using the environment I have access to. $\endgroup$
    – Everlag
    Aug 20, 2013 at 22:23
  • 2
    $\begingroup$ No, there's no derivation at all. You use a true RNG to get a random AES-256 key, then use a public-key scheme to exchange it rather than re-derive it. $\endgroup$
    – pg1989
    Aug 20, 2013 at 22:49
3
$\begingroup$

The #1 thing you can do is: don't derive your keys as a function of a password/passphrase. That's a security breach just waiting to happen. Using something like scrypt mitigates the risk somewhat, but by no means does it eliminate the risk. This is likely to be the weakest link in your cryptographic scheme.

Instead, use a truly random value as your cryptographic key. That'll make a significant difference in the security of your scheme in practice, given what we know about how humans choose passwords/passphrases.

Improve this answer
$\endgroup$
4
  • $\begingroup$ If i'm utilizing truly random keys, how can I insert the user's password/passphrase into this equation? If I do the obvious thing and encrypt the random key with the scrypted password I'm back at where I started as long as the encrypted random bytes are distributed alongside the ciphertext. Could a scheme where the encrypted random bytes are saved as a secondary authentication mechanism work? This splits them from the ciphertext at the least and If I make the true encryption key the hash of the password concatted with the random bytes... could that work? $\endgroup$
    – Everlag
    Aug 21, 2013 at 4:13
  • 1
    $\begingroup$ @Everlag, the short answer is you can't: you need to rely upon something more than just a passphrase. The simple answer is to use public-key key exchange as others have suggested (e.g., like SSL). Or, maybe you need secure storage somewhere (where the private key can be stored securely; possibly encrypted under the passphrase); maybe you need a hardware device or token or smartcard; maybe you need something else. It's hard to tell you what the best approach will be, without knowing anything of the application requirements or restrictions or goals beyond that you want very strong cryptography. $\endgroup$
    – D.W.
    Aug 21, 2013 at 4:40
  • 1
    $\begingroup$ @Everlag: $\:$ You can "insert the user's password/passphrase into this equation" by using PAKE. $\hspace{.55 in}$ $\endgroup$
    – user991
    Aug 21, 2013 at 9:01
  • $\begingroup$ @RickyDemer: PAKE (Password Authenticated Key Exchange) works great if you're doing a key exchange; that is, if you have two parties that can exchange messages; it doesn't really work for file encryption (which he finally mentioned he's doing). $\endgroup$
    – poncho
    Aug 22, 2013 at 21:28

Your Answer

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

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