What I think would be most interesting is whatever primitives are needed to build fancy cryptosystems which are resistant to EMI/DPA sidechannels.
Plain TLS stuff as the sibling comment suggests is entirely uninteresting to me-- a boring software implementation is more than fast enough even on a 100MHz device to accomplish whatever that 100MHz device is going to accomplish. (I assume bunnie's Betrusted soc will be faster than 100MHz too).
But what you can't do from general software is get something which is extremely robust against EMI and power sidechannels.
Similarly, while plain ECDH/etc. will be more than fast enough even in software for 99% of applications you'd want to run on a small device like this, various zero knoweldge proofs and other fancy constructions may still be painfully slow (as they're often noticably slow on desktops).
Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement. ... but group choices for ZKPs are by-far not a settled question.
> Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement.
Luckily you can use an optimized ed25519 to implement ristretto255, which solves this problem :)
Plain TLS stuff as the sibling comment suggests is entirely uninteresting to me-- a boring software implementation is more than fast enough even on a 100MHz device to accomplish whatever that 100MHz device is going to accomplish. (I assume bunnie's Betrusted soc will be faster than 100MHz too).
But what you can't do from general software is get something which is extremely robust against EMI and power sidechannels.
Similarly, while plain ECDH/etc. will be more than fast enough even in software for 99% of applications you'd want to run on a small device like this, various zero knoweldge proofs and other fancy constructions may still be painfully slow (as they're often noticably slow on desktops).
Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement. ... but group choices for ZKPs are by-far not a settled question.