Tag Info

Hot answers tagged

8

I would like to ask if that is true for every AES CTR mode implementation?, Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can ...


8

The reference for this is NIST SP800-38A, especially its appendix B. Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if ...


7

There are probably quite a few good reasons for this, although I don't expect that a scientific answer can be composed (as you would need to use a survey, and I've never heard of such a thing for modes of operation). Let me list a few possible reasons: Developers don't know about CTR mode of operation; most questions on StackOverflow are about ECB and CBC ...


6

First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments. Now, some observations. I haven't read all your code, so I may misunderstand things. Is this a good way to whiten the data? Is ...


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


5

If you want strict indistinguishability, then yes, you need to store the IV (initial counter) somewhere. However, there are some relaxed modes that are used in practice for things like disk encryption, where it is often very useful to decrypt things "in the middle" like you say. For instance, XEX uses a counter which is derived from the sector and offset ...


4

Every paragraph ends with : "this operation is invertible", I suppose the whole salsa20 algorithm is. The Salsa20 quarterround, and thus rowround, columnround and doubleround are invertible. However, the whole Salsa20 core is not because the initial state is added to the state after iterating the rounds (cf. page 6 in the spec). If I use salsa20 ...


4

The sum of PRPs is a secure PRF. That paper gives as a security bound for a sum of two independent PRPs $q^3/2^{2n-1}$, where $q$ is the number of queries and $n$ the block size (i.e. 128 for AES). That means that your construction, correctly used, is more secure than a single PRP, for which the bound is $q^2/2^n$. If you wanted to give an adversary an ...


4

No, this is safe. In fact, if you show a way of distinguish the stream $AES_{k_1}(C) \oplus AES_{k_2}(C)$ from a random stream with fewer than $2^{64}$ outputs, you have just demonstrated a way of distinguishing AES from a random permutation. Here is how this works: suppose we are given Oracle assess to a permutation $P$, which might be $AES_{k_1}$ for ...


4

Like the other answers say, it does not always have to be the case. One other case where it is often not stored is when you have a single use key, for example as part of some hybrid encryption scheme. Then there is no need to use a nonce at all and it is usually taken to have zero value.


4

First, AES-CTR isn't "similar to a stream cipher." It is a stream cipher. That means the real question is "why do we develop new stream ciphers when AES-CTR provides an acceptable one?" The answer is that newer stream ciphers tend to be superior to AES in some way or another. AES is a secure cipher, but it has some bad properties; for instance, it's hard ...


4

There are two well-known Encryption modes, that can construct a $mn$-bit tweakable blockciphers from a $n$-bit blockcipher ($n=64$ for DES) with $1\le m\le n$. The older one is CMC, being not parallelizable. It was superseeded by Encrypt-Mix-Encrypt (EME), which is parallelizable. The basic idea of the two algorithms is to encrypt each block of input data ...


3

A message encrypted with AES-GCM can be decrypted with an AES-CTR library IF the authentication tag is stripped from the message. If you are encrypting with AES-GCM and then adding an HMAC tag, you need to strip the HMAC and the GTAG off the message in order to decrypt it, assuming the IV section of the message is in the correct location for each library to ...


3

How does Salsa20 work? The basic building block of salsa20 is a fixed 512 bit permutation. This is similar to a block cipher with a fixed and publicly know key (or a zero bit key if you prefer). Since it has no key input, you can't use it with block cipher modes of operation. The next step in Salsa20 is a feed-forward by adding the input into the output, ...


3

In CTR, you can use any operation which has a full cycle through the space of the IV with the counter. You could use the plus operator like the example: $69dda8455c7dd4254bf353b773304eec + 1 = 69dda8455c7dd4254bf353b773304eed$ To calculate the next value, just again add 1. You could also use a increasing counter and xor it with the original IV: ...


3

In addition to the tweakable enciphering schemes in the comments, I'll leave this reference here: https://eprint.iacr.org/2009/356.pdf It essentially shows (in the ideal cipher model) that using an n-bit block cipher in a three-round Feistel construction gives you a 2n-bit block cipher.


2

This will not be secure in general, and is not recommended. The reason is that a PRG is guaranteed to produce a pseudorandom output only if its input is uniformly random (or pseudorandom). Moreover, several PRG outputs are jointly pseudorandom only if the PRG is run on independent seeds. But here you are invoking the PRG on "structured" inputs, i.e., the ...


2

Like said in the comments, a 256-bit message is two blocks of AES, no matter the keysize. The main issue with ECB mode (i.e. using AES directly on 128-bit blocks) is that you leak whether two blocks are equal. When encrypting perfectly random data, that means there's a $2^{-128}$ chance the two parts of the key are equal, and the attacker knows that. The ...


2

I would advise a different solution. You either generate a master-key (or key set) or derive one from a user password (e.g. via PBKDF2 or SCrypt). For each file to encrypt you generate a random key (file key) and nonce ad-hoc, and encrypt the file with that key, using an AEAD scheme. The random file key is encrypted with you master key and put at the ...


2

The seed should be the key and the nonce or IV. Those input parameters determine the value of the key stream. Note that the nonce may be implied if the key is not reused, in that case the key may be the only seed, with the nonce having a static value (you should however make sure that you are not vulnerable to multi-target attacks if you use a static IV, see ...


2

The once part inside of the nonce in CTR mode means effectively "once for this particular key". If you use a fresh key for each message (e.g. by encrypting it using public-key crypto or similar), you can use the same nonce for all the messages (or a size-zero nonce). The important part is that the combination of nonce and ctr-value (i.e. what is input into ...


2

Fgrieu has already posted a good answer, which I won't try to repeat. However, here are a few additional observations: For an embedded system, you may want to consider using CMAC-AES instead of HMAC, since you can reuse your AES implementation, and don't need a separate hash function. Further consider using SIV mode (RFC 5297). It's very similar to ...


2

I understand the system as follows: data blocks are enciphered per AES-CTR, using key encryption_key, with an IV made by concatenating device_id and a counter held in Flash or EEPROM, incremented at each use; that enciphered data is integrity-protected by a 256-bit mac_tag computed using HMAC-SHA256 and mac_key. That's theoretically sound if device_id ...


2

It doesn't make too much sense at all to send the IV together with the key. The whole idea of an IV is that it is unique per key. But if the key changes value each time, then any IV is unique. So you could use a static IV or even an IV that consists of all zeros. In that case you only need to worry that you don't reuse the key at other locations in the ...


2

Yes there are such schemes. However they aren't standardized by any means yet. The schemes I'm talking about take part in CAESAR-competition. If you wait ~1 week (hopefully) you'll see if any mode / cipher makes in in the second round. This paper provides you with a good overview over the ciphers. The four ciphers you need are: ICEPOLE (Sponge based) ...


2

AES-CTR is very appropriate. Since a credit card number is 16 characters long, it can be encrypted using a single 128-bit block without any encoding. You will only need 1 block, and hence not require a block counter, just the nonce. Depending on the amount of card numbers being stored, you would only need to store a portion of the full nonce. A 32-bit ...


2

That might not be speed-efficient, but for educational purpose it is possible to implement the CTR internals manually, by using the ECB mode of CNG: Set the Algorithm mode: BCryptSetProperty(hAesAlg, BCRYPT_CHAINING_MODE, (PBYTE)BCRYPT_CHAIN_MODE_ECB, sizeof(BCRYPT_CHAIN_MODE_ECB), 0) Encrypt all blocks the IV with counter with the key hKey: ...


1

No OFB_DRBG isn't directly vulnerable to attacks. However from a theoretical standpoint there is one point speaking against it and in favor of CTR_DRBG. Speed. CTR can be parallelized (can encrypt counters in parallel), OFB can't (encrypting state over and over again) So the main reason is speed I'd guess and of course adding OFB_DRBG wouldn't have added ...


1

I decided to just implement something that's known to work, namely CTR with HMAC SHA256. So you are implementing your own mode after all? Don't. Combining MAC and encryption is actually tricky. You should use a standard authenticated encryption mode, such as GCM (which is CTR plus MAC done right). From what I understand, I can use the IV as a ...


1

For CBC mode, the IV can be generated in any manner where it would be unpredictable to an attacker from one message to the next. In practice that means a random number generator of some kind. Since the block size is 128-bits, the probability of IV repeat before the key expiration is negligible. The CBC IV is visible to an attacker viewing your ciphertext; as ...



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