Skip to content
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

Open
master255 opened this issue Sep 30, 2023 · 9 comments
Open

Wrong ed25519 keys? #146

master255 opened this issue Sep 30, 2023 · 9 comments

Comments

@master255
Copy link

master255 commented Sep 30, 2023

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.

@the8472
Copy link
Contributor

the8472 commented Sep 30, 2023

The ed25519 keys in torrents

Which field are you referring to? And which BEP?

@master255
Copy link
Author

@the8472 Apparently this http://bittorrent.org/beps/bep_0044.html

@the8472
Copy link
Contributor

the8472 commented Sep 30, 2023

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/

@master255
Copy link
Author

@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.

@master255
Copy link
Author

@arvidn Perhaps we need to add support for the global Ed25519 standard? This will fix all problems.

@jcea
Copy link

jcea commented Apr 6, 2024

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?.

@the8472
Copy link
Contributor

the8472 commented Apr 6, 2024

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.

@jcea
Copy link

jcea commented Apr 7, 2024

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.

@master255
Copy link
Author

Torrents do not use ed25519. BEP has a error and they refuse to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants