Gpg where is private key stored

If you found this page, hopefully it's what you were looking for. It's just a brief explanation of some of the command line functionality from gnu privacy guard gpg. Please email me if you find any errors scout gmail. Filenames are italicized loosely, some aren't, sorry , so if you see something italicized, think "put my filename there. I've used User Name as being the name associated with the key.

Sorry that isn't very imaginative. That doesn't make any sense, sorry. This is a variation on: gpg --export which by itself is basically going to print out a bunch of crap to your screen.

I recommend against doing this. To fix that, run. Here is how: Identify your private key: Copy. Owner of this card: Thomas Eisenbarth. Say thanks. Privacy policy Terms of service Imprint.

Where to store public and private gpg keys? Ask Question. Asked 7 years, 6 months ago. Active 7 years, 6 months ago. Viewed 6k times. Can someone help out? Thanks in advance. Improve this question. Robson Braga. Robson Braga Robson Braga 4 4 silver badges 16 16 bronze badges. If you don't store them on disk, where would you imagine they could be stored?

I don't see how you can avoid it. I don't know, maybe in an usb device or a software key manager, I really don't know what is the best and possible alternative Add a comment. Active Oldest Votes. All security is a trade-off. Improve this answer. Craig Ringer Craig Ringer k 59 59 gold badges silver badges bronze badges. Regarding hardware devices - one can hold a copy of the keys elsewhere, so hardware failure is not a problem. Also USB cryptotokens are more usable on the client side they are too slow for server use.

For industrial use there are separate cryptographic devices offered there's a variety of them offered by SafeNet if you are interested. That's a great answer! Thanks a lot. I've already generated the private and public keys, that encrypt and decrypt the database, using GnuPG. My scenario is a RESTful API consumed by any kind of application, so I'll encrypt the public and private keys on disk, load it in-memory, on API initialization, keep it encrypted in-memory, in each API request I'll decrypt the keys passing it as a parameter to the database functions.

So neither the API nor the database knows the keys until it being loaded from disk. Is it good enough? Absolutely impossible to say whether it's "good enough". You need to do thread modelling - figure out what you're trying to protect against, what the possible resources of an attacker are, look into attack vectors, what the consequences of compromise are, etc.