# How resilient to attackers with extreme resources available is this encryption method?

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.

-
"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). $\;\;\;$ –  Ricky Demer Aug 21 '13 at 0:42
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? –  Ilmari Karonen Aug 22 '13 at 14:46

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.

-
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? –  Everlag Aug 20 '13 at 22:09
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. –  pg1989 Aug 20 '13 at 22:10
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. –  Everlag Aug 20 '13 at 22:12
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. –  Everlag Aug 20 '13 at 22:23
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. –  pg1989 Aug 20 '13 at 22:49
@Everlag: $\:$ You can "insert the user's password/passphrase into this equation" by using PAKE. $\hspace{.55 in}$ –  Ricky Demer Aug 21 '13 at 9:01