i still don't get why people use elliptic curves instead of diffie-hellman since you can use it for public keys too. the index calculus cryptanalytic method appears to apply for the usage of F_q where q = pn for some prime p. it appears that if q is a large prime and q - 1 is divisible by a large prime, that covers the two biggest error cases
372
Replies
0
Boosts
https://cr.yp.to/papers/safecurves-20240809.pdf if you read section 10 and onwards there are just an incredible number of problems arising from elliptic curves not using integer bit strings as points where it becomes incredibly hard to tell whether anything is a legitimate point and that seems like a huge problem
and furthermore the index calculus method is not very well evaluated + it seems to apply to elliptic curves anyway
The literature has many more examples of complications stemming from the interface gap between [bit] strings and elements of E(F_p)
this sounds like a bad protocol
Efficient bijections are known for some elliptic curves.
this is definitely not making the case
so because elliptic curve bullshit is confusing as shit the blockchain boys broke the foundational assertion against double-spending
As an illustration of the second complication, the Monero blockchain announced in 2017 [166] that it had patched a vulnerability allowing each coin to be spent 8 times. Monero used Curve25519, which has cofactor 8, so there are 8 points T ∈ E(Fp ) such that 8T is the neutral element; Monero’s security analysis was expecting a point P to be in the order-l group, but the software was accepting P + T as a separate expenditure for each of the 8 points T.
literally not a good protocol
at the end of this djb paper he essentially says yeah you can trigger arbitrary incorrect behavior due to the incredibly complex encoding between integer bit strings and elliptic curve points and nobody knows how to fix it
my suspicion has been for quite a while that DH is the easiest method to implement safely and efficiently and i have learned nothing about elliptic curves which indicate they are safer from index calculus other than daniel jackoff bernstein and miller the IBM guy saying so without really explaining.
having a clear mapping to bit strings and no invalid points is a pretty huge benefit and since RSA relies upon the same trick for encryption i feel this is sufficient for me to feel confident about my insane belief that elliptic curves are confusing on purpose
very funny wikipedia page https://en.wikipedia.org/wiki/Index_calculus_algorithm
The choice of the factor base size r is critical, and the details are too intricate to explain here.
from the koblitz textbook, the factor base depends upon the size of the prime p, which is why it's relevant for q = pn
The lack of the notion of prime elements in the group of points on elliptic curves makes it impossible to find an efficient factor base to run index calculus method as presented here in these groups.
so...nobody's found it yet
Likewise, there’s no known algorithms for efficiently decomposing Integers into members of a target subgroup.
yeah cause everything is obfuscated
first reference http://www.dtc.umn.edu/~odlyzko/doc/arch/discrete.logs.pdf
Due in large part to recent discoveries, discrete logarithms in fields GF(2n) are much easier to compute than in fields GF(p) with p prime.
the 1976 diffie-hellman paper literally says to use a prime smaller than a b-bit string so you can use machine integers
Hence the fields GF(2n) ought to be avoided in all cryptographic applications. On the other hand, the fields GF(p) with p prime appear to offer relatively high levels of security.
lol
It turns out, for example, that the MITRE scheme [38,59] and the Hewlett-Packard chip [69], both of which use the field GF( 2127 ), are very insecure.
MITRE and HP backdoored???? gasp
everyone keeps saying diffie-hellman key exchange is unauthenticated. this bell labs paper (sus) even goes so far as to claim there are "no private keys" in diffie-hellman. both of these are obviously wrong
@hipsterelectron
Sadly I have no clue about how diffie-hellman key exchange went. All I can remember is:
Alice wants to send payload to Bob.
Alice puts LockA on payload locked with KeyA.
Alice sends locked payload to Bob.
Bob adds LockB to payload locked with KeyB.
Bob sends payload back to Alice.
Alice removes LockA from payload using KeyA.
Alice sends payload back to Bob.
Bob removes Lock B from payload using KeyB.
Bob can now read the payload.
@hipsterelectron
okay I remembered now.
it was more like:
Alice uses the Public machine and her KeyA to create LockA.
Bob uses the public machine and his KeyB to create LockB.
Alice sends LockA to Bob.
Bob sends LockB to Alice.
Alice takes LockB and her KeyA, and turns it into the Shared Lock.
Bob takes LockA and his KeyB, and turns it into the same Shared Lock.
the 1976 DH paper is WILDLY negative about backdoored ciphers lmao
