# 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 ...

6

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 ...

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

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

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 ...

5

This is not a mathematical proof. A notable place it fails to be a proof is here: Pay attention to which cipher text I use, look up to match the message with the cipher-number below. $$cipher1⊕cipher3=character1⊕character3⊕IV1⊕IV2$$ (Note that the cipher BOTH use the SAME KEY, but they remain secure because of the two different IV) This line is ...

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.

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

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

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

Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a Vigenère cipher instead. You can determine this is insecure with a simple algebraic combination: $\text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ... 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 ... 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 ... 2 Encryption schemes that use IVs will typically use results from previous block (or some counter combined with IV) to generate a pseudo-random bit stream to encrypt or decrypt the next block. Without an IV, the pseudo-randomness can be based only on the key and the message (because that is the only data that the sender and receiver will both have). Which ... 2 You can use your HardwareID as basis for the encryption key. If the ID provides enough entropy it'll work. However, if anyone can somehow obtain the ID (which might be quite easy to do) one can decrypt the file. For CFB-Mode the IV must indeed be unpredictable (but need not be secret), so random is just fine, but DO NOT REUSE AN IV. Encryption large ... 2 AES-CTR is very appropriate. Since a credit card number is 16 characters long, it can be encrypted using a single 128-bit block without any encoding. You will only need 1 block, and hence not require a block counter, just the nonce. Depending on the amount of card numbers being stored, you would only need to store a portion of the full nonce. A 32-bit ... 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 ... 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 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 ...

2

If the IV is all zeroes, then you basically have ECB for the first block. Basically you're proposing to use this first block's encryption as the IV for the second block. You're implying that the first block will always be unique, but low entropy, which sounds like a counter or time stamp. There are attacks when the IV is predictable, and while this is a ...

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 ...

2

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 ...

2

In cryptography an Initialisation Vector or IV is an input of fixed size required to randomize the output of a cryptographic primitive. It is not meant to be secret, so there is not problem in make it available to the attacker after the encryption. The crucial point about the IV is its uniqueness and, for some mode of operation, its unpredictability. So, if ...

2

Or does OpenSSL derive the IV by the decryption key somehow from the packet ? Well, yes. Actually, it's not that complicated; for DTLS and AES-CBC mode, the IV is the first 16 bytes of the encrypted region, so it just reads it from there, and starts decrypting from there. In DTLS, we assume that encrypted packets can be dropped in flight (or received ...

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