Hot answers tagged pgp
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
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 ...
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
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
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 ...
8
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 ...
7
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 ...
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
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
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.
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
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 ...
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
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).
2
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 ...
2
The OpenPGP standard (RFC 4880) defines in section 3.7 a number of String-to-Key (S2K) conversion functions, which are used for password-encrypted messages (i.e. ones without using a public key scheme), as well as for (the secret part) in private keyrings.
Most probably the Iterated and Salted S2K will be used. Its specification includes a hash function ...
2
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 ...
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 ...
2
With asymmetric cryptography, the sender is not able to encrypt it such that the receiver could have encrypted it without disclosing a private secret without performing a symmetric key exchange. Once you exchange a symmetric key however, you could symmetrically encrypt the contents of the message and the MAC and then encrypt the shared key with the public ...
2
Yes, precisely because of what you're using PAR2 for.
Anyone with the PAR2 data and most most of the compressed
archives can easily calculate the rest of the compressed archives.
(In fact, they wouldn't even need the encrypted data!)
Yes, because anyone could calculate the error correction
data from the encrypted data, without the encryption key.
1
Yes, gpg -c file.zip does encode the input file name in the encrypted packet.
The gpg man page documents a few relevant options:
--set-filename string
Use string as the name of file which is stored in messages.
This overrides the default, which is to use the actual filename of the file being encrypted.
--use-embedded-filename
Try to ...
1
What is the main difference of the three? Can I use only one of them for everything (e.g. GPG for SSH authentication)
GnuPG is an free and open-source implementation of the OpenPGP standard.
Symantec PGP is a proprietary implementation of the OpenPGP standard.
The OpenPGP standard defines ways to sign and encrypt information (like mail, other documents ...
1
I am not sure to fully understand your question, but what you can do is the following: take $r=2^{512}$, and compute $p=r+\delta$ and $q=r-\delta^\prime$ such that $p$ and $q$ are prime numbers, and $0\leq \delta, \delta^\prime < 2^{32}$. Then you have an RSA key at you disposal that can be broken by a brute force search on $\delta$, which should take ...
1
There's no way in OpenPGP to MAC a message. You can sign it, but that's it.
We could have a lively debate about the legal ramifications of a digital signature, and I'll take the side that it means less than you've been told it has. Like everything, context matters. I could give you a use case where there'd be an approximately 100% likelyhood that a digital ...
1
Most hash functions ( it appears this includes S2k) are not memory intensive. As such you can run a bunch of computations of their iterated variants on a GPU very cheaply.
Scrypt, however, is designed to be memory intensive, so you can't really run it effectively in parallel without huge memory requirements.
1
Here's what pgpdump thinks of it:
New: Public-Key Encrypted Session Key Packet(tag 1)(142 bytes)
New version(3)
Key ID - 0xF940C4301A67779D
Pub alg - ElGamal Encrypt-Only(pub 16)
ElGamal g^k mod p(511 bits) - ...
ElGamal m * y^k mod p(511 bits) - ...
-> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 ...
1
Hmmm, Weird key... overly small, no allowable ciphers or hash functions - BC didn't fully implement RFC 4880 so it might be worth upgrading to BC 1.47 and 'new keys please'.
That aside I doubt it will be easy to validate the output of any given public key without it's coresponding private key, plus the planitext.
If you have this info, plus the issue you ...
1
Original Answer (StackOverflow)
Haven't got enough time to look up the details, but I would guess that you're applying (or not applying) padding correctly. That would cause the right result to come up for some input lengths, but not for others.
I guess I'll look into this more, but I wanted to get something in under the bounty wire :)
Edit: Ok, ...
Only top voted, non community-wiki answers of a minimum length are eligible
