# Tag Info

10

GPG's (or OpenPGP's) public-key file encryption uses multiple steps: Generate a random session key encrypt the file using this random session key encrypt the random session key using the public key of the receiver (or using multiple keys in parallel, if the file is meant to be decrypted by multiple receivers). store the encrypted file together with the ...

9

If there is a vulnerability in encrypting a RSA private key with the corresponding public key, when the private key is password-protected, then it mechanically implies a vulnerability in the password-based protection scheme: if an attacker gets a copy of the password-encrypted key (without the password), he can encrypt it with the public key himself; so an ...

9

There is at least one way in which compression can weaken security; it has to do with the fact that essentially all methods of encrypting arbitrarily long message will inevitably leak information about the length of the input. The only way to avoid this leak is to pad all messages to a constant length before encrypting them — but if the messages are ...

9

A PGP encrypted message can be hundreds or even thousands of bytes. Encrypting and decrypting large amounts of data using asymmetric algorithms is extremely slow. Encrypting only 32 to 16 bytes (the symmetric key) is much faster. Additionally, if you encrypt the same message twice with an asymmetric algorithm, you will get the exact same ciphertext. Using ...

9

I think you misunderstood a detail of PGP encryption. Only the random symmetric key is encrypted under the recipient's (asymmetric) public key. This way to encrypt stuff is quite common and is called KEM/DEM paradigm: Key Encapsulation Method/Data Encapsulation Method oy Hybrid Encryption. Some refs: en.wikipedia.org/wiki/Hybrid_cryptosystem and ...

8

OpenPGP's "Iterated and Salted S2K" is just a single hash instance over a very long input, which consists in the repeated concatenation of the salt and the password. This is extremely GPU-friendly, especially when using a hash function which is built over 32-bit elementary operations (this category includes MD5, SHA-1, SHA-256 and RIPEMD-160; GPU are not as ...

8

There are several kinds of asymmetric cryptographic algorithms. All use some sort of mathematical structure, but not the same, and not all involve prime integers. RSA is the most well-known asymmetric algorithm, which includes several variants (e.g. for asymmetric encryption or for digital signature). In a RSA public key, there is a big integer called the ...

8

Technically, if you use a cryptographically secure encryption algorithm with a fresh random key in a confidentiality mode such as (full block) CFB, you don't have to worry about the redundancy of the plain text, since the cipher + mode combination is supposed to be secure even if significant parts of the plain text are known to the adversary. If the cipher ...

8

This is hidden well in RFC 4880, the OpenPGP message format specification. Section 5.7 explains how message data is encrypted. (I'm using the values for a 16-byte block cipher like AES.) A random block of data is created: $p_{1} \dots p_{16}$ The last two bytes of this block are repeated: $(p_{17}, p_{18}) := (p_{15}, p_{16})$. These 18 bytes (in case ...

6

GnuPG follows the OpenPGP format, which is a protocol in its own right -- it uses AES (among other algorithms) but is more complex than "just AES with the right parameters". There is at least one OpenPGP implementation in Javascript (I have not tried it, though).

5

According to How PGP Works it uses a hybrid approach that generates a secret key for symmetric encryption. The wikipedia page for GPG then indicates that CAST5, Camellia, Triple DES, AES, Blowfish, and Twofish are the supported ciphers.

5

The "signed on date" field of any signature message format is only trustworthy if you trust the signer to not modify the software to include an arbitrary date (or use a software which allows setting the date) or change his computer's system date. So, if the signer wants to use this field to prove that this was signed at some time (specially, before some ...

5

This sounds like a fair exchange protocol where what is exchanged is a digital signature. Per this paper, these are impossible without trusted third parties. With a trusted third party, they are possible. Indeed people have proposed schemes that do what you describe again relying on a third party in the case of failure.

5

The basic explanation is that you need both keys to make a complete encryption/decryption cycle. Basically the encryption works with modulo arithmetic so that $$c=m^a \mod n$$ and $$m=c^b \mod n$$ where $a$ and $b$ are the public and private key of the algorithm. $m$ is the plain text message and $c$ s the ciphertext. The most important thing about the ...

5

"Secure" is not a binary, black-and-white thing. Instead, it's about risk management. Instead of asking whether something is secure, it's better to ask whether it is "secure enough for such-and-such purpose". On the one hand, 1024-bit keys are uncomfortably close to what can be cracked, given lots of computational resources. On the other hand, for casual ...

4

No. The passphrase you use creates a symmetric key that is used to encrypt the private key. You're not uploading the private key to the server, at least let's hope you aren't. But even if you are doing that, the password is salted and iterated in hashing, and that means that the visible encrypted private key is radically different even if the password is ...

4

Magic! Have a look at the wikipedia image from the PGP article. The magic behind how the whole thing works is using through the RSA algorithm. Let's say Alice wants to send an encrypted message to Bob. Bob generates a public and private key pair. How the key generation process works is through a whole bunch of mathematics. Essentially, this is how RSA ...

4

Use gpg --s2k-mode 3 --s2k-count N, where N is the number of iterations you want to use. The manual page says the default is 65536, and you can use any number between 1024 and 65011712. If you like to tweak the defaults, I suggest making this number as large as you can bear it, without introducing noticeable slowdown (e.g., ideal would be to make the ...

4

KEM/DEM hybrid encryption has another advantage. It enables a very efficient multi-recipient encryption. The payload is encrypted and transmitted only one time. Haven't you wondered yet why you are able to decrypt and read your own message although it was encrypted with the recipient's public key? Normally PGP encrypts the message key for symmetric ...

3

Let Alice have a key pair (PubKeyA, PrivKeyA), where the first is public, the second private, and similarly for Bob (PubKeyB, PrivKeyB). Alice and Bob know each other's public keys in a reliable way (from a key server, or because they received them in person etc.) If we use RSA keys, e.g., then they could use just one pair, so I'll assume this first. When ...

3

OpenPGP is a protocol that uses various encryption algorithms in it. For public keys, they're either RSA, DSA, or Elgamal. Note that DSA is signing-only and Elgamal is encryption-only. DSA and Elgamal are variants of Diffie-Hellman and thus their relationship to prime numbers is slightly tangential. RSA keys are made of (typically) two prime numbers ...

3

From my understanding no. If you look at the OpenPGP spec section 3.7 it covers the String-to-Key (S2K) Specifiers which convers a passphrase to a key. Assuming the Salted S2K or Iterated and Salted S2K method is used (which is recommended) then reusing your passphrase shouldn't be an issue. The larger key has a larger length, which means the passphrase ...

3

Short answer: “No”. The latest research shows that compression actually harms security. "Reducing redundancy" is an outdated concept from the late 20th century. The intuition was that if our ciphers turned out to be weak, we might avoid a practical loss of confidentiality by giving attackers less information to work with. For example, in the following ...

3

Compressing the data increases the security a number of ways. It reduces an attacker's ability to affect the decrypted output by flipping ciphertext bits. It removes regular patterns in plaintext (it might create other regular patterns, but they aren't directly the plaintext). There are a number of attacks on OpenPGP that are thwarted by compression. Most ...

3

Yes, your public key includes your UIDs. It may be possible to delete all before exporting though - for sure you could copy the key, add an "anonymous" UID and delete all others. As long as you're not signing the message, nobody will know who sent the message (but have a look at the mail or other headers!).

3

You cannot remove all UIDs, but you can create one which does not link to your identity and remove all others. Backup your .gnupg folder (for unix systems, for Windows wherever your key is stored)! Start editing your key: \$ gpg --edit-key 47AB515A Create an anonymous UID: gpg> adduid Real name: Anonymous Email address: Comment: You selected this ...

3

Since your problem seems to be with the principle of public key crypto rather than with the math itself, here is an analogy with a physical object that may help. Take a key lock padlock as below: To close the padlock, you don't need the key, just the padlock itself. To open you use the key. Now, if Bob has a copy of Alice's padlock, he can send her a ...

2

No, the user of the key does. A revocation issued by the key itself, or by a designated revoker, which is some different key. If I am going to encrypt to you, I look at the key before I do, and I look to see if your key is revoked. Similarly, if I am verifying a signature your key made, I look to see if the key is revoked.

2

I believe the answer can be found in section 5.2.4, "Computing Signatures". According to that section, what you actually need to hash is the concatenation of: the key packet (with an old-style packet header with a two-byte length — but your sample key packet has that header type already), for the first (certification) signature, the constant byte ...

2

It's a statement made by the signer, just like if I say that this message was written on 19 June 2012. Its value is context-dependent. Just like with a pen and paper, you can post-date or pre-date anything. In general, there's no such thing as verified time. Over the years, there are many people who have tried to create trusted time services, but they've ...

Only top voted, non community-wiki answers of a minimum length are eligible