Tag Info

Hot answers tagged

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

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


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

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

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


2

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


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

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


1

The authentication tag in GCM is generated by XORing a block cipher output with the Galois field hash (and truncating it for shorter lengths). It is thus assumed to look PRF. So it is effectively just a random nonce that should not collide until a birthday bound of $2^{t/2}$. With a tag length of 96 or more bits, it should be secure. Shorter random IV ...


1

Using the same key and IV for different, independently encrypted cells is a bad idea, regardless of which encryption algorithm you use. It would allow attackers to find either XORs of cells (with CTR) or at least equality of prefixes (with CBC). If you are going to use authenticated encryption, you need to choose whether the MAC applies to each cell ...


1

There's no practical difference between zero IV and any other constant IV here. With some older ciphers that have a small enough keyspace (or weaknesses that allow reducing it) you could have a rainbow table for the encryption of the zero vector which might make zero IV a weaker choice in some cases, but that would be impossible for AES with its 128-256 bit ...


1

Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ...


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

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


1

For CBC mode, the IV can be generated in any manner where it would be unpredictable to an attacker from one message to the next. In practice that means a random number generator of some kind. Since the block size is 128-bits, the probability of IV repeat before the key expiration is negligible. The CBC IV is visible to an attacker viewing your ciphertext; as ...


1

It would really help to see the encryption and decryption code, as used by your program. The Handling of the IV does not seem right. The IV has the size of the block of the cipher used in conjunction with CBC. Thus it should probably be 16 bytes in length. Additionally you have to use the RAW bytes for CBC and not its Base64 representation. In order to ...


1

For CBC encryption, you would store the initialization vector as the beginning of the ciphertext, regardless of whether you read in an IV or generated it yourself. The CBC decryption algorithm would do what you described at the end of your post. Your implementation should also offer access to the block cipher itself, without any mode of operation.


1

It just leaks information about the blocks with the same IV. Specifically, if the two messages encrypted with the same IV started with blocks $M_0$ and $M'_0$, then the attacker learns the value $M_0 \oplus M'_0$ (and if those where the same, then the attacker also learns the corresponding xor with the second block, etc) However, the attacker learns ...


1

First, you have to know what padding you are using. In the padding, you will find the padding length. Second, you should set the padding type in the library. Third, removing and validating and using padding is tricky and can lead to some padding oracle attacks. In essential, the attacker modifies a block, which is likely to result in wrong padding and a ...


1

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



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