1
$\begingroup$

I am developing an app where the following cryptographic system will be in place:

  • Elliptic Curve key exchange (curve: secp521r1)
  • Double Scrypt the shared secret with different salts
  • Pass this result through Argon2 with another salt
  • Encrypt the data using AES 256 and the key from Argon2 (and an IV)

I was wondering whether at the password hashing and KDF stage there was any weaknesses of using double Scrypt then Argon2?? If so, what would be the solution to improve the security of the hashing?? Thanks

Improve this question
$\endgroup$
4
  • 4
    $\begingroup$ are you applying Argon2 on a random key from key exchange? That seems pointless. You should have sufficient randomness in the key to begin with, if it just comes out the wrong shape, a simple fast hashing algorithm will bring it to be the size you want for AES key. KISS $\endgroup$
    – Meir Maor
    Commented Jul 7, 2019 at 9:36
  • 1
    $\begingroup$ @SamG101 When we start learning about cryptography we tend to make two common mistakes: first, "I can invent my own stuff that will be amazing" (amazing to us), and secondly, "more is better and more complex is better". Strike two. $\endgroup$
    – Patriot
    Commented Jul 8, 2019 at 4:23
  • $\begingroup$ @Meir Maor, ok I will use sha3 to convert the shared secret into the correct format for AES encryption, as it is a fast hashing algorithm. However, sha3 doesn't produce the correct length key, so is it advised to truncate a hash or use a HKDF to produce a key of the correct size? Cheers $\endgroup$
    – SamG101
    Commented Jul 13, 2019 at 13:29
  • $\begingroup$ you can safely truncate sha3 for the purpose of producing an encryption key provided the input for sha3 had sufficient entropy to it(at least the size of the key) and in your case that should be the case. $\endgroup$
    – Meir Maor
    Commented Jul 13, 2019 at 14:36

2 Answers 2

Reset to default
12
$\begingroup$

This home-made construction is pointless and unnecessarily complex, Complexity is often the source of vulnerabilities. In this case, for example, I’ll wager you’re not securely handling the intermediate variables as you chain the multiple password hashes together.

Simply use argon2 only and increase the work factors. “Double scrypt” is fairly meaningless as scrypt also has work factor parameters which can simply be increased.

Improve this answer
$\endgroup$
5
  • 3
    $\begingroup$ Why should they pass the output of a key agreement process to Argon2 instead of something like HKDF? Even if passwords were the source of secrecy in the private ECC keys, then using Argon2 on the shared secret is still applying password hashing to the wrong part of the process. $\endgroup$
    – Ella Rose
    Commented Jul 7, 2019 at 15:31
  • 3
    $\begingroup$ Although I upvoted this answer, I just noticed now that it's wrong. OP does not need to "simply use Argon2". As @EllaRose says, he should be using HKDF if he needs a KDF, not a PBKDF. $\endgroup$
    – forest
    Commented Jul 8, 2019 at 0:41
  • 1
    $\begingroup$ I too upvoted and am not removing my vote, despite the current situation where your answer(@forest) below is better and has significantly lower score. I wouldn't say the answer here is wrong, but it catches only part of the mistake. $\endgroup$
    – Meir Maor
    Commented Jul 8, 2019 at 6:51
  • $\begingroup$ I assumed the “shared secret” was a password used for authenticating the key exchange, not the result of the key exchange. I guess I misunderstood the home-grown protocol. If there’s no authentication of the KEX that’s another major problem. $\endgroup$
    – rmalayter
    Commented Jul 8, 2019 at 21:52
  • $\begingroup$ @ramalaytor (replying to comment), When Alice wishes to communicate with Bob, she will generate ephemeral ECC keys. Her ephemeral public key will be signed with her permanent private key. This will be known to Bob, so he can verify Alice's ephemeral public key. I am using ephemeral ECC keys to maintain forward secrecy. $\endgroup$
    – SamG101
    Commented Jul 13, 2019 at 13:26
7
$\begingroup$

You are using the KDF wrong. The only purpose of Argon2 and scrypt (and related constructions like bcrypt and PBKDF2) is to slow down dictionary and brute force attacks against passwords created by humans. Using it on a randomly generated key exchanged using ECC is improper as the key is strong.

You are using salts wrong. The purpose of a salt is to mitigate rainbow table attacks and make parallel attacks against multiple users' passwords more difficult. It is not a magic dust that you sprinkle on your cryptosystem to make it more secure. For a randomly generated key, you don't need a salt.

This is why it's so important to use a ready-made library that does all this for you.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Ok, so I should just use a fast hashing algorithm (like sha3) to convert the shared secret from the ECC key exchange into the correct format for the AES encryption $\endgroup$
    – SamG101
    Commented Jul 8, 2019 at 7:35
  • $\begingroup$ @SamG101 Yes, SHA-3 (or SHA-2) are fine. You only ever want Argon2 for user passwords. $\endgroup$
    – forest
    Commented Jul 8, 2019 at 7:36
  • $\begingroup$ Ah ok, so I would only use Argon2 for if I was storing passwords of login accounts in a database for example $\endgroup$
    – SamG101
    Commented Jul 8, 2019 at 7:39
  • $\begingroup$ @SamG101 Yes, or if you were deriving a disk or file encryption key from a user password. $\endgroup$
    – forest
    Commented Jul 8, 2019 at 7:39

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.