PGP was considered dangerous because it could have allowed Soviet spies and military officers to plan the nuclear annihilation of the western world without the CIA realizing what's happening before it's too late.
Time for some history.
During World War II, the importance of cryptography for military use became apparent. Being able to crack enemy ...
Quote from Wikipedia:
Although PGP keys are generally used with personal computers for
Internet-related applications, key signing parties themselves
generally do not involve computers, since that would give
adversaries increased opportunities for subterfuge. Rather,
participants write down a string of letters and numbers, called a
public key ...
In general, one key per identity should be fine.
One key can include:
Several UIDs (for separate mail addresses, ...)
Several subkeys (for different devices, so you can put some subkey on your mobile; if it gets lost, revoke only this)
Less hassle when signing keys, interacting with keyservers, cross-signing your keys
Less hassle maintaining ...
Summary: S/MIME and PGP both provide "secure emailing" but use distinct encodings, formats, user tools, and key distribution models.
S/MIME builds over MIME and CMS. MIME is a standard way of putting arbitrary data into emails, with a "type" (an explicit indication of what the data is supposed to mean) and gazillions of encoding rules and other ...
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 ...
tl;dr: the expiry date is no reasonable mechanism to protect the primary key, and you should have a revocation certificate at hand.
The slightly longer version is, that the effect of the expiration date differs between primary and subkeys, and also what you aim to prevent.
For subkeys, the effect is rather simple: after a given time frame, the ...
SSL/TLS protects the email from tampering or eavesdropping as it transits between your computer and Google's server, and possibly during further relays to eventual recipient. And that's all it does.
PGP does far more. If you're sending a signed email, the recipient can verify that the email was sent by you, and that it was not tampered with at any point ...
Your PGP private key is encrypted at rest. Altering the passphrase re-encrypts your private key, but it does not affect the actual private key itself. Your passphrase is used to encrypt your private key. From How PGP Works:
PGP uses a passphrase to encrypt your private key on your machine. Your private key is encrypted on your disk using a hash of your ...
In the OpenPGP format (that PGP implements), a given email can be encrypted for several recipient with only minute per-recipient size overhead. This is because email encryption actually uses hybrid encryption:
A new random symmetric key K is generated for the email to encrypt.
The bulk of the email is encrypted with a symmetric encryption algorithm, using K ...
It's not that hard, why isn't it standard for years?
Because that would not have solved the problem that PGP is trying to solve.
PGP is an end to end encryption, so if there is any way for the SMTP server to subvert the encryption, then the scheme fails.
In the case of the scheme you proposed, suppose Alice (firstname.lastname@example.org) wants to send a private ...
About Using Subkeys
Use one primary key for each identity you need, otherwise, use subkeys.
Examples for using multiple primary keys:
You don't want to mix up your private and professional keys
You need some key not connected with your "real life" identity, eg. when prosecuted by the authorities
Examples for using subkeys:
You want to use multiple keys ...
Generally speaking, no, encrypting the same file with the same key will not produce the same file, for three reasons:
The OpenPGP format (which GnuPG implements) uses hybrid encryption: a random, symmetric key is encrypted with the recipient's public key (of type RSA or ElGamal), and that symmetric key is itself used to encrypt the message body with a ...
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 ...
The two statements speak of completely different things. They don't contradict each other. That does not make them both true, though.
PixelPin: this product apparently replaces the password by the selection of four positions on a picture. This means that you choose a picture, and your "password" is the sequence of coordinates for four points you choose on ...
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 ...
There is always a risk that any given cipher will be broken at some point and data like this will become truly public. So yes there are some risks but it doesn't mean you aren't making a reasonable security trade-off.
A few things you may want to consider:
What's your worse case scenario with the data going public and are there implications to this data ...
Removing a Local-Only Signature
If the signature is still only kept locally (either by never sending it to anybody or the key servers, or by even having performed an lsign which creates signatures that cannot be uploaded), you can actually delete it by running
gpg --edit-key [keyid]
[select a uid]
[go through the assistant for deleting signatures]
When you authenticate to Github with your SSH key, that authentication doesn't become part of the repository in any meaningful or lasting way. It causes Github to give you access for the moment, but it doesn't prove anything to anyone who is not Github.
When you GPG-sign a git tag, that tag is part of the repository, and can be pushed to other copies of ...
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 ...
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
RSA isn't really built to encrypt large pieces of plaintext. Each RSA "round" can encrypt 117 bytes of data, and to encrypt more, you'd have to use some chaining mode. Currently, this means extra overhead, slowness (remember, RSA is pretty slow), and security uncertainty (RSA-chaningMode hasn't been scrutinized as other types of encryption schemes). <- ...
integrating PGP into SMTP.
PGP is a container format for data (like mails but not restricted to mails), which adds encryption and/or signature to the data.
SMTP is a transport protocol.
You don't integrate container formats into transport protocols. This would be the same as saying that you should integrate Office (container for text, images...) with SMTP ...
Firstly, that statement doesn't mean "don't bring a computer"; it means " you don't need to bring a computer". Many people going to their first key signing party are likely to assume that, since the keys are intended for use on computers, they will need to bring a computer containing their keys, signatures, or encryption software. What actually happens is ...
RSA is not used directly due to several reasons:
RSA encrypts only messages with a limited size. With a 1024-bit RSA key, RSA (as per PKCS#1) can process only 117 bytes of data. To encrypt more than that, one would have to do some chaining, i.e. split the data to encrypt into several 117-byte blocks and encrypt them separately. This is routinely done for ...
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 ...
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
Total time on my ...
I have two viewpoints on this issue: one is based on historical facts (and is a bit technical), while the other is purely my own, original opinion.
Regardless, it seems indeed more secure, or at the very least more convenient, to use a separate key for signatures; that way, you only use your master key for certifications (and can store it away), and you don'...
The official GnuPG documentation regarding this output is rather awkward.
The OpenPGP trust model
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
By default, GnuPG uses the OpenPGP trust model. In this, you can put trust on a key, which allows it to validate other keys.
Keys can be trusted. Trust allows keys to validate ...
Signing mails is in my experience the best method to show others they can send you encrypted mail. If they're using OpenPGP anyway, their mail client might even automatically enable encrypted mails as replies to signed ones. Recently I was very surprised receiving (S/MIME) encrypted mail from both a bank and a health care institute, just because I signed the ...