Tag Info

20

It's meaningless nonsense. I would be inclined to avoid spending any money with these people. If you scroll down on this page, you'll find a table labelled key size vs. time to crack, according to which their $2 \times 256$ bit encryption takes $3.31 \times 10^{112}$ years to crack, making it (apparently) superior to ordinary $256$-bit encryption (which can ...

18

In short: You must authenticate the IV. Which particular attacks apply if you don't depends on the block cipher mode; I will give two common examples. In CTR mode, an attacker who fiddles with the IV can forge authenticated messages, but the content of the corresponding plaintext is beyond his control (since he doesn't know the key). Depending on the ...

16

We can't implement "AES 512 key size" because AES is defined for key sizes $k\in\{128,192,256\}$ bits only; much like we can't make a bicycle with 3 wheels. I see no reason why we would want to define an AES variant with 512-bit key size (since AES-128 is safe enough for anything foreseeable most current applications except those that require huge security ...

16

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

10

Both an AES-128 key (as defined by FIPS 197), and a TDES Keying Option 2 key (as defined by FIPS SP-800-67) are 128-bit bitstrings. Similarly, both an AES-192 key and a TDES Keying Option 1 key are 192-bit bitstrings. The differences are: In AES, all bits of a key matter to the result; in TDES, 1 bit out of 8 (the lower-order bit of each byte in ...

7

Yes, AES-128 is intended to be the standard block cipher for building a secure and efficient symmetric cryptosystem using some block cipher operating mode, like CTR for encryption or GCM for authenticated encryption; efficiency can be particularly good when there is hardware support for AES and GCM. There might be better choices in the case at hand, like ...

7

I assume you mean AES-GCM. Nonces must be unique for any use of a key. Given that $n = H(k)$ is constant for constant key $k$, this implies that such a nonce may only be used once, ever. Nonce reuse is particularly catastrophic in GCM mode (as with any other CTR-based mode), as it causes the keystream to be identical. Essentially, you wind up with two (or ...

7

DES is slow in software because it was designed back in the early 70's even before the 8086 processor existed, and uses several bit oriented operations that are just not implemented efficiently in a processor with a word oriented instruction set. Its intended product was ASIC hardware designs, in which DES runs quickly. DES hardware processors are quite ...

6

SIV is a mode specially designed for this purpose. SIV-AES would be a good choice, but it has the same issues as AES-wrap; not many implementations. If you use a GCM you should make sure that the IV is unique (if your plaintext is ever not random you would otherwise be in problems). As for the password based key derivation function: yes, PBKDF2 is good, ...

6

If you look at the algorithm description, you see that, at a high-level, the encryption algorithm looks like this: addRoundKey(0); for (int i = 1; i < rounds; i ++) { subBytes(); shiftRows(); mixColumns(); addRoundKey(i); } ...

6

AES-CTR is a stream cipher, of a particular kind where the keystream is obtained by encryption of a counter. So the question reduces to: what are drawbacks of AES-CTR compared to other stream ciphers? The main ones compared to ChaCha20 are: Without hardware support, AES can fail to cache-timing attacks. Without hardware support, AES is slower. Without ...

6

DES is slow compared to AES including in hardware because for comparable security we must use 3DES, which triples the number of rounds per block, to 48 for 3DES versus 10, 12, or 14 for AES; DES's block size is 64 bits, half of AES's 128 bit; so when encrypting a sizable block of data, 3DES does more rounds that AES by a factor of 96/10, 96/12, or 96/14; ...

6

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

6

Given the choice, it is preferable to use the block encryption operation of AES, since it often faster than block decryption (never slower AFAIK). For this reason, AES-CTR is defined to use the block encryption operation of AES exclusively; that's both for AES-CTR encryption and AES-CTR decryption, which are the same operation except for IV generation/input. ...

6

Yes, this is exactly what a message authentication code is for. Its job is to prevent an attacker from tampering with your message, or from forging completely bogus messages. For a secure MAC, it should not matter what these messages contain. (And no, a secure MAC cannot compromise your key; if it did, it would by definition not be secure, since an ...

5

An important principle in cryptography is "key separation" which holds that one should "use distinct keys for distinct algorithms and distinct modes of operation". Violating key separation often opens up avenues of attacks that may break confidentiality, integrity, or even recover the key. You can use a KDF to derive cryptographically independent keys from ...

5

First, it's not said that AES is unbreakable, merely that none of the currently known attacks reduce the computational cost to a point where it's feasible. The current best attack on AES-128 takes 2^126.1 operations, if we had a computer (or cluster) several million times more efficient than any current computer and could operate at the thermodynamic ...

5

Yes, Poly1305-AES can safely be modified to use AES-256 rather than AES-128; but if AES is implemented in software beware of not introducing a timing vulnerability in the implementation. Change of the cipher in Poly1305-AES is explicitly endorsed; quoting D. J. Bernstein's The Poly1305-AES message-authentication code There is nothing special about AES ...

5

I add my whitebox AES implementation on GitHub in: C++ Java C++ version implements both Chow's (mixing bijections, input/output encodings, external encodings) and Karroumi's (dual AES in each column) whitebox AES scheme plus Billet's key recovery attack on both schemes. Java implements Chow's scheme only. PS: Due to low reputation I post links to ...

5

There are two things here: Encryption uses mode of operation, and not "AES alone". Some of them are randomized by an initialization vector - that means the encryption of the same text under the same algorithm is still randomized and not deterministic. The encryption methods take care of that. You only need the correct key to decrypt. Passwords are not ...

5

This begs the question, why would you in any real-world circumstance wish to reduce the difficulty for an attacker to break your cryptosystem? To answer your question practically, the only reasonable way I can think of to accomplish this is to simply reduce the entropy in the key. At 100%, all 128 bits of the key are used. At 50%, 64 bits of the key are ...

5

The most likely rationale to change the AES design is political. It's a NIST standard, designed in Western Europe. It's a bad idea! How much scrutiny has it received? Almost none. How much will it receive? Almost none. Bad idea.

5

At a high level, the major flaw is that you are rolling your own crypto protocol. You should strongly consider using a standardized protocol like DTLS. Some specific problems: Symmetric key distribution is left unspecified. Keys must be changed occasionally to thwart distinguishers. No way to recover from symmetric key compromise. Your message ...

5

If we take some randomly generated key of AES-128 and we change any random 1 byte of that 16 byte key, will this make huge difference in the AES cipher text generated over same input string? Yes. The outputs with different keys differ greatly. If you pick two random keys the outputs must look completely uncorrelated, or an attacker could gain an ...

4

I am assuming that you wish to consider this for standard encryption tasks, and I am going to ignore the specific reference to AES and talk about general block ciphers (pseudorandom permutations). The answer is that small block sizes are very problematic. In particular, they break when used for encryption of any reasonable amount of information. I will ...

4

For encryption or decryption of data that is encrypted on the fly, you can do that. For data you store you obviously have to use the same decryption, so if you encrypt a huge file using AES, you have to decrypt it using AES, even when on battery power. First thing: If there is hardware support for AES, AES will be faster and using less power almost certain. ...

4

What you are asking is a straight application of Format Preserving Encryption, which builds ciphers which input and output are in a constrained format (generically: common to input and output, hence preserved). The FPE field has many articles with proven techniques; and proposed standards, including BPS and SP800-38G Draft. Note: the method tentatively ...

4

You could do a brute force attack where you simply try the keys with highest Hamming weight first (those with the most ones). I am not sure if you would call this attack practical but at least it would be much more likely to succeed quickly than brute force when the key is selected uniformly at random. Just consider the key of all ones, and assume we are ...

4

AES CBC usually requires padding, such as PKCS#7 padding. This padding is 1 to 16 bytes, 16 being the block size of AES. The HMAC will add 256 / 8 = 32 bytes to the total. Usually you will need to store the randomized IV as well with ciphertext, to allow for reuse of the key, adding another 16 bytes (the block size again). So the total overhead will be about ...

4

The answer is simple. The recommandations of all experts in this case is to dissociate Keys used for Encryption from Keys used for MAC-ing. Then you have to use two different Keys.

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