Tag Info

1

Unless a fast AES is available on the combination of CPU and PHP instance being used (that is, something built with AES-NI), I strongly advise against using AES as the basis of entropy stretching. Number-1 rule in designing an entropy-stretching function is that it should put to the best possible use the computational resources available to the legitimate ...

-1

It's normally the best advice to use something proven and well established, such as scrypt or PBKDF2. You say you can't use scrypt, but you could use PBKDF2 and make it run long enough until you feel secure. So you decide that every time you need the password, it must take n seconds on the current system. You store the number of rounds along with the ...

2

Your key derivation function is not particularly memory hard. The second loop walks the array in order, so an optimized implementation which an attacker would use can avoid the whole array, keeping only some elements in memory at a time. For example, you can halve the memory use by only storing the second half of M initially. Then for the first N/2 ...

3

To randomly guess a single key from a 128-bit key space has a chance of 1 divided by the number of elements or $\frac{1} {2^{128}}$ where $2^{128}$ is the number of keys possible. To get ballpark figures to convert between base 2 exponents and base 10 exponents you can use the following trick: Because $2^{10} = 1024 \approx 10^3$ you can easily count the ...

0

This essentially amounts to an encrypted nonce, which NIST says (pdf, Appendix C) is an acceptable way to generate an IV for CBC: 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 must be a ...

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

1

If the IV is all zeroes, then you basically have ECB for the first block. Basically you're proposing to use this first block's encryption as the IV for the second block. You're implying that the first block will always be unique, but low entropy, which sounds like a counter or time stamp. There are attacks when the IV is predictable, and while this is a ...

1

No. ​ An adversary who knows a ciphertext and one of its plaintext blocks p can trivially find the corresponding xored-plaintext x. ​ Since block ciphers with fixed keys are bijections, if there is a previous plaintext block then x has at least as much entropy as that previous plaintext block. (In particular, x can very easily be different from your other ...

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.

0

In your proposal, the IV is used as plaintext in the ECB mode and then is XOR'ed into the plaintext of the first block in CBC mode. I don't believe this is proven weak, but it isn't helping security. The IV is not meant to be secret. You are not gaining any additional security by attempting to keep it so. The only thing that matters is that it is truly ...

0

What you did seems fine for verifying the key is correct. However, unless AES256_encrypt uses an authenticated mode of encryption (in which case the whole exercise would be unnecessary), there is nothing that prevents an attacker from modifying the message. And depending on the mode of encryption used, that can even compromise the privacy of the message. ...

1

Yes, you are in the ballpark with your assumptions. I will store the encryptedKey with the encrypted data, but can I use the same key for all rows or do I need to generate a new one for each one? No you can use the same key. How does the AAD factor into this? Do I need to store it? Does it need to be unique per row? If you don't need ...

1

This sounds like Kerberos. ( https://en.wikipedia.org/wiki/Kerberos_%28protocol%29 ) In any case, you didn't mention, but it would seem quite important, how long are the generated auth tokens valid for, or how would you expire one. There is no such thing (IMHO) as permanent/indefinite authorization--if you believe otherwise, you should not be doing ...

3

In asymmetric crypto including RSA, we ALWAYS encrypt with the public key, and decrypt with the private key (NEVER the other way around). In the question, what's wanted is to sign with the private key, not encrypt. And that's enough to solve the whole problem, since RSA signature schemes exposed in BouncyCastle or the Java crypto API allow to sign data of ...

8

What makes crypto code vulnerable to timing attacks is data dependent timing variations. Branching according to a round counter, or to the key size, does not create a vulnerability. Most implementations of AES make no branch according to key or data value, and supressing other branches won't help. The main source of data-dependent timing variations in AES ...

2

The original is completely broken and would be regardless of the insecurity of DES. The ECB encryption of a single block message (with a secure cipher) would be a secure MAC, but XORing the message blocks means that an attacker can modify any block of the message simply by making the same change to another block so that they cancel out. The modified ...

2

Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to ...

1

No, not as described in the question. Putting aside the block size confusion that Richie Frame mentions in a comment (AES block size is always 128), there is no advantage to encrypting a second half of an IV in GCM mode in particular, and rarely in other modes. In GCM mode the actual IV is used to derive a nonce for CTR mode encryption. By adding a block ...

2

So my question is: it says 10 cycles, but does that mean that the initial round is performed once, the normal rounds 9 times, and the final round also once? Because the expanded key is 176-bytes, so the addroundkey function can be used 176/16 = 11 times. For the 128-bit AES, that is correct. InitialRound, which consists of AddRoundKey is performed ...

1

If $f_k$ is AES the block cipher, then there are $2^{128}$ possible output values for a given plaintext and $2^{|k|}$ possible AES keys, where $|k|$ is either 128, 192 or 256, depending on which AES key size you use. Assuming AES chooses a random permutation, $g_{PT}(k) = f_k(PT)$ behaves like a pseudorandom function*, so you expect something like $2^{127}$ ...

1

So if you consider ASCII encoding you have two plain text blocks: "SEND ME THE DATA" and " ENCRYPTED" + padding (which we will ignore). Note the space before "ENCRYPTED". Now if you change the IV you will indeed only change the first block. What you should however do is to change the first block of the ciphertext. That is used as vector (not the ...

-1

For the symmetric key crypto, generally speaking, you must provide the secret key to the other end for decryption. The same random keys can be generated at the receiver end, if you use same function with same parameters. I am also a bit confused, since you have also used "signature" word in your program. Are you talking about the encryption or the ...

-2

This is a collision when you say fk(PT) = fk'(PT). I don't think it is possible with AES till now. People have find out some theoretical attacks on AES with some assumptions (like considering reduce rounds, etc.), but there is no full attack till now. When you talk about the symmetric encryption, such as AES, you must be aware that currently the standard ...

0

You may want to rethink your whole setup. Like mentioned in the comments, there is a lot more to securely storing files than throwing encryption on them. In particular, you need to be concerned with authentication (CTR without authentication is malleable). I would also look into client side encryption in anything that puts user data in the cloud. Still, ...

2

This is considered in §6 of Bogdanov et al., who go on to devise an alternative 2-round AES-based Even-Mansour cipher—$\text{AES}^2$. The problem is, essentially, that 1-round Even-Mansour is only secure up to $2^{n/2}$ blockcipher queries, for an $n$-bit block. Specifically, a collision between $\text{SEM}_K(P) \oplus P$ and $E(P) \oplus P$ immediately ...

1

I assume the recommended approach is to use a KDF function like HKDF, but what is the security implication of taking an SHA-256 hash and using it directly for AES-256 or truncating it for AES-128 (Alice and Bob are using Java which doesn't have a native implementation of HKDF and I don't think it is a good idea to try and write your own). HKDF(-Expand) ...

2

As CodesInChaos notes in the comments, having more ciphertext–plaintext pairs doesn't help with brute force guessing attacks. Well, that is, except for the minor issue of unicity. Basically, to narrow the results of your brute force attack down to a single key, you do need to have enough ciphertext–plaintext pairs that the length of the known plaintext ...

Top 50 recent answers are included