3 ms·
Reminds me of people where I worked having vanity GPG key ids. I'm wondering how much CPU time and on what machines it took to find them.
by burnt-resistor 1y ago
Reminds me of people where I worked having vanity GPG key ids. I'm wondering how much CPU time and on what machines it took to find them.
- rgovostes 1y agoFor vanity GPG keys, I came up with a neat trick where you could insert arbitrary ASCII art into your key. You construct your ASCII art using the Base64 character set. The decoded binary will be gibberish but you can place it in an inert Literal Data Packet that will be ignored by any conformant OpenPGP parser. It just takes a little finagling to align your data to a 3-byte boundary with appropriate line wrapping.
- wiktor-k 1y agoKey IDs are based on fingerprints and fingerprints are calculated by SHA-1 hashing the primary key's public key and the creation timestamp. A computationally easy way to influence the fingerprint is to tweak the creation timestamp which is a 32 bit Unix epoch value. Of course it needs to be in the past so the range is limited but it's faster to do it this way instead of recomputing the cryptographic key.
- yjftsjthsd-h 1y ago> the creation timestamp which is a 32 bit Unix epoch value. GPG keys aren't 2038-safe?
- dijit 1y agoPGP is pretty old at this point, and kinda jank. RFC 1991 only gives them 4 bytes (32bit); not sure if there have been any later additions to rectify this but I don’t think so since even the latest RFC (9580) has them listed as 4 bytes… https://datatracker.ietf.org/doc/html/rfc1991 https://datatracker.ietf.org/doc/html/rfc1991 https://www.rfc-editor.org/rfc/rfc9580#section-3.5 https://www.rfc-editor.org/rfc/rfc9580#section-3.5
- dpwm 1y agoIt's a 32-bit unsigned integer, so that should give us until Feb 2106. > A time field is an unsigned 4-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.