Conversation

Notices

1. Embed this notice
   Ryan Castellucci (they/them) :nonbinary_flag: (ryanc@infosec.exchange)'s status on Saturday, 06-Jan-2024 23:21:10 JST Ryan Castellucci (they/them) :nonbinary_flag:

   Given a bigint library, how can I double a point on an elliptic curve within a prime field?

   I've gotten tomsfastmath modified so that it can build to freestanding webassembly and I don't want to deal with getting a more complex library to behave thusly.

   All I need to be able to do is double points on P-256, P-384, and P-521. Uncompressing points in compressed format would be NTH.

   • Embed this notice
     Ryan Castellucci (they/them) :nonbinary_flag: (ryanc@infosec.exchange)'s status on Sunday, 07-Jan-2024 01:18:24 JST Ryan Castellucci (they/them) :nonbinary_flag:

     in reply to

     • dakkar

     @dakkar It's doing way more than I need.

     I'm trying to turn one key into a set of several which have a couple bytes of shared prefix or suffix, in webassembly, quickly.

   • Embed this notice
     dakkar (dakkar@s.thenautilus.net)'s status on Sunday, 07-Jan-2024 01:18:28 JST dakkar

     in reply to

     @ryanc@infosec.exchange I guess you've already looked at libtomcrypt's ECC fixed point maths code and deemed it "too much"?

   • Embed this notice
     Ryan Castellucci (they/them) :nonbinary_flag: (ryanc@infosec.exchange)'s status on Sunday, 07-Jan-2024 01:36:42 JST Ryan Castellucci (they/them) :nonbinary_flag:

     in reply to

     • dakkar

     @dakkar I'm working on a WPA3 SAE-PK credential generator.

     It hashes ssid||arbitrary 16 byte value||compressed key in asn.1 der spki format. The standard uses. With the P-256 curve (the only one required by the spec, this uses SHA-256, which has a 64 byte block size.

     You need to get either 24 or 40 leading zero bits depending on the the configured security level.

     The public key representation has a 26 byte fixed prefix, so a 22 byte ssid will push the actual key part of the key entirely into the second block, and you can then compute the first block, clone it, and try again with a different public key.

     For slightly shorter SSIDs you could still do this so long as you had enough bytes of shared prefix. The first byte of the public key is either 02 or 03, so that's trivial, and you can get perhaps two bytes after that matched up with reasonable effort, reducing the ssid length minimum to 19 bytes.

     failing that, you can precompute the message schedule for the fixed second block and still get a decent speed up.