Draft paper linked from efail.de.
TL;DR: the vulnerability is in some popular email client software, often combined with an extension simplifying the use of an OpenPGP (e.g. GnuPG) or S/MIME implementation within the said software; e.g. an extension bundled in popular distributions of GnuPG v2, thus common.
The issue is that un-validated deciphered ...
There are a few parts to the EFAIL attacks.
Some parts are the fault of the mailer authors for exposing unnecessary attack surface via arbitrary incoming email. Some parts are the fault of the OpenPGP and S/MIME designers for failing to heed modern cryptography engineering principles—in particular, failing to provide NM-CPA public-key encryption.
It seems that PGP certificates have the problem that they can be changed by the user. Furthermore, there were extensions for 1.2 that are incompatible for 1.3 (if they were secure in the first place):
I found this on the TLS mailing list from Ilari Liusvaara:
Ugh, the situation is way worse than what I thought.
Basically, all three assume they have ...
Forward secrecy is a confusing term that should be abandoned, especially the meaningless but value-loaded variant ‘perfect forward secrecy’. It is especially confusing because it is often associated with any protocol that does ephemeral DH key agreement, like TLS—even if, as in TLS<1.3 session resumption, the keys capable of decrypting transcripts of ...
Because P-256 is the most used elliptic curve and there are no certain reasons to believe it's insecure.
It's the first standardized curve at the 128 bit security level (which is very popular).
The rumors about its backdoor came from 3 factors:
The Snowden's revelations included a generic claim of the NSA trying to backdoor NIST standardized crypto
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:
Real name: Anonymous
You selected this USER-...
The "s2k" options correspond to the String-to-Key specifiers. An s2k transform turns a human-compatible symmetric secret (a password or passphrase) into a symmetric key suitable for a symmetric encryption or MAC algorithm.
Turning passwords into keys is tricky business because passwords that human can remember and accept to type tend to be weak with regards ...
"If PGP and GPG both follow the OpenPGP standard, are they 100% compatible in all use cases?"
No, they are not 100% compatible in all use cases, because — depending on the PGP version — there are known interoperability problems.
The GNUPG FAQ answers this question quite well:
Is GnuPG compatible with PGP?
In general, yes. GnuPG and newer PGP ...
The risk mainly resides in compatibility.
See, not all GPG users/systems are updated to the latest version. If you look at the GPG changelogs, you'll notice ECC was first introduced to GPG with version 2.1 in 2015:
Support for Elliptic Curve Cryptography (ECC) is now available. ⇒more
None of the pre v2.1 versions of GPG support ECC, which is something that ...
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 en.kryptotel....
If Bob does NOT care to check signatures (as in the question), Eve can send ANY message she wants to Bob pretending to be Alice, including but not limited to messages Eve got from Alice; all Eve needs is Bob's public key (which, as the name implies, is assumed public knowledge thus known to Eve) and straight use of PGP.
Therefore the right question is: Can ...
From this answer:
The difficulty of factoring (thus, as far as we know, the security of RSA in the absence of side-channel and padding attacks) grows smoothly with $n$.
So, if factoring is the method of choice for breaking RSA, it doesn't seem like it really helps.
It is the keypair that is doing the encrypting, not the one doing the decrypting, that the expiration date applies to. And yes, they will be able to decrypt it after one week. In fact, they will always be able to decrypt it. The expiration date only applies to the key and is nothing more than a gentle reminder that the key is supposed to be replaced and ...
From my understanding, if an attacker is able to decrypt a session key which was encrypted through a public key, then the attacker practically has the corresponding private key pair.
Effectively yes, however only for that single message. Note that session keys are chosen independently and so leaking one doesn't allow you to guess any others. The public key ...
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 ...
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 ...
GnuPG may ask you to enter the passphrase for the key. This is required because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol.
I guess that answers it. Though if anybody knows more, feel free to share.
In RSA, assuming knowledge of the public key but not the private key, analyzing any number of triplets of matching message, encrypted message, and signature $(m,M,sg)$, does not help (as far as we know) towards recovering the private key $s$ (nor an equivalent). That's regardless of the sensible padding or RSA variant used (as long as neither the padding nor ...
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$$
$$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 ...
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 ...
OpenPGP is a hybrid cryptosystem. The actual message is encrypted applying a symmetric cipher like AES with a random session key. This session key again is encrypted using a public/private key cryptography algorithm like RSA. This is mostly because symmetric encryption is much faster than public/private key cryptography, especially for large messages. As the ...
From the manual of GnuPG:
To help safeguard your key, GnuPG does not store your raw private key on disk. Instead it encrypts it using a symmetric encryption algorithm. That is why you need a passphrase to access the key. Thus there are two barriers an attacker must cross to access your private key: (1) he must actually acquire the key, and (2) he must get ...
GPG's AES-256 symmetric encryption is believed to be as secure as it is difficult to
guess the passphrase
or compromise the machine used to perform encryption and decryption.
Guessing the passphrase should be harder if one uses
gpg --s2k-mode 3 --s2k-count 65011712 --s2k-digest-algo SHA512 --s2k-cipher-algo AES256
or equivalently puts in the gpg.conf ...
"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 ...
How does one verify a key revocation?
As Jon Callas already stated: you simply don’t.
In case a different wording helps, here’s a quote related to the exact same question… https://lists.gnupg.org/pipermail/gnupg-users/2014-February/049100.html
I revoked my key and on the public key server it says: "* KEY REVOKED * [not verified]" Why does ...
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.
The difference is inconsequential in this context.
If you do some "processing" (e.g. generating a RSA key pair) using a deterministic and publicly known algorithm (e.g. OpenSSL's code) where the only parameter which is not known to the attacker is a random $n$-bit seed (e.g. $n$ = 256 for 32 bytes from /dev/urandom), then there is a theoretical possibility ...
OpenPGP as defined by RFC 4880 knows two different encodings.
Obviously, there is no reasonable limitation to an (ASCII) character subset in binary encoding.
Radix 64 is also often called ASCII armored. In the end, it is a base64 encoding with a checksum. The content may consist of [a-zA-Z0-9+/=].
ASCII-armored OpenPGP messages ...
The abbreviations stand for the following:
pub -- public primary key
sub -- public sub-key
sec -- secret primary key
ssb -- secret sub-key
In asymmetric cryptography you always have key pairs: A public key to encrypt, a private (secret) key to decrypt. Here we have two key pairs: (1, 3) and (2, 4). They can be identified by their identical fingerprints.
how does gpg know which cipher is needed (in this case AES256 instead of the default CAST5?
The OpenPGP Symmetric-Key Encrypted Session Key Packet (RFC 4880, §5.3) says which algorithm.
wouldn't it be "better" to not tell anyone what encryption type was used?
Not really. This is a basic premise of essentially all serious cryptography for more than a ...