Client Key/Certificate Algorithm update

As per PR syncthing/syncthing#10162, the paragraph in doc should be updated about the usage of the ED Curve (ED25519).

Maybe a note about the impossibility to use the ED448 to due Go current limit (syncthing/syncthing#10854 (comment)), would be nice. What do you think?

docs/dev/device-ids.rst

Lines 11 to 66 in 56d35a6

    
           Keys 
        
           ---- 
        
           To understand device IDs we need to look at the underlying mechanisms. At first 
        
           startup, Syncthing will create a public/private keypair. 
        
           Currently this is a 384 bit ECDSA key (3072 bit RSA prior to v0.12.5, 
        
           which is what is used as an example in this article). The keys are saved in 
        
           the form of the private key (``key.pem``) and a self signed certificate 
        
           (``cert.pem``). The self signing part doesn't actually add any security or 
        
           functionality as far as Syncthing is concerned but it enables the use of the 
        
           keys in a standard TLS exchange. 
        
           The typical certificate will look something like this, inspected with 
        
           ``openssl x509``:: 
        
               Certificate: 
        
                   Data: 
        
                       Version: 3 (0x2) 
        
                       Serial Number: 0 (0x0) 
        
                       Signature Algorithm: sha1WithRSAEncryption 
        
                       Issuer: CN=syncthing 
        
                       Validity 
        
                           Not Before: Mar 30 21:10:52 2014 GMT 
        
                           Not After : Dec 31 23:59:59 2049 GMT 
        
                       Subject: CN=syncthing 
        
                       Subject Public Key Info: 
        
                           Public Key Algorithm: rsaEncryption 
        
                           RSA Public Key: (3072 bit) 
        
                               Modulus (3072 bit): 
        
                                   00:da:83:8a:c0:95:af:0a:42:af:43:74:65:29:f2: 
        
                                   30:e3:b9:12:d2:6b:70:93:da:0b:7b:8a:1e:e5:79: 
        
                                   ... 
        
                                   99:09:4c:a9:7b:ba:4a:6a:8b:3b:e6:e7:c7:2c:00: 
        
                                   90:aa:bc:ad:94:e7:80:95:d2:1b 
        
                               Exponent: 65537 (0x10001) 
        
                       X509v3 extensions: 
        
                           X509v3 Key Usage: critical 
        
                               Digital Signature, Key Encipherment 
        
                           X509v3 Extended Key Usage: 
        
                               TLS Web Server Authentication, TLS Web Client Authentication 
        
                           X509v3 Basic Constraints: critical 
        
                               CA:FALSE 
        
                   Signature Algorithm: sha1WithRSAEncryption 
        
                       68:72:43:8b:83:61:09:68:f0:ef:f0:43:b7:30:a6:73:1e:a8: 
        
                       d9:24:6c:2d:b4:bc:c9:e8:3e:0b:1e:3c:cc:7a:b2:c8:f1:1d: 
        
                       ... 
        
                       88:7e:e2:61:aa:4c:02:e3:64:b0:da:70:3a:cd:1c:3d:86:db: 
        
                       df:54:b9:4e:be:1b 
        
           We can see here that the certificate is little more than a container for the 
        
           public key; the serial number is zero and the Issuer and Subject are both 
        
           "syncthing" where a qualified name might otherwise be expected. 
        
           An advanced user could replace the ``key.pem`` and ``cert.pem`` files with a 
        
           keypair generated directly by the ``openssl`` utility or other mechanism.

This confused me for a bit when setting up Syncthing, the documentation said that the client keys are based on ECDSA, so I wanted to manually replace them with ED25519 keys using openssl (peace of mind, etc).

So while checking the format of the keys already present on the configuration folder, I saw that that cert.pem already was a ED25519 certificate.

While most users won't really care about this, "power users" that do check the cryptography will probably be concerned that ECDSA is used and will either try to change it (and be confused because the documentation is outdated) or they will just consider some other software for whatever they wanna do.

fix(dev): update device ID documentation to Ed25519 (fixes #1028) (#1029

Navigation Menu

Repository navigation

Client Key/Certificate Algorithm update #1028

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	Keys
	----

	To understand device IDs we need to look at the underlying mechanisms. At first
	startup, Syncthing will create a public/private keypair.

	Currently this is a 384 bit ECDSA key (3072 bit RSA prior to v0.12.5,
	which is what is used as an example in this article). The keys are saved in
	the form of the private key (``key.pem``) and a self signed certificate
	(``cert.pem``). The self signing part doesn't actually add any security or
	functionality as far as Syncthing is concerned but it enables the use of the
	keys in a standard TLS exchange.

	The typical certificate will look something like this, inspected with
	``openssl x509``::

	Certificate:
	Data:
	Version: 3 (0x2)
	Serial Number: 0 (0x0)
	Signature Algorithm: sha1WithRSAEncryption
	Issuer: CN=syncthing
	Validity
	Not Before: Mar 30 21:10:52 2014 GMT
	Not After : Dec 31 23:59:59 2049 GMT
	Subject: CN=syncthing
	Subject Public Key Info:
	Public Key Algorithm: rsaEncryption
	RSA Public Key: (3072 bit)
	Modulus (3072 bit):
	00:da:83:8a:c0:95:af:0a:42:af:43:74:65:29:f2:
	30:e3:b9:12:d2:6b:70:93:da:0b:7b:8a:1e:e5:79:
	...
	99:09:4c:a9:7b:ba:4a:6a:8b:3b:e6:e7:c7:2c:00:
	90:aa:bc:ad:94:e7:80:95:d2:1b
	Exponent: 65537 (0x10001)
	X509v3 extensions:
	X509v3 Key Usage: critical
	Digital Signature, Key Encipherment
	X509v3 Extended Key Usage:
	TLS Web Server Authentication, TLS Web Client Authentication
	X509v3 Basic Constraints: critical
	CA:FALSE
	Signature Algorithm: sha1WithRSAEncryption
	68:72:43:8b:83:61:09:68:f0:ef:f0:43:b7:30:a6:73:1e:a8:
	d9:24:6c:2d:b4:bc:c9:e8:3e:0b:1e:3c:cc:7a:b2:c8:f1:1d:
	...
	88:7e:e2:61:aa:4c:02:e3:64:b0:da:70:3a:cd:1c:3d:86:db:
	df:54:b9:4e:be:1b

	We can see here that the certificate is little more than a container for the
	public key; the serial number is zero and the Issuer and Subject are both
	"syncthing" where a qualified name might otherwise be expected.

	An advanced user could replace the ``key.pem`` and ``cert.pem`` files with a
	keypair generated directly by the ``openssl`` utility or other mechanism.

Client Key/Certificate Algorithm update #1028

Description

Activity

girlf4ngs commented on Aug 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions