Re:AES-Gem (AES with Galois Extended Mode)
by exabrial on Saturday July 13, 2024 @10:57AM
(#40954479)
Remember: You should never been on the bleeding edge with crypto. It takes years to find attacks in ciphers, and more years to find attacks in implementations.
Never roll your on crypto. Always move slow and trust the process.
Re:AES-Gem (AES with Galois Extended Mode)
by bjoli on Saturday July 13, 2024 @01:40PM
(#40955509)
I like these proposals to extend the current systems. They will probably never lead anywhere, but they are still a nice reminder that we are still learning things.
Re:AES-Gem (AES with Galois Extended Mode)
by jedisct1 on Saturday July 13, 2024 @03:15PM
(#40956171)
This is a great proposal.
It would have been a good opportunity to leverage the AES-PRF construction (see tosc.v2018.i2.161-191 in addition to the original paper), whose overhead is negligible. But unfortunately, FIPS restrictions is why we can't have nice things.
If FIPS compliance is not a requirement, AEGIS (AEGIS-256 in particular) is a more efficient alternative and on the standard track.
But when only FIPS-approved things can be used, AES-GEM is a nice way to solve a very common problem.
Never roll your on crypto. Always move slow and trust the process.
Moving slow is fine, but the reality is that the current options are not great for today's use cases. They're very easy to use insecurely.
My vacation plans include trying to grok at least a little bit of the xocb paper: https://dl.acm.org/doi/10.1007/978-3-031-30634-1_18
It would have been a good opportunity to leverage the AES-PRF construction (see tosc.v2018.i2.161-191 in addition to the original paper), whose overhead is negligible. But unfortunately, FIPS restrictions is why we can't have nice things.
If FIPS compliance is not a requirement, AEGIS (AEGIS-256 in particular) is a more efficient alternative and on the standard track.
But when only FIPS-approved things can be used, AES-GEM is a nice way to solve a very common problem.