This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Related to https://abyssdomain.expert/@filippo/109925743627302756 | |
# // len(z) == len(x)... or len(z) <= len(x) and everything is based on len(z) | |
# // z[] += x[] * y | |
# // c = overflow (ie c is "z[len(z)]") | |
# func addMulVVW(z, x []uint, y uint) (c uint) | |
# { | |
lea RSI,[x] # RSI = "&x" | |
lea RDI,[z] # RDI = "&z" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Double BS-SPEKE | |
Double BS-SPEKE is BS-SPEKE but with 3DH vs Noise-KN to make it a doubly | |
augmented PAKE. Double BS-SPEKE is the best doubly augmented PAKE that I know | |
of. Only problem is there are no proofs, but it's not hard to take the SPEKE | |
proof, add the OPAQUE proof for OPRF, and it's obvious that the doubly augmented | |
change makes it doubly augmented. So if anyone knows how to formally state that | |
in a proof, that would be awesome to have. BS-SPEKE defined on multiplicative | |
groups can be found here: | |
https://gist.github.com/Sc00bz/ec1f5fcfd18533bf0d6bf31d1211d4b4 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Prints "done" 4 times then doesn't exit ~50% of the time. | |
from multiprocessing import Process, Queue | |
def f(q): | |
while 1: | |
try: | |
data = q.get(False) | |
except: | |
break |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<?php | |
// Collision taken from https://shattered.io/ | |
// Outputs: | |
// HMAC-SHA1(key, msg1): 9b4dee1a35fc03786f1162989d1e441ba0e69f4d | |
// HMAC-SHA1(key, msg2): 9b4dee1a35fc03786f1162989d1e441ba0e69f4d | |
// | |
// HMAC-SHA256(key, msg1): e98a27bd93001cda9810b93c2191f5099817bb31f5445bc12cafd27a78cb4506 | |
// HMAC-SHA256(key, msg2): 97aa871b175a99417f7f1c44ac2793730821caf7da697ff374c60f595ef5173a |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BS-SPEKE (defined on multiplicative groups) | |
BS-SPEKE is a modified B-SPEKE with blind salt (OPRF). Modified B-SPEKE is a | |
similar change from SPEKE as from SPAKE2 to SPAKE2+ to make it augmented. Doing | |
this saves a scalar point multiply vs original B-SPEKE with blind salt. BS-SPEKE | |
is the best augmented PAKE that I know of. Only problem is there are no proofs, | |
but it's not hard to take the SPEKE proof, add the OPAQUE proof for OPRF, and | |
it's obvious that the augmented change makes it augmented. So if anyone knows | |
how to formally state that in a proof, that would be awesome to have. BS-SPEKE | |
defined on ECC can be found here: |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CPace (defined on multiplicative groups) | |
CPace is the best balanced PAKE that I know of. CPace defined on ECC can be | |
found here: | |
https://gist.github.com/Sc00bz/545eb39a369b67242634bd9c3302627c | |
Costs per step | |
A: - *^^ | |
B: *^ ^ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SRP is deprecated. | |
Use BS-SPEKE defined on multiplicative groups: | |
https://gist.github.com/Sc00bz/ec1f5fcfd18533bf0d6bf31d1211d4b4 | |
Or better BS-SPEKE defined on ECC: | |
https://gist.github.com/Sc00bz/e99e48a6008eef10a59d5ec7b4d87af3 | |
-------- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AuCPace | |
AuCPace with blind salt (OPRF) is the best augmented PAKE that I know of that | |
comes with a proof. | |
Costs per step | |
C: H*i fffI*i*iH**[ii] | |
S: f*iH***[iii] f*i | |
*: Scalar point multiply |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CPace | |
CPace is the best balanced PAKE that I know of. CPace defined on multiplicative | |
groups can be found here: | |
https://gist.github.com/Sc00bz/1375a5dc7d1e8a1ffdfb789d3f4c6593 | |
Costs per step | |
A: - fH**[ii] | |
B: H*i f*i |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Awhile ago I found this pointless optimization for Ed25519 because it only saves a few | |
multiples. Also it doesn't help much unless you're on a 32bit or 8bit processor then it | |
kinda helps, but since you do 4x more doubles than adds it really isn't noticeable. Also | |
you can precalculate T*(2*-121665/121666) so it only helps on the initial 3 adds when | |
building 1*P, 2*P, 3*P, ... 8*P. If you store 60833*(Y-X), 60833*(Y+X), 121666*Z, 121665*T | |
then it's a little less work than storing Y-X, Y+X, 2*Z, k*T. Well this really only helps | |
if you are on an embedded processor and don't have the RAM to build the 1*P, 2*P, 3*P, ... | |
8*P lookup table. So it's not completely pointless. | |
This is from the Explicit-Formulas Database with d = -121665/121666 |
NewerOlder