Tag Info

12

It actually leaks information. You are sending: Encrypted IV: $AES(k,IV)$ First ciphertext block of CBC: $AES(k, M_1 \oplus IV)$ Eavesdropper can observe whether the two blocks are equal, which happens iff $M_1$ is all zeroes.

9

CBC mode decryption for the first block is defined as: $$P_0 = IV \oplus D_k( C_0 )$$ where $P_0$ is the first plaintext block, $C_0$ is the first ciphertext block, and $D_k$ is the decryption by the block cipher using the key $k$. This can be rearranged as: $$IV = P_0 \oplus D_k( C_0 )$$ which allows you to reconstruct the IV, if you know the key, the ...

8

The use of the AES key many times is not a problem. However, there is a fundamental flaw with your solution. The server has no way of validating that it received the client's authentic public key. In particular, a man-in-the-middle can capture the client's public key, can forward its own public key to the server, and can then decrypt all traffic sent by each ...

8

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...

7

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. IV of any size For GCM a 12 byte IV is strongly suggested as other IV lengths will require additional calculations....

7

As SEJPM notes in the comments, the IVs will repeat after $2^{32}$ frames. This is bad (unless the key is changed more often than that). In particular, if you can temporarily capture the device and make it encrypt $2^{32}$ known messages of sufficient length, you will learn the keystreams corresponding to all the $2^{32}$ possible IVs for that device. ...

6

In this answer I'm assuming that a key is used to encrypt more than one message. The first weakness is that CBC with fixed IV leaks if messages share a common prefix. The second weakness is that it makes a padding oracle attack much more severe. Consider a device that knows the key and decrypts a ciphertext you send to it. While it won't tell you the ...

6

The scheme you describe is essentially same as the "SIV construction"* introduced by Rogaway and Shrimpton in their 2007 paper "Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem". This construction takes a PRF (such as HMAC) and a conventional IV-based encryption scheme (such as, say, a block cipher in CTR mode), ...

6

An initialization vector is, in fact, always binary. It's just random bits. So, if you choose to encode those bits as a hexadecimal string for ease of storage or transportation, that is fine. However, since it is the binary that is the IV, you will need to decode it back from hexadecimal to a binary value before using it in the decryption process. As a ...

6

the key and plaintext is the same. The attacker knows this and the IVs used but doesn't know the plaintext. Is there anything to learn about the plaintext when multiple ciphertexts are available instead of only one? No. Giving the attacker multiple encryptions of a single plaintext using a randomly chosen IV and a fixed key with AES-CBC does not leak any ...

5

The SNI extension is plain text in the ClientHello. This means that it is possible to passively snoop the value and redirect the traffic. This is already used in practice, i.e. haproxy has this feature for several years.

5

The IV of encryption schemes can be made public without damaging the security of the encryption, so there shouldn't be any issues with prepending it to the encrypted file. The difference between IVs and Nonces was already explained by @SEJPM in the comments. Note that in the case of GCM, you do need to make sure that you do not re-use the IV with the same ...

5

I want to make it harder to decrypt AES I send. Fundamentally, the thing you are trying to do is completely unnecessary. If AES does ever become broken, the scenarios in which this makes any measurable difference are exceedingly unlikely. If AES isn't broken, then doing this was wasted effort in the first place. There is zero plausible reason why your ...

5

Any of the ways you listed would work. If you're collecting alternatives, yet another one (which I have seen in practice) is to include the message counter as the AAD (additional authenticated data), which is another input to GCM. When we consider which one would be the best, we note that GCM has absolutely no requirement that the nonce be "random", or for ...

4

Yes, you can store the IV any way you want. Putting it in the file name is no different from putting it in the file contents. (Actually, there's nothing specific to cryptography here. You could take any file you want and decide to move, say, the first $n$ bytes of its content into the file name. It's all just data.) That said, as SEJPM notes in the ...

4

Most likely, the hardware engine has an API accepting an IV of 256 bits (32 bytes) and a data block of some size multiple of 512 bits (64 bytes), and returns a result of 32 bytes. Given that SHA-256 is a Merkle-Damgård hash, in order to chain invocations of that API, you want to pass the SHA-256 IV (given by FIPS 186-4 section 5.3.3) as the IV of the first ...

3

It seems you want to make the IV secret for security purposes, in direct opposition to common knowledge and NIST recommendation that non secret keying material (such as a non-secret initialization vector) be... non secret. So that goes against some of the wisdom espoused a few years ago by Bart Preneel in this video, which says that IVs should be kept ...

3

The point you highlighted (same plaintext and same key produce same ciphertext) is not a problem for a cryptanalytic point of view: you don't give any additional information to the attacker, but it is a weakness from a traffic analysis point of view. If the same ciphertext is stored in different locations or is broadcast multiple times on the network, an ...

3

Let's look at your requirements: have a large IV — specifically, one large enough that using a CSPRNG to generate a fresh IV each time is secure. Generally, IVs/nonces longer than 96 bits are thought to be okay for random generation. If it is at least 128 bits you can safely use it as long as you can a 128-bit block cipher like AES, because before you ...

3

The answer is yes. There is no problem with sending the IV in the clear. So, this is fine. Likewise, the salt is not there to add entropy so this is also fine. Having said that, I understand from the code that the application is not using a uniformly distributed (and so high entropy) key. This is a problem and very bad, since it is easy to carry out a brute-...

3

The output of the block cipher is used as the new key, and also passed to the "output block" function, which is referenced in the NIST document as $B^m_R$. The purpose of the IV $R$ and the function $B^m_R$ is to reduce the output to a smaller size in a manner that hides the true output of $f$. Too large an output allows key recovery. The output of this ...

3

The schemas from the relevant Wikipedia page really explain it all: As you see in the decryption schema, the IV is used for a single XOR that yields the first plaintext block; it is obvious that the IV impacts only that block. When encrypting, though, modifying the IV alters the first ciphertext block, then the second ciphertext block, and so on. The ...

3

Wouldn't encrypting a message with AES, then encrypting the (randomly generated) AES key and IV with the EC public key suffice? Yes it would suffice and is what is usually done. However for this to work you'd have to have a way to reliably convert a random integer to a curve point and back which isn't trivially possible. And even if you could reliably ...

3

Yes, this is secure, even though scrypt uses PBKDF2 inside. PBKDF2 has the issue that it the work factor is required $n$ times where $n$ is the number hash outputs concatenated to create the final PBKDF2 output. That means that if you can check the validity of PBKDF2 using only the initial bits (in your case used for the key if the hash was SHA-256, for ...

3

No the IV doesn't get encrypted. The IV is a random vector to make sure that the ciphertext is not identical for identical plaintext. This would leak information to any eavesdropper. It needs to be unique - and in the case of CBC, indistinguishable from random to the eavesdropper ("unpredictable") - but not confidential. As the IV is separate from the ...

3

It is the IV as a whole that needs to be unpredictable... but knowing some bits would make guessing the IV easier. The requirement of an unpredictable IV has to do with chosen plaintext attacks. If the attacker can predict the IV, they can choose the first block of plaintext such that they can verify any guesses they have for the content of previous ...

3

If you have a nonrepeating (but possibly predictable) value, you can convert that into an unpredictable CBC-mode IV at fairly minimal cost. Here's how: Prepend the 128 bit nonrepeating value to the message CBC mode encrypt the (value, message), using any IV that's not correlated to the nonrepeating value (all 0's work) Use the first 16 bytes of the ...

2

Is the above example correct? If not, how can the IV to be used for decryption be determined? Yes, it is correct. The vector/mask in CBC mode is generally the previous ciphertext block. The algorithms in 2a and 2b simply extends this notion to the IV so that the CBC mode encryption doesn't have to be re-initialized. The outcome of the IV decryption won'...

2

You can use those values more than once and there isn't much of a reason to choose another pair – except longer values for a cipher with a larger block size. The only real requirement for the values is that they differ. However, if someone found a fixed point or other cycle for MDC-2 with a given block cipher, they could choose that point as an IV and be ...

2

ECIES may seem complex, but if you try another approach, you would end up with something very much like it. If you only encrypt with AES, then you are not authenticating, which is most cases you also need to do. If you then encrypt and authenticate by yourself, you pretty much reinvented ECIES. But yes, ECIES is in higher layer of abstraction compared to ...

Only top voted, non community-wiki answers of a minimum length are eligible