Prerequisite Exploration for Oxidizing AES-GCM. #369
Conversation
|
Coverage increased (+0.7%) to 92.154% when pulling 8dc7d070994257cf6d69e195702d564568071864 on oxidize-gcm into 5c5c294 on master. |
1 similar comment
|
Coverage increased (+0.7%) to 92.154% when pulling 8dc7d070994257cf6d69e195702d564568071864 on oxidize-gcm into 5c5c294 on master. |
briansmith
force-pushed
the
oxidize-gcm
branch
from
f34c868
to
79da032
Compare
The functions are infallible at this level so make the return types |void|.
The GCM code already works in a similar way. If we need a generic I-U-F interface for Poly1305 in the future, we'll probably need one for GCM too, so we'd probably build the I-U-F logic at a higher layer so tha it could be shared by both. It is likely we won't do that any time soon. This also avoids memory copies for aligning the opaque state between each function call. Now there are no copies.
briansmith
force-pushed
the
oxidize-gcm
branch
from
79da032
to
17540bc
Compare
|
I did quite a bit of work on this to move it further along. Unfortunately things get really ugly because of the alignment (to 16 bytes) requirements (probably just preferences) that the lower-level assembly language AES-GCM and low-level AES code has. I implemented some workarounds, but they're ugly. Also, the primary purpose of switching to Rust is to improve static analysis of safety, improve readability, and improve maintainability, but the hacks currently needed to get things aligned are counter to all those goals. Accordingly, I'm closing this w/o landing anything. I'll continue this in a different PR, using better code, once rust-lang/rust#33626 is implemented, which could likely happen soon. Note that after this is done, we'll be able to share a significant amount of logic between AES-GCM and ChaCha20-Poly1305. Probably that will also make it much easier to implement new AEADs, in particular AES-CCM and maybe AES-GCM-SIV. So I'm postponing all that work until I can land something here. |
Here are a bunch of changes, only about half of which we're likely to keep. The point of these changes is to see how close we can make the AES-GCM logic and the ChaCha20-Poly1305 logic so that we can eventually share even more code between them, and also have less C code.
Based on this, a lot of sharing of logic should be possible by factoring out lots of the code from src/aead/chacha20_poly1305.rs into src/aead/aead.rs and then adapting the remaining code in e_aes.c to expose an API that is like
GFp_ChaCha20_ctr32and then adapting the remaining code in gcm.c to expose an API that is similar to the Poly1305 code.One complication to factoring out the common logic is the
aesni_gcm_enabled/GFp_aesni_gcm_encrypt/GFp_aesni_gcm_decryptoptimization.Another complication to factoring out the common logic is the
GHASH_CHUNKlogic. Probably I'll just drop that for now, and then try to add it back in a way that can be used for ChaCha20-Poly1305 too. I'm not sure why OpenSSL chose not to have anyGHASH_CHUNK-style logic in the ChaCha20-Poly1305 code we inherited from it.