Add Multilinear Galois Mode #185
Conversation
Codecov Report
@@ Coverage Diff @@
## master #185 +/- ##
==========================================
- Coverage 93.95% 90.80% -3.15%
==========================================
Files 28 32 +4
Lines 827 1066 +239
==========================================
+ Hits 777 968 +191
- Misses 50 98 +48
Continue to review full report at Codecov.
|
| /// | ||
| /// When carries do occur, they wind up in a "hole" and are subsequently masked | ||
| /// out of the result. | ||
| fn bmul64(x: u64, y: u64) -> u128 { |
There was a problem hiding this comment.
Note that I am using u128 here instead of the reversing trick. It allows to simplify code a bit and it should be more performant on targets which support "wide" multiplication. Maybe it's worth to port this approacht to polyval?
There was a problem hiding this comment.
Sure.
(I'm also curious why all of this can't be implemented in terms of POLYVAL?)
There was a problem hiding this comment.
I'm also curious why all of this can't be implemented in terms of POLYVAL?
It could be, but I am not sure if it will have the same performance as an "inlined" version. Plus there are some annoying differences between algorithms, e.g. MGM does not chain values like GHASH and Polyval and it uses a "direct" order of bits for mapping binary string to polynomial. I will look into unifying code bases later, but not now.
| //! use mgm::aead::{Aead, NewAead, generic_array::GenericArray}; | ||
| //! | ||
| //! let key = GenericArray::from_slice(b"an example very very secret key."); | ||
| //! let cipher = Mgm::<Kuznyechik>::new(key);; |
There was a problem hiding this comment.
Surprised clippy didn't catch that
There was a problem hiding this comment.
Currently clippy does not check code examples, see: rust-lang/rust#56232
|
Does anyone know how secure this is? I can't seem to find any information on that, and I'm not good at reading papers on cryptographic algorithms or hash functions. |
|
AFAIK the construction was not properly analyzed by independent cryptographers yet. The authors claim some improvements compared to GCM, but in my understanding they are mostly theoretical. On a con side those properties are achieved by significantly degrading performance, if Contrary to MGM and GCM, SIV can not be fully parallelized (but it can be fixed by using PMAC-SIV) and requires two passes instead of one (assuming you are not saturating your memory bus it should not be a big problem thanks to prefetching), but it has a really nice property of misuse resistance, which (as far as I understand) is much more important in practice than the theoretical improvements of MGM. Also MGM authors made, let's say, an "interesting" decision to use nonces with length not multiple of 8 bits (127 and 63 bits for 128 and 64 bit block ciphers respectively), which adds some additional headache when generating nonces (current implementation will return an error if the most significant bit in 128 bit nonce is not equal to zero). So unless you target Russian crypto standards, I think it is better to choose between GCM and SIV modes. |
|
Also note: AES-GCM-SIV provides both parallelism and AES-GCM equivalent performance (with a ~20% encryption performance penalty, but decryption at equivalent-or-faster speeds to AES-GCM) |
|
Yeah... the fact that it hasn't been independently reviewed makes it
sketchy. And the use of a non-power-of-two nonce is... really odd. I
was thinking of using GCM-SIV over standard GCM just for the nonse
reuse protection.
…On 9/24/20, Tony Arcieri ***@***.***> wrote:
Also note: AES-GCM-SIV provides both parallelism and AES-GCM equivalent
performance (with a ~20% encryption performance penalty, but decryption at
equivalent-or-faster speeds to AES-GCM)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#185 (comment)
--
Signed,
Ethin D. Probst
|
For now it uses standalone code for simplification reasons, but in future hopefully it will use the same code base as
ghashandpolyval. I haven't portedsoft_u32and probably I will postpone it until unification withpolyval.MGM can also work with 64-bit wide block ciphers, but I doubt I will bother implementing it.