Open master255 opened 1 year ago
The ed25519 keys in torrents
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
Throughout the world, a private key is 32 bytes of the seed + 32 bytes of the public key.
This is incorrect, there are several ways to do it: https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/
@the8472
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. For this purpose, different names of algorithms are used so that they can be distinguished from each other.
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.
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).
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. If it says everywhere that Ed25519 keys are used, but in reality keys generated using golang crypto or Java Bouncycastle are not suitable, then this will cause problems in development. And if the keys in the DHT torrent correspond to the global Ed25519, then it will be possible to duplicate data in different DHTs and eventually merge them (different DHTs). Since there will be no problems with key incompatibility.
@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.