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

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

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

4

There are many reasons why the IV could be expected as an input parameter: it could be to let the user use his/her own random number generator, possibly because the device has none (as G_G has already stipulated) it could be to allow for creating larger ciphertext (as ArtjomB has already mentioned) by using the IV to contain the last vector it could be to ...

4

It offers more flexibility in using that API. Having a separate IV parameter enables bigger plaintexts than would not be possible in a single invocation, because of for example memory restrictions. I assume CBC is used. You generate the IV and invoke the encryption on the first part of the big plaintext with the generated IV. For every other part of 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 Yes, it is correct. Just follow the bits in the decryption pictures on the Wikipedia page about modes of operation. Modes of operation don't have to have a meaning compared to other modes of operation. I don't see CFB or OFB used too much anymore. OFB with partial feedback has been shown to be less secure, so that shouldn't be used anymore. Currently the ... 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 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 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 ... 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 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 ... 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 Aren't$IV_1$and$IV_2$public in TLS 1.2 as well?$IV_1$certainly is (as that's just the ciphertext block in front of the block we're attacking); however the IV that the TLS 1.2 sender will use for the next message ($IV_2$) is not. In fact, the sender might not know it yet, as it might not have not picked it yet. But doesn't this mean that BEAST ... 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 I cannot prove that your scheme is secure, but as far as I know, a non-cryptographic hash function would work fine as there is an infinite number of inputs to any given hash, making it impossible to bruteforce all but the shortest messages (which would be an issue for short messages, you may want to append some sort of 128-bit padding). However, that said, ... 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 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 ... 1 A predictable nonce that cannot be controlled by the adversary is safe as a CFB IV (with some assumptions), as shown in the other answers. However, a nonce that can be chosen by an adversary is not safe against chosen plaintext attacks, as shown in Evaluation of Some Blockcipher Modes of Operation (page 36): Assume s = n. The adversary asks its oracle to ... 1 It is secure. The IV only needs to be indistinguishable from random to an attacker, and it is as long as the salt is random. There is one remark: if you extract more key + iv bytes than the hash function in PBKDF2 returns then the PBKDF2 function is executed twice. An attacker however only has to find the key, not the IV, so an attacker doesn't have to do ... 1 Generating the IV for CBC mode by encrypting a counter is one of the IV generation methods recommended in NIST SP 800-38A, Appendix C: "There are two recommended methods for generating unpredictable IVs. The first method is to apply the forward cipher function, under the same key that is used for the encryption of the plaintext, to a nonce. The nonce ... 1 Indeed both have the aim to prevent same messages "encrypting" to the same plaintext. The difference is the context. People speak about using IVs if they want to use them in blockcipher modes, like CTR or CBC. People use the word "salt" if they want to refer to something that is stored in public but must be somewhat random and large. Usually this applies ... 1 Well, your requirements sound pretty much like standard disk encryption ones. Assuming you can assign IDs (0,1,2...) to each 4kiB sector implicitely.In this case you could simply use XTS-mode of encryption using AES. You'd then iterate through the 4kiB block using the inner counter and iterate through all sectors using the outer counter. This should give ... 1 Yes. They're called Format-Preserving Encryption schemes, and this is the best known construction of that. 1 During CBC mode decryption, each ciphertext block is first decrypted with the block cipher, and then the first decrypted block is XORed with the IV, while later blocks are XORed with the previous ciphertext block: Thus, the first block of plaintext is computed as: $$P_1 = IV \oplus D_K(C_1).$$ Equivalently, we may solve this equation for$IV\$ to obtain: ...

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