Is there a human readable easier version to represent PGP Private keys?

I'm working on a distributed application, and we need a way to authorize clients. Every client has a PGP keypair associated with them, and we require them to enter their private key (which is not stored) through which their pubkey is derived and used to identify clients and modify their fields on the distributed database.

Now, considering user experience, entering a private key on a website whenever you need to do something is troublesome. But we also cannot maintain a central database for username/password based authentication as that creates a single failure point (not what the distributed application is meant to do)

I am hoping there is some way to get an easier to remember human readable descriptor of the private key which can be used to authenticate - if something like that exists. Any other ideas are appreciated too.

P.S. - For background, I am not a cryptographer, I am a computer developer, so I don't fully understand how PGP works - excuse me if this is a noob question.

• My spider sense is tingling. Why are you entering a PGP private key into a webserver? They're only meant to be kept on Post-its stuck to the screen, and never entered into servers. And they're used for asymmetric encryption, not authentication. Is PGP the solution here, or is re-architecture necessary? – Paul Uszak Aug 27 '19 at 13:50
• @PaulUszak I understand and share your concern. I am not sure how else I can authenticate users another way in this distributed database design where any information on chain is public to all members -- im not sure how safe having hashed passwords be visible to all participants of the network would be, having the pubkey there which is checked against by deriving it from the privkey seems safer to me – Ryder Aug 27 '19 at 18:16
• Okay. It seems to me that input from an architect might be appropriate here. Or a consultant who knows distributed systems like Oracle's stuff. Those systems have all authentication and professionally architected cryptography built right into their modules. Expensive stuff though, but secure with experienced input. But a little off topic. P.S. An authentication system isn't a single point of failure with clusterware, hot standbys, failover, hot migration, K8s and all that cloudy business. But complicated beyond anything you can hope to achieve with simple PGP... – Paul Uszak Aug 27 '19 at 21:08
• PGP keys are commonly not stuck to post its, they are stored on computers or external devices or even smart cards, protected by password based encryption if they are stored as a file. Authentication is one of the listed use cases for PGP keys, although signature generation and decryption is likely much more common. But Paul is right about one thing: you don't let the server know your private key, it's not a secret key after all. – Maarten Bodewes Aug 27 '19 at 23:03
• Sorry if this is a noob question, but what is the difference between a private and secret key? Is that something better used for authentication? I was thinking we'll encrypt the private key with the public key of the expected receiver so MITM won't work. @MaartenBodewes – Ryder Aug 29 '19 at 18:01

Apparently this answer will be updated as OP develop an understanding of his application. I've never used PGP, but general public-key cryptography concepts are always applicable.

entering a private key on a website whenever you need to do something is troublesome

You can let clients derive their keys through memorable string - the user agent first derive a seed using a secure key derivation function (KDF) from 1) the user-supplied string, and 2) a random salt, then the seed is fed to a cryptographic deterministic random bits generator (DRBG), then the key-pair generation is run using the just-seeded DRBG.

Normally a hard-to guess 16-character string with upper and lower case letters and digits is a minimum. The salt should be a string of at least 16 fully-random bytes.

If you don't have a database of users, how do you authenticate them (recognize actual users from outsiders)? There is a solution: Use primitives that binds the authenticator to the public key, such as ECQV implicit certificate scheme, or identity-based encryption (IBE). These are not commonly-used public-key cryptography functionalities, and their post-quantum equivalents are far from mature.

• How long does the user supplied string need to be? Can a simple password style string work? On those lines, how strong should the salt be? On your second point, we do have a database of users, but it is distributed as part of a private blockchain. The information on chain is public to all participating members on the network. A simple way would be to just store hashed passwords on chain, but they would be visible to multiple participants, I am not sure how safe that is. – Ryder Aug 27 '19 at 13:05
• @Ryder Updated for you. – DannyNiu Aug 27 '19 at 13:10
• Thanks! Since I am not a cryptographer, are KDF's and CSDRBG functions easily available for use? FWIW, Im using Golang. – Ryder Aug 27 '19 at 13:15
• PBKDF2 is widely available in many languages, that's what I know. But even you do have CSDRBG, you still need key-pair generators that works deterministically and takes user-supplied seed. If you can't find CSDRBG (more commonly called CSPRNG), try SHAKE-128/256 or XOF (eXtensible Output Function). – DannyNiu Aug 27 '19 at 13:23
• Note (again) that any changes in the key pair generation mechanism or CSDRBG will break this kind of scheme. – Maarten Bodewes Aug 28 '19 at 0:34

Yes, there is BIP39(Bitcoin Improvement Proposal )in the Bitcoin protocol. That converts a hex private key in to a list of 12 to 24 human readable words.

For example you have a cryptographic key

E9873D79C6D87DC0FB6A5778633389F4453213303DA61F20BD67FC233AA33262


Gets converted to:

witch collapse practice feed shame open   despair creek road again ice least


BIP 39 has implementations in all major programming languages.

There is also an older & less popular spec(1994)from the Internet Engineering Task Force called RFC 1752.