Nicolas Mora nicolas@babelouest.org writes:
I haven't made all the changes you requested but here's my situation.
Le 2021-03-06 à 04 h 45, Niels Möller a écrit :
Nicolas Mora nicolas@babelouest.org writes:
About the byteswapping comment, the code
// A = MSB(64, B) ^ t where t = (n*j)+i A64 = READ_UINT64(B.b); A64 ^= (n*j)+(i+1); WRITE_UINT64(A.b, A64);could be replaced by something like
#if WORDS_BIGENDIAN A.u64 = B.u64 ^ (n*j)+(i+1); #elif HAVE_BUILTIN_BSWAP64 A.u64 = B.u64 ^ __builtin_bswap64((n*j)+(i+1)); #else ... READ_UINT64 / WRITE_UINT64 or some other workaround ... #endif
The problem I have with this is the type of A and B: nettle_block8 and nettle_block16, and in nettle_block16, u64 is declared as 'uint64_t u64[2];'
So do I need to choose B.u64[0] or B.u64[1] depending on the architecture?
As far as I understand, B.u64[0] would be right in all cases. That represents the first 8 bytes of B.b, interpreted as a 64-bit number in platform-dependant endianness. Which is the same data accessed (using big-endian, regardless of platform) by the READ_UINT64 version.
- Some or all memcpys in the main loop can be replaced by uint64_t
operations, e.g.,
I.u64 = A.u64;
instead of
memcpy(I.b, A.b, 8);
I have the same problem with B.u64 being an array
.u64[0] for bytes 0--7, .u64[1] for bytes 8--15.
I've updated the MR to reuse ciphertext or cleartext as R. The original test cases still pass, I'll have to complete the tests.
Hmm. I think you should leave the input buffer untouched, with type const uint8_t*, and only use the *output* area for temporary storage.
In the in-place case, those will be the same and the code needs to handle that case, but if caller passes separate input and output buffers, the input should not be modified.
Using the output area directly has the drawback that it isn't aligned, so you'll need to keep some memcpys in the main loop. One could consider using an aligned pointer into output buffer and separate handling of first and/or last block, but if that's a lot of extra complexty, I wouldn't do it unless either (i) it gives a significant performance improvement, or (ii) it turns out to actually be reasonably nice and clean.
I'll rely on your wisdom about that if you don't mind
That's fine for now. We might try out the more complex way later.
I agree, I've updated the indentation using gnu indent with gnu style
Thanks. One peculiarity with the gnu style is the space between function name and open parenthesis (which you have after reindent). Nettle isn't quite consistent, but new code mostly follows this convention.
Regards, /Niels