6

This is mostly a theoretical question.

I am using AES128 CBC to encrypt small files. Both my keys and my IVs are randomly generated per file using iOS's secure random value generation (SecRandomCopyBytes).

1) In theory, do I need to check for any inherently insecure Keys, IVs, or key-IV combos (ex. although completely unlikely, if the Key and IV both end up being all zeroes, is it just as secure presuming an attacker does not know this)?

2) Can I rely on Apples random value generator for this?

3
  • Major issue with your approach: You're using AES-CBC and not AES-GCM, AES-EAX, AES-OCB or AES-CCM for your encryption which results in no integrity protection whatsoever and therefore an attacker could maliciously manipulate the files. – SEJPM Apr 2 '16 at 13:23
  • @SEJPM the question didn't seem to aim for integrity but for confidentiality; other than that, that's right:) – Tobi Nary Apr 2 '16 at 13:37
  • Thanks for the comments and attempted answers. I precede each file with a computed hash and then encrypt it. Obviously, reusing IVs in AES128 CBC is insecure and I am not doing this. I would just like to know if there are any known inherently weak keys. – WaterNotWords Apr 5 '16 at 5:52
1

A CSPRNG is expected to return every possible value of the image space with a probability indistinguishable from a random distribution.

Leaving certain results out would make a bad design. Think of dice. If you roll 1-1-1, you would not think that this is not random enough and sort it out - You just generated that entropy with certainty that it is real.

Doing so with an PRNG would compromise it's security, so no, there is nothing filtered out, hopefully.

Side note here: even if the probability is very small (so small as to be negligible): you are not supposed to reuse the same IV on the same key with AES-CBC, as to not leak anything if your files share structural information

Other than that, you should be fine with your approach. Every call to SecRandomCopyBytes you may consider a dice roll, for all you care about, as it's the best entropy you are going to get.

If your aim is not only confidentiality but also data integrity, you would be better off using another mode of operation as pointed out in the comments. I know, iOS is not very generous in giving much choice there, though.

4
  • 1
    "you are not supposed to reuse the same IV on the same key with AES-CBC, as to not leak anything if your files share structural information" the probability for this to happen should be around 2^{-128} if key and IV are chosen at random. – SEJPM Apr 2 '16 at 13:24
  • @SEJPM Right. Hence my "The probability is very small";) – Tobi Nary Apr 2 '16 at 13:25
  • Thanks. Although your answer does not speak specifically to SecRandomCopyBytes, I am also working under the assumption that what you say would be the case. So can you answer the main part of the question... are there any inherently weak IV-Key combos (aside from reuse obviously). – WaterNotWords Apr 5 '16 at 6:01
  • @WaterNotWords as of today, I know of none. – Tobi Nary Apr 5 '16 at 6:03
0

I am using AES128 CBC to encrypt small files. Both my keys and my IVs are randomly generated per file using iOS's secure random value generation (SecRandomCopyBytes).Do I need to check for any inherently insecure Keys, IVs, or key-IV combos (ex. all zeros, etc)?

So far, I do not think you can do anything about that.

Firstly, iOS's secure random value generation should not be so broken as to generate all zeros as you are worried about. Even if a random number generator is made predictable, its output can still looks quite random unless you know the trick.

Secondly, have not heard any weak keys about AES. And if there are no known weak keys (or key-IV combos), there are no ways that you can check against them.

Can I rely on Apples random value generator for this?

I think it would be OK since AES uses a 128-bit key. But if your files are really important, you can use multiple independent RNGs and Xor their outputs as the Keys and Ivs.
See wikipedia:
"The outputs of multiple independent RNGs can be combined (for example, using a bit-wise XOR operation) to provide a combined RNG at least as good as the best RNG used."

1
  • @Water Not Words A RNG should NOT filter out any certain results by design, or it could be seen as a weakness. If a RND is insecure, its core algorithm should be re-designed rather than certain values be filtered out; since it is the predictability of the next byte(s) matters, rather than a list of known "insecure" something. – Leo.W Mar 3 '16 at 21:35

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.