-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong ed25519 keys? #146
Comments
Which field are you referring to? And which BEP? |
@the8472 Apparently this http://bittorrent.org/beps/bep_0044.html |
Ah, those are only used for publishing stuff on the DHT, for which distributed torrent feeds are one proposed use. Torrents themselves only use sha1 lists (v1) or sha256 merkle trees (v2). Anyway
This is incorrect, there are several ways to do it: https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/ |
I'm not good at cryptography. But we cannot call encryption algorithms that produce different keys the same. We either have to prove that the standard doesn't work correctly. Either rename the name Ed25519 to something else, or change the encryption in torrents to the standard.
Yes, sure. But DHT is a very important component of torrents. And for its development it is necessary to bring it to the form that everyone thinks about it. |
@arvidn Perhaps we need to add support for the global Ed25519 standard? This will fix all problems. |
I got confused too by this in BEP-0044. Ed25519 Private Keys are 32 bytes long conventionally, and in the BEP they are described as 64 bytes long. Given that, I cannot check the test vectors. Could I suggest to include extra test vectors with 32 bytes long private ed25519 keys?. |
The test vectors work for mldht and for libtorrent. Read the blog post that I linked in a previous comment to get an overview of the different private key formats. |
I don't request to replace current test vectors, I am asking to add new test vectors with other popular keyformats for ed25519, specifically 32 bytes secret keys. Or provide the same private key in the test vectors in different formats, if that is possible. Since the BEP is DRAFT, I guess somebody is/should be paying attention to feedback. |
Torrents do not use ed25519. BEP has a error and they refuse to fix it. |
The ed25519 keys in torrents are not the same as the ed25519 keys used around the world. Is this some kind of its own version of the keys?
Throughout the world, a private key is 32 bytes of the seed + 32 bytes of the public key. And here the private key is a 64 byte hash of the seed. Probably it's necessary to rename ed25519 to ed25519t at least? To avoid confusion?
And of course, worldwide ed25519 keys do not pass verification in the ed25519 torrent keys and vice versa. These are different keys. Although they have the same name and the same size.
How keys are generated worldwide: https://github.com/golang/go/blob/1e690409206ff97330b5a91517d453fc5129bab2/src/crypto/ed25519/ed25519.go#L172C43-L172C43
This matches Bouncycastle keys.
And now this has big problems. Since, for example, IPFS uses ed25519 keys, which are used all over the world and due to key incompatibility it is not possible to combine torrents and IPFS (and many child components)
Perhaps the transition to keys that the whole world uses would give us more opportunities and ready-made libraries for use in torrents. This choice is the most preferable. Although more expensive.
Or it would be absolutely wonderful to change the ed25519 standard to the one used in torrents. But I think this is extremely unlikely.
I found some illogical problems in the standard.
The text was updated successfully, but these errors were encountered: