Skip to main content
deleted 54 characters in body; edited tags
Source Link
otus
  • 32.4k
  • 5
  • 73
  • 167

My understanding is that, in CTR mode, the NONCE must be unique because, if a NONCE is reused, multiple plaintexts will be XORed with the same value and this gives an attacker leverage to decrypt the data.

If you have a situation where it is hard to guarantee that the NONCE will always be unique, but you have a fast (whatever that means in your context) encryption implementation, can I take away the leverage that repeated NONCES give by adding an additional encryption step the normal CTR mode process?

E.g. replace

AES256(key, NONCE) XOR Plaintext

AES256(key, NONCE) XOR Plaintext

with

AES256(key2, (AES(key1, NONCE) XOR Plaintext))

AES256(key2, (AES(key1, NONCE) XOR Plaintext))

I understand I loose CTR mode's ability to work with arbitrary length plaintexts (which is fine for me, I'm happy working in blocks), and that I have doubled the amount of encryption I need to do, but I think this retains the advantages of CTR mode (as opposed to ECB mode) while gaining some protection against repeated NONCEs.

Is this approach valid? Is there a lighter way to gain some protection against repeated NONCEs?

I am focusing on CTR mode because my communication channel is not necessarily reliable and I worry about the need to "resync" if I use any of the chained modes.

Thankyou for considering this newbie question.

Julian

My understanding is that, in CTR mode, the NONCE must be unique because, if a NONCE is reused, multiple plaintexts will be XORed with the same value and this gives an attacker leverage to decrypt the data.

If you have a situation where it is hard to guarantee that the NONCE will always be unique, but you have a fast (whatever that means in your context) encryption implementation, can I take away the leverage that repeated NONCES give by adding an additional encryption step the normal CTR mode process?

E.g. replace

AES256(key, NONCE) XOR Plaintext

with

AES256(key2, (AES(key1, NONCE) XOR Plaintext))

I understand I loose CTR mode's ability to work with arbitrary length plaintexts (which is fine for me, I'm happy working in blocks), and that I have doubled the amount of encryption I need to do, but I think this retains the advantages of CTR mode (as opposed to ECB mode) while gaining some protection against repeated NONCEs.

Is this approach valid? Is there a lighter way to gain some protection against repeated NONCEs?

I am focusing on CTR mode because my communication channel is not necessarily reliable and I worry about the need to "resync" if I use any of the chained modes.

Thankyou for considering this newbie question.

Julian

My understanding is that, in CTR mode, the NONCE must be unique because, if a NONCE is reused, multiple plaintexts will be XORed with the same value and this gives an attacker leverage to decrypt the data.

If you have a situation where it is hard to guarantee that the NONCE will always be unique, but you have a fast (whatever that means in your context) encryption implementation, can I take away the leverage that repeated NONCES give by adding an additional encryption step the normal CTR mode process?

E.g. replace

AES256(key, NONCE) XOR Plaintext

with

AES256(key2, (AES(key1, NONCE) XOR Plaintext))

I understand I loose CTR mode's ability to work with arbitrary length plaintexts (which is fine for me, I'm happy working in blocks), and that I have doubled the amount of encryption I need to do, but I think this retains the advantages of CTR mode (as opposed to ECB mode) while gaining some protection against repeated NONCEs.

Is this approach valid? Is there a lighter way to gain some protection against repeated NONCEs?

I am focusing on CTR mode because my communication channel is not necessarily reliable and I worry about the need to "resync" if I use any of the chained modes.

Source Link

Repeated NONCE in CTR mode

My understanding is that, in CTR mode, the NONCE must be unique because, if a NONCE is reused, multiple plaintexts will be XORed with the same value and this gives an attacker leverage to decrypt the data.

If you have a situation where it is hard to guarantee that the NONCE will always be unique, but you have a fast (whatever that means in your context) encryption implementation, can I take away the leverage that repeated NONCES give by adding an additional encryption step the normal CTR mode process?

E.g. replace

AES256(key, NONCE) XOR Plaintext

with

AES256(key2, (AES(key1, NONCE) XOR Plaintext))

I understand I loose CTR mode's ability to work with arbitrary length plaintexts (which is fine for me, I'm happy working in blocks), and that I have doubled the amount of encryption I need to do, but I think this retains the advantages of CTR mode (as opposed to ECB mode) while gaining some protection against repeated NONCEs.

Is this approach valid? Is there a lighter way to gain some protection against repeated NONCEs?

I am focusing on CTR mode because my communication channel is not necessarily reliable and I worry about the need to "resync" if I use any of the chained modes.

Thankyou for considering this newbie question.

Julian