Nikos Mavrogiannopoulos <[email protected]> writes: > I can see it on my sent folder. Could it be that the list manager removed it?
Possibly. The mailman config is known to be a bit picky (and I'm not very good at configuring it), but I thought it would usually bounce messages rather than silently remove attachments. > I've put it at: > http://homes.esat.kuleuven.be/~nikos/0001-Added-timing-resistant-versions-of-rsa_compute_root-.patch Thanks! I've had a quick look. A few comments: I'm not sure if the low-level rsa_compute_root should be aware of the blinding, or if it should be the responsibility of its callers (using _rsa_blind, _rsa_unblind helper functions, put in rsa_blind.c or so). Support for blinding is desirable not only for rsa_decrypt, but also for the various rsa_*_sign functions, right? The blinding function should probably use nettle_mpz_random, which provides for *almost* uniform distribution mod n by generating a few extra bits before the mpz_fdiv_r. As for interface, I have been considering to also add some kind of deterministic dsa signatures, substituting something like HMAC(private key, message) for the random input, and if possible, it would be nice to have a consistent interface for {rsa, dsa} signatures {with, without} randomness input. Not sure if we should have separate functions for operation with and without blidning, or a single function with an optional randomness source as argument. If we have separate functions, we have to decide on the name (I don't quite like "_timing": If the name is supposed to describe intended use, it needs to be more verbose, maybe "_timing_resistant". I think it may be more handy to rather describe what it *does*, something like "_blinding" or "_randomized" or so). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
