@jww Number of key exchanges is not the issue. You'd need a protocol that assumes contributory behaviour, or something similarly weird.

@CodesInChaos Perhaps a browser plugin then?

?

@jww I think there's a miss-understanding about what you are trying to achieve here

Thanks @SEJPM. Yeah, it is kind of tricky. We have to envision future attacks (many of which we have not thought of), and then we try to harden against them. Its not the easiest task. The browser plug-in [and malicious Javascript] came from the shared memory requirement.

@jww in this particular case for the curve25519 / X25519 implementation of the SC4-HSM?

@SEJPM So in the SC4-HSM case I was thinking along the lines of an integrated encryption scheme, similar to DLIES or ECIES. In the IES's, half of the key exchange has been performed. Decryption occurs by performing the other half of the key exhange to arrive at the shared secret. The shared secret is then subsequently used during decryption.

@jww security should be the same as with standard DH then, which is well understood (?) for Curve25519 / X25519

Thanks @SEJPM. Any ideas on where to find an updated implementation or the patches? I'd like to see what the team considers the state of the art. I feel like there's something fishy with the 2011 sources being considered the latest revision.

@jww so I asked a fellow crypto implementor ("the bear") and he said that for timing attacks any decent implementation should be fine

(which I think includes the nacl one)

for more advances side-channels things depend on the HW

other relevant implementations include the bearssl ones and the NaCl one

munacl.cryptojedi.org/faq.shtml

bearssl.org/gitweb/?p=BearSSL;a=tree;f=src/…

^SHA256 implemented in...excel