On 09/13/2011 03:56 PM, Niels Möller wrote:
Indeed. Once a framework for overwriting functionality is set, those would
be not very hard to add. However setting such framework in nettle seems to
require substantial work as all exported functions need to be replaced by
function pointers thus breaking ABI.
I don't think the function pointers should be exported. If "fat" library
is enabled (default for x86), then the exported function should be
void memxor (...)
{
(*memxor_p)(...);
}
I think one should have the possibility to choose between fat and
non-fat builds, with the same ABI. There's going to be a small extra
call overhead in the fat case.
Disabling the optional architectures would be possible but reducing the
call overhead in the "thin" case would require a lot of ifdefs. It would
keep the external api intact, but the internals would look ugly.
As long as all implementations can use the same ctx structs, there
should be no problem with the ABI. If we also want to support hardware
acelerators which are like black boxes, then some API and or ABI changes
may be necessary.
This is not guaranteed. For example AES-NI and padlock require the
AES key to be aligned to 16-byte boundaries, something that the
current structures do not offer.
I wouldn't care of serpent optimizations much :)
I'm not surprised ;-) But on processors which lack aes-instructions, but
which have 256-bit %ymm-registers, serpent can most likely be twice as
fast as aes if used in ctr mode (for the current code with 128-bit
%xmm-registers, serpent speed was somewhere between aes-128 and aes-192
last time I measured).
Why not use camellia as an alternative? It is newer design than serpent
and is pretty much standardized as the aes alternative.
In any case, I just noticed that for the x86-64 you don't really need to
detect SSE2, it is just there by default. So maybe the SSE2 xor can just
replace the x86-64 xor. For the plain x86 though this is not the case.
regards,
Nikos
PS. The ECC patch just got very low in my priority stack. If anyone else
is interested into porting it to nettle, he would make me a favor.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
