0
$\begingroup$

Given some intervals of long integers (64 Bits). I need to generate alphanumeric strings which:

  • should be used like passwords(known only by few individuals)
  • must always be the same for the same integer
  • must always be different for different integers
  • must not be easily to be created for another integer if they are known for some integers

Until now that is implemented by using AES-256-encryption using a fixed nonce and Base62-encoding the result.

Example-Pairs:

        262238999990755L/"U20r97pqmJvmHXDFusePv"
        262231199990754L/"4glfYQz77IbXqXJKnxJR2g",
        262232929990753L/"7ZvHRx4W72GLOpDfSy2Kr6",
        262233999390752L/"1MWaro0TzsM6LjCqVfzT2b",
        262234699990751L/"1tW5x0sWY9Z4g4Ltrnjkn2"

How easy is it to figure out the AES-Key and fixed nonce used to generate the string? Or: How difficult is it to generate the password for another long integer?

How much would that improve if I used the integer itself or a hash of it as nonce?

Improve this question
$\endgroup$
6
  • $\begingroup$ AES itself doesn't use use nonce, which AES mode of operation are you using? How do you convert from a 64 bit long to bytes? $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 1, 2022 at 15:29
  • $\begingroup$ Hmm, strange. Using the java-std-library selecting AES/CBC/PKCS5Padding: If I don't provide a what is called iv (16 bytes), each encryption produces a different result. I thought that would be a nonce. Conversion of long to 8 byte-array is done doing binary ops (shift left, and 0xFF) most significant byte first. $\endgroup$
    – aschoerk
    Commented Sep 1, 2022 at 16:54
  • 1
    $\begingroup$ Ah, OK, so CBC mode. CBC uses an IV, but not a nonce. nonce means "number used once". CBC needs such an input but it requires that value to be non-predictable - so the IV has more requirements than just being a nonce. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 1, 2022 at 17:05
  • $\begingroup$ That means it would be better to use a constant secret value, than a calculated but always different one? $\endgroup$
    – aschoerk
    Commented Sep 1, 2022 at 17:20
  • 1
    $\begingroup$ An even better choice might be to not use AES-CBC and instead use a Key Derivation Function. E.g. HKDF, use a fixed secret 32-byte randomly chosen value as the salt, Integer To Octet String of the input integer as the IKM, and a short sentence describing the intended use of the output as the info. $\endgroup$
    – SAI Peregrinus
    Commented Sep 1, 2022 at 17:41

1 Answer 1

Reset to default
1
$\begingroup$

should be used like passwords(known only by few individuals)

Yes, that would work.

must always be the same for the same integer

True for single block encrypt using AES and using the full output. AES is a block cipher, and a keyed block cipher is a permutation, which is what you are looking for.

How easy is it to figure out the AES-Key and fixed nonce used to generate the string?

The key is protected by AES, and AES, as a block cipher, should not give any advantage to an attacker that knows input / output blocks. So the key should remain secure (as long as the cipher doesn't leak information, and the key is kept secure of course).

The nonce doesn't have any security properties in this scheme, so it can be dismissed. It will remain unknown until the key is known, and if the key gets known then it becomes easy to find it.

must always be different for different integers

Yes, that's a property of a permutation.

must not be easily to be created for another integer if they are known for some integers

Unless you know the key this is the case. You do however keep in mind that AES s not build to provide collision resistance. That means that there is a small chance that each guessed output value has a 1 in $2^{64}$ chance to have a correct input. There is only a 1 in $2^{128}$ chance to guess a good pair though (pick a long, and then guess the "result".

How easy is it to figure out the AES-Key and fixed nonce used to generate the string?

Already answered.

Or: How difficult is it to generate the password for another long integer?

Same.

How much would that improve if I used the integer itself or a hash of it as nonce?

Well, fortunately the value is padded using PKCS#7 compatible padding, otherwise it would completely destroy your scheme. It won't improve the scheme in any way.

Notes:

  • the person that has the key can retrieve back the nonce in your scheme;
  • using a HMAC or KDF instead could improve your collision resistance, at the drawback of having a larger "result", i.e. password (it would also make the function irreversible, even to those that have the password, but having a small input size of 64 bits largely negates that benefit)
Improve this answer
$\endgroup$

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.