New answers tagged

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


2

If MixColumns is omitted, the following happens: The cipher essentially becomes a group of 8-bit block ciphers, that work only by subkey addition and s-box transformation. After every 3 rounds, the original bytes will shift back to their original locations, in the following pattern: Original state a b c d e f g h i j l k m n o p After round 1 a g i o f k ...


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

If you ask about the protocol itself, as a theoretical construct, then it is safe. In theory it indeed provides all the feature that it promises. And now for the "but..." part. When you use a protocol to communicate, you are actually using one implementation of the protocol. The implementation tries to do exactly what the protocol says. However you can ...


2

I would not consider your case to be a cascading encryption. The reason why is the fact you need multiple interventions before getting access to your file. Here is what I would consider a cascading encryption (let's go crazy) : $$E(k_1,k_2,k_3,m) = \text{KEYAK}(k_1,\text{NORX}(k_2,\text{AES}(k_3,m)))$$ which you would decipher with : ...


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


1

Suppose you use 128 characters out of an alphabet (this is a large alphabet). To create a key you'd need about 37 fully random characters to create an AES key of 256 bit strength. Even you would create such a password, you'd have trouble encoding it over the required number of bits. You could either use a 44 character base 64 string or 64 character hex ...


0

AES supports three key lengths. They are 128, 192 and 256 bits long. You chose to use the 256 bit algorithm that operates in CBC mode. It's a correct choice. Now all you need is: key - 256 bits long initialization vector - 128 bits long You can generate them using command I found here: openssl enc -aes-256-cbc -k secret -P -md sha1 where the "secret" ...


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


7

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


9

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


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


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.


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


0

You can use CCM or EAX mode. EAX mode is not standardized by NIST, but it uses AES + AES-CMAC as underlying primitive, implementing a secure authentication mode. You could use AES-CMAC (or EAX mode without any ciphertext and just Additional Authenticated Data) to calculate an authentication tag over the authentication tags of the blocks. Advantage of EAX ...


0

To answer your ideas of: "I use hash-then-encrypt" with CBC + SHA-1 "I use MAC-then-encrypt" with CBC + HMAC "I won't use GCM because of unclear usage guidance" First, hash-then-encrypt is a really bad idea. You really should avoid it if possible. Details are explained in this related question on Crypto.SE. Second, MAC-then-encrypt is a concept you also ...


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


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


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


1

It's also worth considering the point of a MAC in the first place, i.e. - why it should be calculated over all of the input rather than just the first block. Making the tag dependent on only the first block of the tag would allow an attacker to fill in the rest of the message with whatever they wanted, so long as the first block of CT represented a valid ...


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


0

The problem with non-authenticated symmetric cipher modes is that they are PRP's. That means that - no matter what you do to the ciphertext - you'll get a valid and unique plaintext (not considering unpadding). This means that an attacker can change (part of) the outcome of decryption by altering the ciphertext. It can also lead to information leakage, e.g. ...


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.


1

Do I really need a random IV if I salt the data? Prepending 128-bits of random salt to the data is the same as using a 128-bit random IV, right? Yes, it should do the job, but if I'm reading your question correctly you don't really have to optimize storage away, but if you want to, I'd rather recommend going with AES-128 and a 128-bit IV which is ...


0

I've converted my comment into an answer. Thomas Pornin accurately sets out why there are likely to be fixed points in AES (where for a given key K, there is a plaintext which equals the ciphertext). Let me explain why there is no key K where the plain text equals the ciphertext for all plaintext inputs (i.e. there is no identity key). This is not a ...


1

We solved this problem in just 9 hours 37 minutes. Here is how to do it. Tools you need: sudo apt-get install cryptsetup sudo apt-get install dh-autoreconf sudo apt-get install libcryptsetup-dev 1 - Dump the encryption header of your device using cryptsetup toolset, here /dev/sda1 was our device yours could change: sudo cryptsetup luksHeaderBackup ...


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


1

If I understand correctly: You have a 256-bit master key $K0$ Generate a random 128-bit value $N0$ and set the last bit to 0 Generate a 256-bit keystream $K1$ using $E_{K0}(N0)$ || $E_{K0}(N0 \oplus 1)$ Generate a random 96-bit value $N1$ Using $K1$ as the key, and $N1$ as the nonce, encrypt your message with AES256-GCM, and authenticate $N0$ as associated ...


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


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


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


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


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


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.


0

While an eight digit search space is easily iterated, the default settings for LUKS/cryptsetup use a password hash that takes 1s to compute (PBKDF2-SHA1 with iterations chosen to reach that time). That means a brute force of eight digits would take $10^8/60/60/24$ days or over three years on that hardware. If you assume a GPU is ten times as fast, you will ...


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


0

yes, in the same way the hash of a password does help you recovering the password. If you have the hash you can test against it. This doesn't mean that the recovery is doable in a reasonable amount of time


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


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


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


0

You might want to call out to libsodium instead. It provides password hashing and authenticated encryption built-in, with a very clean API that is easy to use correctly, as long as you remember to choose a fresh nonce every time you encrypt. It will also be faster than AES+HMAC, and uses Argon2 for password hashing, the winner of the Password Hashing ...


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 .


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


1

I did not paid attention enough when reading the paper. The figure 2 illustrates the operation: So after the computation of $S'$ and $M$, at the first round, the $\texttt{AddRoundKey}$ step stay the same but in addition, the round key is xored with $n$. So if the block data is $x$, after the first $\texttt{AddRoundKey}$ we get $x \oplus k \oplus N$ (where ...


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



Top 50 recent answers are included