4 ms·

I know SIV doesn't address release of unverified plaintexts and iirc, AEZ and RIV (https://fse.rub.de/slides/fse_talk_lucks.pdf https://fse.rub.de/slides/fse_ta

by zkms 9y ago

I know SIV doesn't address release of unverified plaintexts and iirc, AEZ and RIV (https://fse.rub.de/slides/fse_talk_lucks.pdf https://fse.rub.de/slides/fse_talk_lucks.pdf) do. Are there any robust AE schemes nearing standardisation / deployment / "mainstream" like SIV is?

lvh 9y ago
Are you asking in the context of an on-line scheme? SIV "addresses" unverified plaintext release by just being off-line, which is the easiest and most elegant solution in my opinion.
- pbsd 9y ago
  Being offline does not ensure security against unverified plaintext. Imagine a colossal implementation fuckup (e.g., using strncmp to verify tags, ala Nintendo), or perhaps a hardware glitch flipping the verification bit to always return true. Ideally, i.e. with a robust AE scheme, you would hope that an altered ciphertext would result in random plaintext, but in SIV this is not the case. Alas, there are no standardized robust schemes, with AEZ making it to the CAESAR final portfolio being the most likely scenario of that happening.
  - swordswinger12 9y ago
    AEZ uses a non-standard AES variant in a sui generis fashion; as a result some people have called its security into question: https://eprint.iacr.org/2016/832.pdf https://eprint.iacr.org/2016/832.pdf Point being, its inclusion in the final CAESAR portfolio is far from clear at this point.
lvh 9y ago
My understanding is that the state of the art can barely agree on what RAE is and that's something that happened in the last year or two, so, nope, nothing I know of. Disclaimer: I'm not the GP.
- eternaleye 9y ago
  From everything I've seen, the security requirements of "true" RAE are exactly SPRP - that's certainly how Rogaway has framed it. To the best of my knowledge, that's why he designed AEZ under the encode-then-encipher paradigm - encode the plaintext with \tau trailing zero bits, then encipher it with (what is intended to be) a length-preserving SPRP. Being an SPRP, the inverse is also a PRP, and thus any adulteration of the ciphertext results in a pseudorandom decryption, preventing RUP (and causing the trailing zeroes to fail to validate). Constructing the SPRP then becomes the interesting part - a fascinating construction can be found in https://arxiv.org/abs/1310.4050 https://arxiv.org/abs/1310.4050 (which neither uses a block cipher entire, paying the cost of multiple invocations per block, _nor_ gives up on proofs - instead, it extends Cook's Elastic Cipher construction to arbitrary lengths, using the _round function_ directly, with security reductions to the original cipher the round function was taken from.)

by zkms 9y ago

lvh 9y ago

Are you asking in the context of an on-line scheme? SIV "addresses" unverified plaintext release by just being off-line, which is the easiest and most elegant solution in my opinion.

pbsd 9y ago
Being offline does not ensure security against unverified plaintext. Imagine a colossal implementation fuckup (e.g., using strncmp to verify tags, ala Nintendo), or perhaps a hardware glitch flipping the verification bit to always return true. Ideally, i.e. with a robust AE scheme, you would hope that an altered ciphertext would result in random plaintext, but in SIV this is not the case. Alas, there are no standardized robust schemes, with AEZ making it to the CAESAR final portfolio being the most likely scenario of that happening.
- swordswinger12 9y ago
  AEZ uses a non-standard AES variant in a sui generis fashion; as a result some people have called its security into question: https://eprint.iacr.org/2016/832.pdf https://eprint.iacr.org/2016/832.pdf Point being, its inclusion in the final CAESAR portfolio is far from clear at this point.

lvh 9y ago

My understanding is that the state of the art can barely agree on what RAE is and that's something that happened in the last year or two, so, nope, nothing I know of. Disclaimer: I'm not the GP.

eternaleye 9y ago
From everything I've seen, the security requirements of "true" RAE are exactly SPRP - that's certainly how Rogaway has framed it. To the best of my knowledge, that's why he designed AEZ under the encode-then-encipher paradigm - encode the plaintext with \tau trailing zero bits, then encipher it with (what is intended to be) a length-preserving SPRP. Being an SPRP, the inverse is also a PRP, and thus any adulteration of the ciphertext results in a pseudorandom decryption, preventing RUP (and causing the trailing zeroes to fail to validate). Constructing the SPRP then becomes the interesting part - a fascinating construction can be found in https://arxiv.org/abs/1310.4050 https://arxiv.org/abs/1310.4050 (which neither uses a block cipher entire, paying the cost of multiple invocations per block, _nor_ gives up on proofs - instead, it extends Cook's Elastic Cipher construction to arbitrary lengths, using the _round function_ directly, with security reductions to the original cipher the round function was taken from.)