# Tag Info

58

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 ...

49

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. For ...

23

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 ...

21

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 ...

19

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 USER-... 18 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 ... 17 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 ... 17 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 DualEC ... 16 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 ... 15 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 of ... 14 "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 ... 12 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.... 12 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 ... 12 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. 12 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 ... 11 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 ... 10 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 ... 10 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 ... 10 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 ... 9 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 +... 9 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 ... 9 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 ... 9 man gpg... 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. 9 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 ... 9 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 ... 8 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. 8 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. 8 "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 ... 8 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 ...

8

OpenPGP as defined by RFC 4880 knows two different encodings. Binary encoding Obviously, there is no reasonable limitation to an (ASCII) character subset in binary encoding. Radix 64 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 ...

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