Yin Guanhao

Definitely need this. Will work on it. Just need to repeat the authorization process, right? The rate limit for authorization is 300 per account per week([link](https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769)), which is quite abundant,...

> I was intending this just to do a self-test check, not against the ACME server. Why not just provide a command for authorization renewal? That should cover challenge test....

`KeyPair::from_bytes` should probably be removed too.

Well it's certainly better backward compatibility. But if backward compatibility is less a concern, I think a better API would be to have a `ExpandedKeyPair` struct (or just change `KeyPair`...

If the `ExpandedSecretKey::sign_*()` methods are changed to `pub(crate)`, there's not much point in exposing `ExpandedSecretKey` in public API at all.

> instead of removing it, I added simple validation logic to ensure matching key pair in [fd8c5fb](https://github.com/dalek-cryptography/ed25519-dalek/pull/205/commits/fd8c5fb5aeffb6c389b39dddda890e7a5b4f70f1) @sopium wdyt? I guess what I have in mind is similar to https://github.com/dalek-cryptography/ed25519-dalek/pull/210:...

It boils down to LLVM not able to optimize `write_volatile` for u8 pointers. The bytes have to be written individually. I think monomorphize for 16/32/64-byte arrays should be fine. These...

> The use of `write_volatile` was something of a hack to ensure that the writes would not be elided by the compiler. > > But inline assembly should also ensure...

> We can not use `write_volatile` on `*mut __m128` which we got from `[u8; 32]`, since the pointer could be insufficiently aligned. AFAIK we do not have unaligned version of...

> Yeah the typical way to implement a zeroization primitive efficiently is some sort of volatile `memset` typically realized by using some kind of compiler fence, often implemented as invoking...