Tag Info

43

In the "ideal cipher" model, the block cipher is a permutation of the space of input blocks, chosen uniformly among all such permutations. A plaintext that gets encrypted to itself is a fixed point for the permutation; it is expected that about 63.21% of all permutations have at least one fixed point (a permutation with no fixed point is called a ...

16

There are two important differences between AES-128 and AES-256: AES-128 has 10 rounds, AES-256 has 14 The key expansion process (that is, how they generate subkeys) is different If your AES-128 encryption hardware just takes a plaintext block and a 128 bit key, and produces a ciphertext block, well, no, there's not much you can do. In this case, the ...

13

The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks.

12

You have clarified the question as asking about whether replacing ShiftRows with a random byte permutation would strengthen AES against differential attacks. It would not. ShiftRows and MixColumns were carefully selected to work in tandem, such that every byte affects every other byte in the state within just two rounds. MixColumns ensures that every ...

8

It depends how the “AES-128 encryption hardware units” you mention are actually defined. I've already encountered processors that allow to independently compute AES operations such as $\texttt{SubBytes}$ and $\texttt{MixColumns}$ – which are the same regardless the key size involved (128 or 256 bits). In that case: yes, it can speed up the calculation for ...

7

This is terrible. In GCM, if you use the same nonce, then the authenticator is completely broken (for all messages in the future). You should never assume that the attacker doesn't know the filename either. You MUST use different IVs.

7

The practical answer is "not really". With that said, here's a more nuanced answer: If you only have a single AES-256 plaintext/ciphertext pair (one block, that is), it's not actually possible to bruteforce the key. AES has a block size of 128 bits, so the probability of any given key having that plaintext/ciphertext pair should be $2^{-128}$. That number ...

7

The fastest block cipher is identity, which leaves input blocks completely unchanged. This is infinitely fast on all platforms; however, it is not secure. So maybe you want the fastest block cipher that still offers some given non-trivial level of security? Then it depends a lot on what you want to implement the block cipher on. With recent PC, you would ...

7

I assume that you mean the S-box. The answer is NO! Randomly chosen S-boxes are not good choices for differential and linear cryptanalysis. When Biham and Shamir presented differential attacks on DES, one of the things that they showed was that if you replace the S-boxes in DES with randomly chosen ones, then the differential attack becomes much more ...

7

Do all TLS cipher suites using "ChaCha20-Poly1305" use Poly1305-AES? Nope, AES is indeed replaced with ChaCha20 in TLS. The Poly1305 one-time key is generated pseudorandomly using the ChaCha20 block function. The ChaCha20-Poly1305 TLS cipher suite spec draft uses the AEAD construction from RFC 7539, which defines exactly how this works: The ChaCha20 ...

6

In my own knowledge, encrypted data can't be decrypted without knowing the key, but BitLocker breaks it. That description indicates you might have misunderstood something there. Bitlocker does not break anything* as Microsoft BitLocker uses recovery keys (read again: “keys”), not code! The related code for recovery is pretty similar to the usual ...

6

Is Rijndael the fastest block cipher in the world? No. On an Intel 64 Sandy Bridge without AES-NI, AES (a subset of Rijndael) is outperfomed by ChaCha20 (and also likely by Threefish 512 which has about 6-7cpb cost on an older Intel Core 2 Duo with 64-bit ASM (link: original Skein paper PDF)) as opposed to AES' 11 cpb. (7.59 cpb on an Intel Core 2) ...

4

Quoting from FIPS 197 (PDF), on page 11: Rcon[] The round constant word array. So, the answer is obviously "round constant".

3

First of all, the usual way to do this is to generate a new random AES key and then wrap it with the public key. Generally you don't encrypt with the private key at all. Yes, SHA-256 is a one way hash so you can do this. The problem is that you would still need to encrypt with a public key to let the other party know the AES key (unless you use the key to ...

3

Would these steps result in a suitable pair of keys for AES-encrypt-then-HMAC-authenticate? Yes. That would be fine. It almost is HKDF-Expand, in fact. However, as you note, by deriving the two 256-bit keys from a 160-bit key your effective security will "only" be 160 bits, since an attacker could brute force the intermediate key. That is not at all a ...

3

In your link next to the cipher suites with poly1305 you find a link to http://www.iana.org/go/draft-ietf-tls-chacha20-poly1305 That in turn links to rfc7539 which in Section 2.6 describes generating the key for poly1305 using chacha20. So my answers would be: No. It is being used so it's probably and hopefully not a problem.

3

As you know, it makes reading and writing the disk very slow if all the data in the drive is chained together. If so, writing to a drive of size $n$ at position $p$ will require $\Theta (n-p)$ time. One solution is the drive being divided into sectors, and each sector being chained. The IV of each sector can be attained using ESSIV. it generates IVs from a ...

3

PBKDF2 alone would be bad for step 4, since the blocks of its output can trivially be computed independently. ​ If the PBKDF you use can't directly produce enough output, then you should compose with a fast key-based KDF. Make sure that the IV is part of step 9's ciphertext and step 5 of decryption is constant-time .

3

RCon == Round Constant It's a value that slightly modifies how each round operates. Without it, AES might be vulnerable to a (related key) slide attack. Such an attack would probably not be of practical interest, however since it's so easy to avoid it (by including the RCon), it makes sense to.

3

"Given the above assumptions and limitations, is the encryption scheme still secure?" No; the attacker can remove blocks of [IV + rest_of_ciphertext] from either end to remove corresponding plaintext blocks without affecting any other part of what it decrypts to change the IV to change the initial plaintext block in the same way as for the OTP, without ...

3

A slight correction about terminology: The key is constant when you use CTR. The IV/counter affect the cipher input and so the keystream varies. The reason this can be decrypted is that the decrypter knows both the key and the IV/counter. They can calculate exactly the same function as the encrypter did, resulting in the same keystream block, which a XOR ...

3

Just use AES. It's hardware-accelerated and implementations have had ages to have flaws discovered and patched. More strongly, just use GPG to encrypt data at rest and just use TLS (>= 1.2, with appropriate AEAD ciphers) for data in motion. "If you're typing the letters A-E-S into your code, you're doing it wrong." Anything you build yourself is infinitely ...

2

Given some intermediate data $x$ as two shares $x=x_1\oplus x_2$ take some fresh random $r$ to calculate new shares $x_1' = ((x_1\oplus r)\oplus x_2)\oplus(n\oplus r)$ [parenthesis indicating the order of evaluation] and $x_2' = n$. Now you can use $x_1'$ ($=x\oplus n$) as input for both tables. The answer to "So how should it be computed?" is not at all. ...

2

First of all, you should make a more formal definition of the protocol. Security cannot be assessed without a proper definition. Second you don't specify an key sizes. RSA-512 is such a low key size that it may be considered broken. On the other hand, you may run into performance issues if you choose a higher key size (Elliptic Curve crypto would make more ...

2

How does value of $p$ comes to $2^{512}$ for security complexity of $2^{72}$? Personally, I couldn't connfirm this number, but rather landed at $2^{66}$. If you don't know how to find this number, just plug the $2^{512}$ into the complexity equation given and take the logarithm to the base two for better readability. Note that Schnorr's complexity ...

2

As I read the comments on your question, I felt like I might react to it, even though it is not a formal answer. First, you seemed to wonder why you got some downvotes - I agree that downvoting without explaining why is far from useful. So, let me try to explain what might have provoked those negative reactions in your questions (I'm not saying that this ...

2

If attackers can strip off RSA / EC / -DSA digital signature and conduct CCA on AES-CTR or CBC payload, why can't they do the same for AES-GCM? The scenario, you're talking about is iMessage or Signal Protocol or other protocols which allow optionally to sign the ciphertext and thereby don't MAC it. The problem here is a) that you could replace the ...

2

To fully answer your question, let me go over the exact way in which CTR mode works. Following the diagram below: CTR mode takes in a 96 bit nonce and a 32 bit counter that is incremented with each block. This 128 bit value is then put through, let's say AES encryption, with either a 128, 192 or 256 bit key. This same key is used with every block. A ...

2

I would say thats not safe. GCM works as CTR, so an attacker that knows (part of) the plaintext version of the file name can compute the beginning of the file as plaintext. If you XOR the two encryption, you'll have the XOR of plaintext, and if you know the filename, you'll get the (beginning of the) file. To securely encrypt the filename you'll need a ...

2

I think it's OK in this instance: an attacker cannot check the first half of the hash (160 bits) because he cannot use AES-256 yet; the key is incomplete. So he needs to run the second half too. He needs the full key to check the decryption. The OWASP guide refers to the case where the output of the PBKDF2 function is stored directly as the hash-check in a ...

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