Luca Saiu — public keys

I value privacy and encourage everyone's use of strong cryptography for private communication.

[FIXME: I have to move the now obsolete information about X.509 certificates for this site to a new section at the end]

[FIXME: I have to replace some now obsolete information about my use of GNU PG or OpenPGP. I use p≡p for encrypting my email now. See my little blog post about p≡p-mail-tool for a general introduction, even if many details have already changed since then.]

Visit cards

Of course you have no particular reason to trust the information you read on this site over an HTTP connection, or even over HTTPS unless you trust my certificate. If we meet in person you can ask me one of my visit cards, containing a printed copy of my GPG key fingerprint; I always carry a few cards in my wallet.

Obsolete: server certificate fingerprints on my visit cards

2022-03-28: I gave up on this, in order for my web site not to be too penalised by search engines.

Starting from late August 2016 every card also includes an SHA256 fingerprint of the X.509 certificate used on this server. If you have an older version with only the GPG fingerprint the best you can do is asking me a copy of the certificate information; I will send it to you by GPG-signed email.

[FIXME: update: I am about to change certificates]
My visit cards now have an "updated" date. The current version is dated 2022-01-11.

My server X.509 certificate [obsolete]

2022-03-28: I gave up on this, in order for my web site not to be too penalised by search engine.

For the layperson: this information lets you check that the machine you are connecting to is actually my server, rather than some machine belonging to an impostor who wishes to eavesdrop your traffic.

Why my certificate is self-signed

My certificate is self-signed and I do not plan to ever submit it to a certification authority, as I see no particular reason to trust any entity to guarantee the authenticity of third-party keys; on the other hand the reasons to distrust them abound, as shown for example in this hilarious Mozilla bug report highlighting the inherent conflict of interest of commercial enterprises engaged in this activity, particularly after they become well established. The current political climate makes the argument even stronger, considering that most authorities are based in the US. Even authorities not suspected of any wrongdoing might well engage in the same practices as the famous ones you are thinking about now: US gag laws make it impossible for the public to know, which puts the last nail in the coffin of the credibility of CAs.

Certificates are important, and they should never be accepted blindly: when you accept a certificate tentatively, you should consider the entire exchange to be potentially spied on and tampered with while it happens; in other words the connection is to be treated as no more secure than an unencrypted one. In order to convince yourself that the server you are connected to actually is what it claims to be, you'll have to do your due diligence; and no, this activity cannot be simplified down to the level of the typical Apple fanboy who only understands graphical user interfaces.

If you want to see the authentic fingerprint of my server certificate you can ask me for a visit card, as explained above. You are also welcome to request a copy of the information by GPG-signed email, if you have reason to trust my GPG key — for example my GPG key may have been signed by enough people you know and who can attest that I care about security.

Certification Authorities providing certificates for free

Since a few people asked I clarify that my statements in the previous section also apply to Let's Encrypt, which doesn't magically become trustworthy thanks to its non-profit status. It may very well be run by completely honest people, as some of the commercial entities might be as well; the point is that we, the public, do not have any reason to grant them confidence. We should also keep in mind that the Internet Security Research Group is US-based.

CACert.org issues (gratis) certificates supposedly made credible by a Web of Trust; I have to look into its activity in more detail, but as far as I understand there is no technical reason to trust the organization not to provide false certificates; are the actual certificates provided by CACert signed by people in my (GPG, or other) web of trust? That model would work, but I cannot see how it can integrate with the idea of adding CA root certificates to web browsers. In practice the degree of trust I would assign to each server certificate would very according to how close I am, in WoT terms, to who approved it, making the issuing authority irrelevant. I am probably missing some detail, but such an arrangement sounds similar to my visit card system.

Certificate information

The certificate described here dates from 2022-01-11. I replaced the old certificate ageinghacker-a.pem, which is now no longer in use; ageinghacker-b.pem has been in use just for a few days.

I use the same certificate for HTTPS and email, plus most other non-public services on this server.

You can download my X.509 certificate in PEM format here as ageinghacker-c.pem. Its SHA256 fingerprint is

31803489ffa3da2474887178e7b7c7589a32c43a867fcc6fe92cc8636b99ce11

. Its SHA1 fingerprint is

8c25ad3385afaad88a6ffb0c76eb45415a271ce2

, but you should not use SHA1 as it now appears to be vulnerable to collision attacks.

This is the information printed by

certtool --certificate-info

. You should check that it matches what your client says.

X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 0bce2474609fc302745c97f0cc7130c17faa8849
	Issuer: CN=ageinghacker.net
	Validity:
		Not Before: Tue Jan 11 19:15:54 UTC 2022
		Not After: Wed Dec 30 19:15:54 UTC 2071
	Subject: CN=ageinghacker.net
	Subject Public Key Algorithm: RSA
	Algorithm Security Level: High (4096 bits)
		Modulus (bits 4096):
			00:a4:01:e6:78:6b:bb:6d:67:4c:11:d7:51:22:c4:68
			92:c8:8b:a6:30:69:38:42:15:00:f4:49:25:a0:38:4e
			2a:b6:af:77:54:30:c7:1d:50:b4:da:5c:c4:c4:92:a1
			37:52:42:88:97:52:08:6f:a4:c5:71:46:08:2c:ed:dd
			2b:4a:53:e6:1c:ef:7f:70:c5:8a:80:08:d1:32:56:4d
			2a:0c:68:96:41:9b:c3:36:3a:b7:db:2c:36:f7:e7:b6
			0f:2e:4b:03:36:7e:cb:d5:69:a1:74:a9:32:c8:83:ed
			f2:ce:6c:5e:af:61:36:91:e7:e6:ce:2b:fb:5c:87:fe
			d5:46:c4:2e:af:39:36:6e:bd:26:df:62:08:d6:5a:fd
			6a:b5:47:45:6d:45:93:f1:af:29:20:45:3d:02:2c:de
			6b:12:c5:13:89:97:2c:23:1b:0f:69:dc:32:9a:34:22
			b2:ca:7f:42:66:ff:41:eb:7f:f7:8f:a8:9e:ee:31:73
			30:e1:59:c1:ab:13:ec:b8:91:62:8e:60:66:2c:d8:af
			de:5f:e8:3e:54:8b:eb:f1:7d:c7:e5:61:16:9e:ce:8b
			d9:cb:aa:5b:e7:b4:f4:cd:f6:cc:d4:a6:d6:a0:f6:eb
			4b:25:df:8e:9a:07:99:40:cc:e2:9a:d8:77:98:48:0a
			93:56:31:6d:d5:5a:26:23:ad:47:45:42:c0:7b:d8:f8
			f2:7d:97:d9:4d:c9:16:3f:77:b5:7d:48:85:b9:1b:1a
			a6:f2:be:43:94:e0:6e:32:d3:c3:66:36:f8:27:9b:9b
			bb:a2:d7:e7:27:eb:87:3f:96:a5:28:69:ab:76:8a:f6
			f8:7b:ae:d0:e5:b9:fa:5b:f3:e2:09:66:e9:e9:ad:d9
			75:a3:83:4b:45:d9:a3:e3:59:fb:83:43:e7:39:f2:66
			06:75:91:83:b7:48:c3:f5:88:dd:74:9a:60:f0:d3:f5
			fb:82:f5:26:09:33:ec:d1:8d:32:98:d6:d7:ce:6c:15
			fd:3a:7c:6a:fe:79:21:c2:85:ac:e9:16:64:ee:09:2c
			4e:28:63:35:e5:e0:04:1f:51:2d:20:10:cc:fa:4b:d7
			f6:c6:13:f3:3a:e5:88:32:ef:7d:9e:7c:93:5c:57:00
			bc:20:11:8e:0c:df:07:ec:cb:ba:5b:7e:e6:3a:e2:dd
			2f:9a:c4:3b:7c:76:ad:b8:45:3f:e0:06:e2:bb:5b:6e
			3a:0f:61:4a:c5:0d:39:82:8f:a0:50:43:6a:3c:c5:de
			69:48:0d:cf:9d:a4:76:05:a8:30:a1:60:05:6d:c5:72
			33:85:f3:65:8f:0c:73:2a:74:a8:f8:32:af:2b:58:41
			25
		Exponent (bits 24):
			01:00:01
	Extensions:
		Subject Alternative Name (not critical):
			DNSname: ageinghacker.net
			DNSname: aginghacker.net
	Signature Algorithm: RSA-SHA256
	Signature:
		49:b5:14:57:76:c2:b1:d8:81:85:1d:5c:27:9a:7f:ed
		96:4a:9a:25:54:d7:c1:d3:f9:c9:9d:3c:b8:b5:99:b6
		00:b3:90:cd:1c:ec:7b:2b:33:02:75:ef:79:3b:2e:50
		24:7a:5b:6e:ef:d1:b7:4b:24:78:f1:01:26:76:f2:f3
		4a:57:0b:b7:c1:e9:9b:57:62:17:15:09:81:3c:ea:28
		80:20:cb:a6:ae:aa:d1:7e:2c:8b:2a:8b:f7:6b:c1:b8
		6e:64:a8:4b:31:c7:dd:d4:66:d1:ad:3c:c5:14:bc:73
		45:89:17:7e:8a:dc:4d:48:b9:8c:89:2b:e2:a3:5a:0f
		1a:e9:3d:dc:2a:39:97:e5:6b:73:e3:2a:d1:95:7f:a5
		2f:d2:e6:ee:94:4e:5d:54:98:c8:9c:a6:39:aa:d8:68
		1c:b2:8d:dd:3c:c3:15:38:3b:7a:30:bd:1d:36:36:7d
		89:bc:be:cd:b7:fe:86:ff:77:c2:7b:12:bb:fe:f8:65
		68:a2:05:76:71:4a:39:17:76:cf:c2:48:f2:a3:9d:14
		d1:88:a0:a7:a5:9d:ce:34:00:80:43:24:b0:c4:17:f5
		55:7d:40:8c:d6:56:51:69:e0:cc:31:6f:2e:b4:95:e5
		47:1d:2f:a8:05:92:8a:11:12:e1:e8:2a:4c:db:ec:c2
		f4:6f:42:65:c8:6d:2b:b3:56:25:db:2a:a2:a9:1a:78
		8f:d1:c4:66:49:20:67:fd:41:d7:42:c5:21:5e:36:da
		ac:4b:26:bf:1f:d6:37:d1:39:18:b4:f7:af:b6:05:06
		4a:a9:49:6a:17:dd:32:2d:fe:8d:29:ee:d9:ae:82:37
		5a:a2:d3:29:ca:c6:d9:c1:95:c7:cc:bb:dc:34:5d:42
		52:c2:7e:47:57:75:cb:2a:de:08:5d:00:38:b4:78:31
		c7:0b:e9:88:ab:bf:08:6d:03:93:9a:de:2a:1d:31:5f
		c7:06:bf:13:85:43:a7:09:a8:df:af:e2:5c:d5:20:a3
		53:fe:65:31:af:18:b6:8b:d2:bc:da:40:a5:f2:6c:69
		fc:39:82:26:ca:5e:92:d5:73:98:8a:ea:8b:91:46:6a
		c4:bf:a4:9b:71:28:be:15:da:e9:03:52:73:69:7d:ab
		aa:0e:64:8f:28:58:48:a5:00:08:8f:fd:1b:fc:6d:88
		b4:bc:5a:73:5f:a9:40:09:8a:01:bd:c1:3d:9a:86:8b
		d4:7d:41:f3:da:ab:87:a9:f6:f2:8a:15:a3:8a:ed:31
		48:63:18:4c:13:bf:a6:86:e5:59:81:b5:eb:74:3b:12
		87:17:f5:db:0c:2e:a4:1e:98:d7:54:ff:3b:f0:14:78
Other Information:
	Fingerprint:
		sha1:8c25ad3385afaad88a6ffb0c76eb45415a271ce2
		sha256:31803489ffa3da2474887178e7b7c7589a32c43a867fcc6fe92cc8636b99ce11
	Public Key ID:
		sha1:63e639d34d0a960ff08ae28963d71eedca482642
		sha256:0ec0784ac42252e3f307b21a72f381381f7943474b1851312477f5fc66682caf
	Public Key PIN:
		pin-sha256:DsB4SsQiUuPzB7IacvOBOB95Q0dLGFExJHf1/GZoLK8=

-----BEGIN CERTIFICATE-----
MIIE9jCCAt6gAwIBAgIUC84kdGCfwwJ0XJfwzHEwwX+qiEkwDQYJKoZIhvcNAQEL
BQAwGzEZMBcGA1UEAwwQYWdlaW5naGFja2VyLm5ldDAgFw0yMjAxMTExOTE1NTRa
GA8yMDcxMTIzMDE5MTU1NFowGzEZMBcGA1UEAwwQYWdlaW5naGFja2VyLm5ldDCC
AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKQB5nhru21nTBHXUSLEaJLI
i6YwaThCFQD0SSWgOE4qtq93VDDHHVC02lzExJKhN1JCiJdSCG+kxXFGCCzt3StK
U+Yc739wxYqACNEyVk0qDGiWQZvDNjq32yw29+e2Dy5LAzZ+y9VpoXSpMsiD7fLO
bF6vYTaR5+bOK/tch/7VRsQurzk2br0m32II1lr9arVHRW1Fk/GvKSBFPQIs3msS
xROJlywjGw9p3DKaNCKyyn9CZv9B63/3j6ie7jFzMOFZwasT7LiRYo5gZizYr95f
6D5Ui+vxfcflYRaezovZy6pb57T0zfbM1KbWoPbrSyXfjpoHmUDM4prYd5hICpNW
MW3VWiYjrUdFQsB72PjyfZfZTckWP3e1fUiFuRsapvK+Q5TgbjLTw2Y2+Cebm7ui
1+cn64c/lqUoaat2ivb4e67Q5bn6W/PiCWbp6a3ZdaODS0XZo+NZ+4ND5znyZgZ1
kYO3SMP1iN10mmDw0/X7gvUmCTPs0Y0ymNbXzmwV/Tp8av55IcKFrOkWZO4JLE4o
YzXl4AQfUS0gEMz6S9f2xhPzOuWIMu99nnyTXFcAvCARjgzfB+zLult+5jri3S+a
xDt8dq24RT/gBuK7W246D2FKxQ05go+gUENqPMXeaUgNz52kdgWoMKFgBW3FcjOF
82WPDHMqdKj4Mq8rWEElAgMBAAGjMDAuMCwGA1UdEQQlMCOCEGFnZWluZ2hhY2tl
ci5uZXSCD2FnaW5naGFja2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAgEASbUUV3bC
sdiBhR1cJ5p/7ZZKmiVU18HT+cmdPLi1mbYAs5DNHOx7KzMCde95Oy5QJHpbbu/R
t0skePEBJnby80pXC7fB6ZtXYhcVCYE86iiAIMumrqrRfiyLKov3a8G4bmSoSzHH
3dRm0a08xRS8c0WJF36K3E1IuYyJK+KjWg8a6T3cKjmX5Wtz4yrRlX+lL9Lm7pRO
XVSYyJymOarYaByyjd08wxU4O3owvR02Nn2JvL7Nt/6G/3fCexK7/vhlaKIFdnFK
ORd2z8JI8qOdFNGIoKelnc40AIBDJLDEF/VVfUCM1lZRaeDMMW8utJXlRx0vqAWS
ihES4egqTNvswvRvQmXIbSuzViXbKqKpGniP0cRmSSBn/UHXQsUhXjbarEsmvx/W
N9E5GLT3r7YFBkqpSWoX3TIt/o0p7tmugjdaotMpysbZwZXHzLvcNF1CUsJ+R1d1
yyreCF0AOLR4MccL6YirvwhtA5Oa3iodMV/HBr8ThUOnCajfr+Jc1SCjU/5lMa8Y
tovSvNpApfJsafw5gibKXpLVc5iK6ouRRmrEv6SbcSi+FdrpA1JzaX2rqg5kjyhY
SKUACI/9G/xtiLS8WnNfqUAJigG9wT2ahovUfUHz2quHqfbyihWjiu0xSGMYTBO/
poblWYG163Q7EocX9dsMLqQemNdU/zvwFHg=
-----END CERTIFICATE-----

My ECDSA and RSA server host keys

The RSA and ECDSA server host keys, useful for example to connect over SSH and check against man-in-the-middle attacks, are abelson-rsa-a.pub and abelson-ecdsa-a.pub.

Recent SSH clients use an ECDSA key to identify a host. You can verify the ECSDA key fingerprint with:

ssh-keygen -lf abelson-ecdsa-a.pub

which is supposed to print:

256 SHA256:yY/8catPSSH2Uk9AymUNp975yKucOOsEag266BbE9l8 root@vps43244 (ECDSA)

This is how you can check the RSA kay's SHA256 fingerprint:

ssh-keygen -lf abelson-rsa-a.pub

If the public key you downloaded is authentic, the output must be:

2048 SHA256:ArFvprNQNe5plchnAikM16Sgqyz37eIvajzQ0Ll/cyk vps43244.iceservers.net (RSA)

Older SSH clients show the RSA key's MD5 fingerprint, which is also easy to check:

ssh-keygen -lf abelson-rsa-a.pub -E md5

The output should be:

2048 MD5:07:71:43:51:2f:d9:84:1c:f3:c5:d2:98:7b:eb:f9:ec vps43244.iceservers.net (RSA)

My GPG public keys

For the layperson: you need this key if you want to make sure that I am the actual author of a GPG-signed message you received from somebody claiming to be me, or to send me a GPG-encrypted message which nobody but me can read.

Most of my e-mails sent from computers I trust have been GPG-signed since 2007.

My GPG key A

The 1024-bit GPG keypair I have been using for many years was generated on 2007-03-29, and is set not to expire; still, I will revoke it at some point in the future and switch to my GPG key B only.

You can find it my GPG key A here as gpg-a.asc and, for convenience, on several keyservers as well.
The key fingerprint is

14DC72EB19F7D2E6C12E113CBF339ABE26C5D286

. Nowadays it is better not to use only the last four bytes, to avoid collision attacks. You should always consider a key ID to be an indivisible 20-byte sequence.

My GPG key B

I generated a new 4096-bit keypair in September 2019. I am in the process of switching to it as my only key. You can verify that my keys A and B are signed by each other.

You can find it my GPG key B here as gpg-b.asc.

Its fingerprint is

08C6A9408241E6ED99A0A2767A6B35253722954D

. At the time of writing it is only signed by itself and by key A. More signatures will come.

If you receive a message signed or encrypted with my GPG key B, you may see one of the following subkeys:

For encryption: 9F62CE8B0786820B933427A50AC73BFE55E17D22 (rsa4096 2019-09-22);
For signing: DB806800E939D5F0611BCD0DD9D4C006F09088D1 (rsa4096 2019-09-22);
For encryption: 2F7B12FD253CF4ECC9255D7053D8C1B7F801D54D (rsa4096 2019-09-22).

It is easy to verify that they are in fact subkeys of key B:

gpg --with-subkey --list-keys 08C6A9408241E6ED99A0A2767A6B35253722954D

My lost GPG key from 2003, `0x586648D5`, not to be used

Please do not use the old key with ID 0x586648D5, back from 2003. It was indeed mine, but I lost the associated private key in a disk crash years ago back when I was naïf enough not to keep backups of these important things. Unfortunately there is no way for me to revoke it.

My OpenSSH public keys

For the layperson: you only need these keys if you want to give me shell access to a machine of yours.

I use several different RSA key pairs, depending on which client machine I'm physically on.

By convention RSA public keys are written on single, very long lines; since this notation makes them clumsy to display in inline HTML, I publish each key as a separate text file.

You can check the fingerprint of your copy, interactively, with

ssh-keygen -l

. The utility will ask you the pathname.

My OpenSSH RSA public key #1

A 4096-bit key pair. You can find the RSA public key here as ssh-a.
Its fingerprint is

4096 SHA256:Ll2MioFd5FahanPMe92GfaC7lOr+knZc34ErMmjU4Ok luca@optimum (RSA)

My OpenSSH RSA public key #2

A 2048-bit key pair. You can find the RSA public key here as ssh-b.
Its fingerprint is

2048 SHA256:Stv9EwRz86soXbzE/3njfuvqtNzy37bX2wNIwoQl+l0 luca@lucalaptop (RSA)

My OpenSSH RSA public key #3

A 2048-bit key pair. You can find the RSA public key here as ssh-c.
Its fingerprint is

2048 SHA256:dcE6nRF7RHO0JDR/WNweFJdJNTHorMEjG1GTXS7u9nI luca@ritchie (RSA)

My OpenSSH RSA public key #4

A 2048-bit key pair. You can find the RSA public key here as ssh-d.
Its fingerprint is

2048 SHA256:0CYsQgalAnprKHbfUnMEaQWb7WR/5T4vETC9LMXMxss luca@minsky (RSA)

My OpenSSH RSA public key #5 (obsolete)

I no longer use ssh-e.

My OpenSSH RSA public key #6

A 2048-bit key pair. You can find the RSA public key here as ssh-f.
Its fingerprint is

2048 SHA256:YPotJhZoKmHlA2+/Zzx3Pjtu/bk44F/ZOe5FkAzObII luca@moore (RSA)

Luca Saiu
Last modified: 2024-01-11