4 ms·

Two very closely-related exceptions, and a host of very closely-related copycats. Essentially, one problem space which makes up a small (I would say) percentage

Two very closely-related exceptions, and a host of very closely-related copycats. Essentially, one problem space which makes up a small (I would say) percentage of the use of cryptography. In terms of daily impact on the lives of random folks, anyway. I never said secp256k1 was depreciated (nor deprecated), I said that I have seen recommendations from people far more knowledgeable than I who say, effectively, don't use it unless forced to interoperate with Bitcoin. For example: https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/ https://soatok.blog/2022/05/19/guidance-for-choosing-an-elli... The above link, in case you don't want to read through, basically says "use ed25519. If you can't do that, use secp256r1." This tracks with what I have read from others, and with the direction Filo is taking, so I consider it pretty good advice.

adastra22 4y ago
Yea I'm not going to dox myself on this site, but having actually submitted papers and presented at various cryptography conferences and worked as an applied cryptographer in this field for 10 years, I think I have more cryptographic domain experience than some random furry-avatar security blog writer. Nobody recommends secp256*r1*. Nobody. The Koblitz curve is strictly better. And libsecp256k1 as an implementation has received as much or more review by professional cryptographers (including many members of the well-respected Stanford cryptography group) than any other curve implementation, including many of the curve25519 libraries. It is battle-tested and very secure. There is, essentially, a giant billion-dollar bounty on the security of this curve and the correctness of its implementation. And in the history of cryptocurrency, there has never, not once, been a theft of money due to a cryptographic weakness or implementation error in this library. Unlike curve25519, whose non-unity cofactor for example was a source of inflation bugs in CryptoNote-based projects (e.g. Monero), something which secp256k1 mathematically prevents from being possible in the first place. If you want to start a new project and not have to worry about potential cryptographic vulnerabilities with your choice of curve or algorithm, there are very few options to pick from. Both curve25519 and secp256k1 are pretty much the only two options, and they are pretty equal in terms of trustworthiness. If you are doing anything novel with publicly-visible digital signatures, I would absolutely recommend secp256k1 over curve25519 due to the cofactor situation.
- KAMSPioneer 4y ago
  > Yea I'm not going to dox myself on this site, but having actually submitted papers and presented at various cryptography conferences and worked as an applied cryptographer in this field for 10 years, I think I have more cryptographic domain experience than some random furry-avatar security blog writer. I believe the random furry-avatar blog writer works in the field as well, and writes under a pseudonym to "avoid dox[ing himself]. But I dunno, I'm not a regular reader > Nobody recommends secp256r1. Nobody. The Koblitz curve is strictly better. Well again, you have to see that from my perspective, your credentials are the same as the other guy. To be clear, I believe you; I just also believe the Soatok guy. > Unlike curve25519, whose non-unity cofactor for example was a source of inflation bugs in CryptoNote-based projects (e.g. Monero). Ah, I hadn't heard of that issue/those issues. I'll search for them tomorrow. To be clear, I don't recall anyone ever saying secp256k1 is insecure, hence why I didn't want you to think I was calling it deprecated. I appreciate your insight.
  - adastra22 4y ago
    > Ah, I hadn't heard of that issue/those issues. I'll search for them tomorrow. It's pretty easy to summarize: basically for every curve25519 secret, there are 8 (cofactor=8) corresponding public keys, whereas for secp256k1 there is a 1:1 mapping between secret values and public keys. Normally this isn't an issue because when doing things like ECDH key agreement, or digital signatures, honestly who tf cares? Hence why djb opted for a cofactor curve for a small performance gain. However as a broad generalization, zero-knowledge proofs basically operate by doing manipulation of public keys instead of the underlying secrets/committed values. So for every committed value there are 8 different possible commitments on the curve. Any time you have a zero-knowledge proof using curve25519, anyone can come by and (without knowing the secret value), manipulate it to create an entirely different, but valid proof. In the case of Monero, spending authority derived from knowing a secret corresponding to an output, but you only ever revealed a "key image" which (simplifying greatly) was essentially a public key / elliptic curve point derived from that secret in a particular way. Double spends were prevented by keeping track of which key images had been seen already. But of course there are 8 possible key images, so every output was spendable up to 8 times. It was a number of years before this flaw was caught! The cofactor is a huge foot-gun opportunity for anybody doing anything more complicated than simple ECDH, signing a message, or login authentication. It is the main reason why I don't use curve25519 in new protocols, nor recommend its use to others. Better to just not take the risk of getting burned. There is a sub-curve (Ristretto) which is of prime order which can be used on top of curve25519. But doing zero-knowledge proofs of Ristretto operations is significantly more complicated due to the fact that it is a sub-curve, and the security arguments are subtly different in nontrivial ways. Easier to just use secp256k1 and know you are safe.

adastra22 4y ago

Yea I'm not going to dox myself on this site, but having actually submitted papers and presented at various cryptography conferences and worked as an applied cryptographer in this field for 10 years, I think I have more cryptographic domain experience than some random furry-avatar security blog writer. Nobody recommends secp256*r1*. Nobody. The Koblitz curve is strictly better. And libsecp256k1 as an implementation has received as much or more review by professional cryptographers (including many members of the well-respected Stanford cryptography group) than any other curve implementation, including many of the curve25519 libraries. It is battle-tested and very secure. There is, essentially, a giant billion-dollar bounty on the security of this curve and the correctness of its implementation. And in the history of cryptocurrency, there has never, not once, been a theft of money due to a cryptographic weakness or implementation error in this library. Unlike curve25519, whose non-unity cofactor for example was a source of inflation bugs in CryptoNote-based projects (e.g. Monero), something which secp256k1 mathematically prevents from being possible in the first place. If you want to start a new project and not have to worry about potential cryptographic vulnerabilities with your choice of curve or algorithm, there are very few options to pick from. Both curve25519 and secp256k1 are pretty much the only two options, and they are pretty equal in terms of trustworthiness. If you are doing anything novel with publicly-visible digital signatures, I would absolutely recommend secp256k1 over curve25519 due to the cofactor situation.

KAMSPioneer 4y ago
> Yea I'm not going to dox myself on this site, but having actually submitted papers and presented at various cryptography conferences and worked as an applied cryptographer in this field for 10 years, I think I have more cryptographic domain experience than some random furry-avatar security blog writer. I believe the random furry-avatar blog writer works in the field as well, and writes under a pseudonym to "avoid dox[ing himself]. But I dunno, I'm not a regular reader > Nobody recommends secp256r1. Nobody. The Koblitz curve is strictly better. Well again, you have to see that from my perspective, your credentials are the same as the other guy. To be clear, I believe you; I just also believe the Soatok guy. > Unlike curve25519, whose non-unity cofactor for example was a source of inflation bugs in CryptoNote-based projects (e.g. Monero). Ah, I hadn't heard of that issue/those issues. I'll search for them tomorrow. To be clear, I don't recall anyone ever saying secp256k1 is insecure, hence why I didn't want you to think I was calling it deprecated. I appreciate your insight.
- adastra22 4y ago
  > Ah, I hadn't heard of that issue/those issues. I'll search for them tomorrow. It's pretty easy to summarize: basically for every curve25519 secret, there are 8 (cofactor=8) corresponding public keys, whereas for secp256k1 there is a 1:1 mapping between secret values and public keys. Normally this isn't an issue because when doing things like ECDH key agreement, or digital signatures, honestly who tf cares? Hence why djb opted for a cofactor curve for a small performance gain. However as a broad generalization, zero-knowledge proofs basically operate by doing manipulation of public keys instead of the underlying secrets/committed values. So for every committed value there are 8 different possible commitments on the curve. Any time you have a zero-knowledge proof using curve25519, anyone can come by and (without knowing the secret value), manipulate it to create an entirely different, but valid proof. In the case of Monero, spending authority derived from knowing a secret corresponding to an output, but you only ever revealed a "key image" which (simplifying greatly) was essentially a public key / elliptic curve point derived from that secret in a particular way. Double spends were prevented by keeping track of which key images had been seen already. But of course there are 8 possible key images, so every output was spendable up to 8 times. It was a number of years before this flaw was caught! The cofactor is a huge foot-gun opportunity for anybody doing anything more complicated than simple ECDH, signing a message, or login authentication. It is the main reason why I don't use curve25519 in new protocols, nor recommend its use to others. Better to just not take the risk of getting burned. There is a sub-curve (Ristretto) which is of prime order which can be used on top of curve25519. But doing zero-knowledge proofs of Ristretto operations is significantly more complicated due to the fact that it is a sub-curve, and the security arguments are subtly different in nontrivial ways. Easier to just use secp256k1 and know you are safe.