I like to store mine on paper.
Here's some that should work for you no matter what operating system you use, as long as you have a browser that ...
Option 1 is more secure. In option 2, we can guess each word seperately. When we guess "amazing", we get confirmation that this word is correct and we can continue to the second word. In option 1, we have to guess all four words at the same time.
You may think that one GPG offers some security, and four GPGs offer four times that security, but it doesn't ...
Yes, it's a coincidence that the first bytes appear to you as these symbols. They are part of the OpenPGP message format specification (RFC 4880) and vary depending on the packet properties.
Let's create a file containing only those bytes and try to read it as a GPG message:
$ echo "\x85\x02\x0c\x03" > foo.gpg && gpg --list-packets foo.gpg
# off=0 ctb=85 ...
On the days when my paranoia is like a ripe tomato, begging me to pick it, I split the private key (naturally it is already passphrase-protected) in half, then make a 3rd string by XOR-ing them together. Then I use simple password encryption (gpg --symmetric) on each string, and put each on a remote server on a different continent. Ideally, each remote ...
TL;DR: private keys are called private for a reason.
You can secure private keys by not transmitting them at all.
If you have shell access to the server they are used at, you simply generate them in situ.
If the target device is too weak/underpowered to generate the keys, it is also too weak to use asymmetric encryption (this includes entropy sources). Of ...
Why not use a commonly used application to do it? VeraCrypt is a good choice as it replaced the respected TrueCrypt application and allows you to create an encryption container that you mount as a drive.
How the Fingerprint and Long and Short Key IDs are Related
Each OpenPGP key has a fingerprint attached, calculated mainly from its public key packet which also contains the creation time. The calculation is defined in RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints.
There are short and long key IDs, which resemble the lower 32 respective 64 bits of the ...
I figured out what the problem and solution was so I give an answer with details should anyone run into the same problem, it may be helpful.
The problem is somewhat ambiguous, no really informative error message is given.
It turned out that the encryption sub-key was expired. Strangely, gpg --list-keys did NOT show the expired sub-key!! Once the sub-key ...
There are three main reasons why you may want to have separate keys:
Not all key types can be used for both encryption and signature. OpenPGP (the format that GnuPG implements) primarily supports RSA, ElGamal and DSA; ElGamal is encrypt-only, while DSA is sign-only. RSA can do both; however, there was a time when RSA was still patented, and since that time ...
since it's known that the NSA infiltrated RSA and made their key generation algorithm weaker
If you know that, then you know wrong. You are confusing two things which have no relation whatsoever:
RSA, the asymmetric cryptographic algorithm.
Dual_EC_DRBG, a PRNG algorithm of poor quality and amenable to backdooring.
RSA can be used for asymmetric ...
Does it store the secret key somewhere and uses it (I also stored my secret key in the GnuPG key chain, does it uses that)?
GnuPG only uses keys from your key chain, so it must be in there to use it.
How can I force the system to ask the passphrase every time?
Old versions of GnuPG uses the gpg-agent, which caches the passphrase for a given time. Use ...
I find some of your comments curious. Particularly,
I'm trying to stay away from methods that are reliant on an application, and do it manually - as I'd feel more in 'control'.
I don't need to solution to be incredibly secure, prioritising on convenience for this use case.
do seem somewhat at odds with each other.
First, you really should spend ...
GitHub itself is signing commits made through the online editor using the key 0x4AEE18F83AFDEB23:
GitHub will automatically sign commits you make using the GitHub web interface. These commits will have a verified status on GitHub. You can verify the signature locally using the public key available at https:/...
It can actually be done.
The instructions at atom.smasher.org/gpg/gpg-migrate.txt are now out of date.
Try this. As always, make backups, because it's really easy to mess it up.
So these are your 'old' keys:
$ gpg -K
sec 2048R/712A2BBD 2013-01-29
uid Test Key 1
This is not what I currently use, but I am thinking about it:
Encrypt the private key with very long symmetric encryption key
Use Shamir's Secret Sharing to split the symmetric encryption key to 7 pieces (like Voldemort), require at least 5 shares to merge successfully.
Figure out where to put 7 secret backups, some ideas:
media card in a safe at home
First, I create a 500 MBytes file full of random bytes:
dd if=/dev/urandom of=/tmp/foo bs=1000000 count=500
then I encrypt it using GnuPG, measuring the time taken by that process ("keyID" is the UID of the public key I am using):
time gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o /tmp/bar --encrypt /tmp/foo
This doesn't add security, but makes it easier to guess the passphrase one word at a time (N⁴ vs. N+N+N+N, where N is the symbol count of the word list). Even when you encrypt a file or a message to multiple recipients using PGP, the payload is encrypted only once using symmetric encryption, and then the key for that is encrypted separately for every ...
TL;DR: For GnuPG 1.0 and 2.0, default is Cast5, for GnuPG 2.1 it is AES-128.
Per default, GnuPG will read the recipient's algorithm preferences and take the first algorithm in that list it supports (in other words, it takes the most-preferred supported algorithm the recipient asks for).
If no preferences are given (or -...
GnuPG does not support encrypting to a recipient specified by a key file. The key must be imported in advance, and the recipient defined with either his mail address or key ID.
I'd recommend to use a cleaner approach as expected by GnuPG and hard-code either the key's fingerprint, or a user ID given by that key and import it as usual.
If you really do not ...
GPG can allow you to send these securely without having to send a passphrase. If the destination has their own GPG key, you can encrypt the file so that only they can open it.
For example, the following command will allow me to only open thefile.zip with my GPG key without either of us ever communicating a passphrase.
gpg -e -r E9053BDA thefile.zip
Considering that your public key is only usable by a computer1; you can remove clutter from your business card by having all electronic data accessible online and referred to by a QR code.
The link could refer to a vCard file stored on, say, a public Dropbox. As the vCard format can store any business or contact information including OpenPGP keys.
OpenPGP User IDs
User IDs in OpenPGP are used to connect keys to entities like names and e-mail addresses. These are used to search for keys on key servers, and matching them to users/e-mail addresses.
Be aware user IDs are not checked by key servers, make sure to verify them on your own!
OpenPGP Key IDs
OpenPGP key IDs (and fingerprints) are used to ...
Theoretically, there's no limit on the number of times you can encrypt a file. The output of an encryption process is again a file, which you can again pass it on to a different algorithm and get an output.
The thing is, at decryption side, it will have to be decrypted in LIFO (last in, first out) style, with the proper passwords.
For example, if your file ...
There is no contradiction. Linus himself said in that same talk:
If I have those 20 bytes, I can download a git repository from a
completely untrusted source and I can guarantee that they did not do
anything bad to it.
I'd interpret the "Git uses SHA-1 not for security" as "SHA-1 hasn't been added to git for security reasons, but for reliability ...
RFC 4880, OpenPGP, 11.1. Transferable Public Keys defines subkey packets are always preceded by a public (primary) key, thus GnuPG does not allow to export it separately.
To do so anyway, export the key (it is recommended to use --export-options export-minimal to reduce the number of packets you have to deal with), and use gpgsplit on it, which will ...
This post by user rjh from 2008 in the enigmail forum answers it well:
Originally in PGP 2.6, back in the early 90s, you had just one keypair
and it was used for both encryption and signing. The ability to have
additional keypairs presented some engineering challenges. Ultimately,
it was decided that the additonal keypairs would be called "subkeys",
What's your threat model?
If your threat is that you are protecting from physical theft, then encrypting the key (using passphrase) or full disk encryption would suffice.
If your threat is a malicious program running under your user account, then you want to run potentially malicious programs in a sandbox, or just not run it at all.
If your threat is a ...
You can set every key to ultimate trust through opening the key edit command line
gpg --edit-key [key-id]
and running the trust command. You will now be prompted to select the trust level:
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I ...
There are things which can be done, depending on how much technology-...