3
$\begingroup$

I'm trying to define key and IV lengths for every of this methods: https://developer.android.com/reference/javax/crypto/Cipher.html

Also I still can't understand IV. If I will use 128-bit key with 128-bit IV so it will be 256-bit protection. Can I initialize Cipher with 256-bit looong key only (without IV)? Is IV necessary element for some methods?

$\endgroup$
10
  • $\begingroup$ No, IV*Cipher doesn't apply. You need properly long key and properly long IV (which might have more requirements depending on mode). Only ECB doesn't need IV, but it's insecure. Read up on those topic, otherwise you will likely void any security with your implementation. $\endgroup$
    – axapaxa
    Mar 8, 2017 at 16:52
  • $\begingroup$ @axapaxa I already understood it from knbk's answer, but what do you mean under «proper length»? How can I understand which is proper here? $\endgroup$
    – Daimonium
    Mar 8, 2017 at 17:21
  • 1
    $\begingroup$ That class in that version of Java (if we can legally call it so?) supports 5 symmetric ciphers, which mostly have different key sizes, in multiple modes, which have different IV requirements; several PBE (password-based) ciphers which aren't given the key at all but instead a password, salt, and iteration count and possibly IV; and 1 asymmetric cipher RSA which uses much larger keys but in effect not all the bits in them, no true mode (although base Java used ECB as a dummy mode), and no IV. An explanation for 'every of this methods' won't fit on stackexchange. $\endgroup$ Mar 9, 2017 at 6:34
  • 1
    $\begingroup$ AES uses one of three key sizes, see wikipedia, unless Android kept Sun/Oracle's obsolete export policy. DESede (aka triple-DES 3DES etc) might use two sizes, see wikipedia, depending on the provider. Blowfish and RC4 use variable size and RSA uses variable length but constructed in a specific mathematical way, see wikipedia. DES uses 8 bytes but not all the bits, see wikipedia, but is broken and shouldn't be used. For PBE as I said you don't directly provide the key at all. And when an IV is used, depending on cipher&mode, it should not be chosen with or like the key. $\endgroup$ Mar 10, 2017 at 14:01
  • 1
    $\begingroup$ Yes key size/range depends only on algorithm. For AES-the-standard 256bit key and 128bit IV is indeed possible and reasonable for modes that treat IV as a block, which is true for all in that Android list except ECB (which uses no IV at all). My only caveat is the possibility I noted that Google kept the silly export policy created by Sun and continued by Oracle; I don't see any reason they should but I don't do Android dev myself and don't know for certain. $\endgroup$ Mar 13, 2017 at 0:07

1 Answer 1

5
$\begingroup$

No, a key and IV give very different security properties, and you can't compensate a weak IV with a strong key, or the other way around.

First of all, a small misconception: a 16-bit number can have $2^{16}$ possible values, and combining them gives $2^{16} \cdot 2^{16} = 2^{32}$ possible values, or a 32-bit number, not a 256-bit number.

An IV or initialisation vector is used to prevent chosen-plaintext attacks. Without an IV, encrypting a specific plaintext with a specific key will always yield the exact same ciphertext. An attacker can use this to its advantage by asking an encryption oracle to encrypt a plaintext that the attacker guesses. If the ciphertext matches the original encrypted message, the attacker knows that the chosen plaintext is the text that was originally sent.

An IV will change the ciphertext each time a message is encrypted, even if the key and plaintext are exactly the same. It is important that the IV is unpredictable before encrypting the text, but it does not have to be a secret after the text is encrypted. Even if the attacker knows the IV for a specific message, when the attacker asks the encryption oracle to encrypt a chosen plaintext, the IV will be different, so the attacker can't verify that the original message was the same as the guessed plaintext.

No matter how strong your encryption key is, it won't protect against this kind of attack.

Similarly, a long IV won't protect against a weak key. Since the recipient of the message needs to know the IV, it is usually send in cleartext along with the encrypted message. Now an attacker only has to guess the key, so if the key is weak and the attacker guesses correctly, s/he can actually decrypt all messages that use that key.

$\endgroup$
4
  • $\begingroup$ For most operations of operation, having an identical IV also breaks security of messages that are partially identical or related. The security aspects and required number of bits for the IV depends heavily on the mode of operation of the block cipher. For CBC it needs to be 16 bytes and random, but other modes may have different requirements for the IV. $\endgroup$
    – Maarten Bodewes
    Mar 8, 2017 at 12:49
  • $\begingroup$ So I should append IV to the message, right? It seems to be clear now, but how can I understand which length of key and IV is suitable for every algorithm which is described on Android Developers page? $\endgroup$
    – Daimonium
    Mar 8, 2017 at 14:01
  • $\begingroup$ No, it doesn't stick IV automatically. Sorry, but I would like to know exactly which lengths is permitted to every algorithm. That's the main question. $\endgroup$
    – Daimonium
    Mar 9, 2017 at 5:59
  • 1
    $\begingroup$ The Java Cipher API does not concatenate IV to (or split it from) ciphertext; caller must handle that if desired, as it often is (and several Qs on SO are from people who failed to). Java does concatenate and split the auth tag for AEAD, but from the list given the Android provider(s?) doesn't (currently?) support any AEAD modes. $\endgroup$ Mar 9, 2017 at 6:39

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.