# Tag Info

1

Since this is still open and the issue keeps coming up: TLDR: There are lots of things in OpenSSL that implement standards including AES, but the key derivation part of enc is partly nonstandard First, OpenSSL has several commandline operations it calls commands (although they usually aren't separate programs, as typical commands are on Unix), and a whole ...

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

2

If you use a random IV each time you encrypt a file, the result will be different. $$\text{AES-CBC}(IV_1, Key, M) = C_1$$ $$\text{AES-CBC}(IV_2, Key, M) = C_2$$ you do not gain any pieces of informations by having $C_1$ and $C_2$. Even knowing that they share the same key and should they share the same length, an attacker can not even know whether or not ...

4

Yes, in case of VeraCrypt there is a difference, but it is negligible in practice. First we need to consider how VeraCrypt actually performs the cascading of the encryption algorithms which is (literally) a block-wise chaining. E.g.: $$C=E_{XTS}^{1}(E_{XTS}^{2}(E_{XTS}^{3}(M)))$$ where each $E$ is a block cipher run in XTS mode and all using the same XTS ...

7

In addition to the other answer Using asymmetric cryptography in the meters would have some benefits: it can make passive eavesdropping of meter/server communication useless, even to a party holding or able to use the server's private key; something not achieved with secret-key cryptography. it can ensure that any central key leak can not compromise the ...

3

If the central key database is hacked, does an attacker is able to decrypt the communication of any meter? To tamper it? Indeed, if the central key database is hacked, then an attacker will know all the secret keys and so will be able to decrypt all communications. Why not choosing an asymmetric public key mechanism instead, where the central ...

3

From what I understood, data units are sectors, so a sector can have at most $2^{128}-2$ blocks but you can only encrypt $2^{20}$ blocks which cannot be correct (it seems too little compared to a disk's capacity). The data unit is the sector, yes, but both of those quotes only talk about the length of a single data unit. The larger number in the latter ...

1

The entire premise of modern ciphers is that they're indistinguishable from random by a computationally-bound adversary. If you believe the assertion that a modern cipher is secure, then it follows that you believe you cannot reliably distinguish it from randomness. If you share a secret key with your clients, what you can do is verify a MAC over the ...

3

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

0

Is it safe to generate IV along with KEY from PBKDF2 when using and storing salt for each user or should IV also be randomly generated and stored along with salt? When generating IV from PBKDF2 I'm basically choosing for it to be part of the key, ie a secret. Using a sufficiently large salt per user would guarantee that no two generated KEY/IV pairs ...

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

1

The main advantage I have heard is reducing the amount of data the client has to send to the cloud. As said in A Comparison of the Homomorphic Encryption Schemes FV and YASHE: [...] ciphertext expansion (i.e. the ciphertext size divided by the plaintext size) of current FHE schemes is prohibitive (thousands to millions). For example using ...

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

6

Does it matter WHICH bit I'm flipping? Is it legit to always flip the MSB f.e. or should it be a random position? If you see the cipher design as a black box then certainly yes. It could well be that the design would be more secure for certain positions than the other. This would indicate a (local) weakness. Note that the Hamming distance is just one ...

0

Here is such a protocol. Alice chooses a random AES key $K_a$, encrypts it using Bob's public key to get $C_a = \mathrm{Enc}_{pk_b}(K_a)$, and sends $C_a$ to Bob. Likewise, Bob sends $C_b = \mathrm{Enc}_{pk_a}(K_b)$ for a random AES key $K_b$. Upon receiving $C_a$, Bob recovers $K_a = \mathrm{Dec}_{sk_b}(C_a)$ and computes the shared AES key $K_{ab} = ... 3 I'm not sure about your definition, so let's take branch number in terms of the byte-wise differential branch number, i.e. the branch number of a function$F(x)$is $$\mathcal{B}_{F(x)} = \min_{a,b \neq a}\{ w(a \oplus b) + w(F(a) \oplus F(b))\}$$ where$w(x)$is the number of non-zero bytes in$x$. In this case, the branch number of the Twofish round ... 1 After trying all the possible inputs with Hamming Weight of 8 and below from the space of 2^64, it seems that MDS + PHT combined achieves branch number not less than 8. Since there was no output which had Hamming Weight of 0 in case of Input Hamming Weight from 1-7, MDS + PHT combined will never attain Branch Number less than 8. 1 Basically there are two ways: decode the counter to be a big number in some kind of library, increase that number, then encode it back as unsigned, statically sized, big endian value, making sure you left pad with zero valued bytes when necessary; increase the value of the right-most byte (highest index) as unsigned number, if the resulting value is zero ... 3 This is a type of chosen-plaintext attack, where the adversary gets partial choice of plaintexts — they can cause the same substring to be encrypted multiple times. AES-CTR, if used properly, is resistant to chosen-plaintext attacks. Used properly, for CTR mode, means that the same counter value must not be reused for different messages. For example, if ... 1 The main complexity of attacks using a quantum computer with Grover's attack is explained here. I'll use the remainder of the answer to indicate some possible misconceptions in your question. It's hard to say exact QC specs, but let's assume we have decent a quantum computer using Grover's algorithm that is able to half AES-128 keyspace to that of ... 4 You can (and should) do the reduction in constant time using masking. That is, instead of using the following (non-bitsliced) pseudo-C code to do the reduction: if ((result >> 8) & 1) { /* bit 8 is set: clear it and flip bits 0, 1, 3 and 4 */ result ^= 0x11b; } you can simply do: result ^= 0x11b * ((result >> 8) & 1); ... 10 There is no such thing as a 16 bit AES key. AES is a block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits. As a block cipher, AES can only encrypt 16 bytes (128) bits at a time. AES in itsef is not (CPA) secure as repetition of the plaintext would lead to repetitions of the ciphertext. To encrypt larger amounts of data, AES ... 5 TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy. In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called ... 0 No, it is not possible. The encryption step of CBC is$c_i = E(c_{i-1} \oplus p_i)$. When you double encrypt, the previous block ciphertext gets XORed with an independent block cipher output. The only place where something weird could happen is the beginning. If you assume that the (identical) IV$I\$ is prepended to the ciphertext, as is common, you get ...

1

The speed of a cipher actually depends on lots of factors, including: The specific hardware platform you're considering (CPU architecture, instruction set, number of cores etc). Implementation details. Compiler flags used. Some ciphers have a large initial overhead due e.g. to a slow key setup; as a result they are slow when encoding very small messages. ...

Top 50 recent answers are included