Hot answers tagged

34

Notably, PGP is not the problem. The problem lies with the mail handling apps in your browser which you have allowed to use your PGP keys. Those browser apps decrypt the message as they should, but inside that message in addition to your secret is a trojan URL which is an attackers site. Your browser app stupidly tried to connect to the URL which has your ...


20

PKCS#7 is an old standard from RSA Labs, published later on as an "informational RFC". Then, a new versions was produced, as an "Internet standard", i.e. with the seal of approval from the powers-that-be at IETF; a new name was invented for that: CMS. Newer versions were subsequently defined: RFC 3369, RFC 3852, RFC 5652. You can consider CMS and PKCS#7 to ...


13

Yes, a nation-state adversary can get a valid certificate for any site from any CA which they have power over. Whether it's legal or not is probably another question which I'm not qualified to answer. Keep in mind that, even if a hijacked CA starts signing certificates with CNs of popular websites like google.com in order to MITM their traffic, it will be a ...


12

Disable HTML rendering. (Not HTML sending: HTML rendering. It doesn't matter what mail you send; what matters is what your mailer does on receipt of the adversary's mail.) Consider configuring your mailer to disable automatic PGP key download, S/MIME OCSP verification, S/MIME CRL download, S/MIME intermediate CA download; consider periodically updating ...


11

From what information is out there, it seems like the most likely scenario was that the US Government wanted these companies to install back-door technology into their systems and give the government agencies access to all the information that flows through them; these companies would be ordered to not disclose the backdoor nor the government's involvement. ...


11

The main reason to prefer one technology over the other is usability. Regardless of the tools you use, email security will depend mostly on how well the users cooperate -- most of the confidentiality of their emails rests on their ability not to do anything stupid with their data, and to react appropriately in unusual conditions. You will get decent security ...


11

Yes you can. This example uses openssl smime with the default RC2 CBC with a 40-bit key. The newer cms sub-command behaves slightly differently, and uses 3-DES by default. You probably shouldn't be using either of those algorithms to encrypt important data ;-) There are two minor caveats: firstly, I'm also going to use a couple of other tools (though ...


11

A hierarchical public key infrastructure is when some Certification Authority (CA) issues certificates to a lot of sub-entities: the CA signs certificates to guarantee the link between an identity and the public key owned by that entity. The PKI is hierarchical in that there are few CA and each CA signs certificates for a lot of people. In a Web of Trust, ...


10

It's not standard for a commericial CA to insist on making your private keys. For reasons you mention. Here's a link pointing to a collection of CA providers that suggests (and rightfully so) that the typical thing is for your browser to create the key pair and then send the Certificate signing request to the CA. In my experience with high end Verisign ...


10

It's usually a costs vs. benefits decision. Costs: Create your own CA infrastructure or buy a public certificate for each sender Teach employees how to use it Teach employees how not to use it, especially how to make sure that the secret key is really kept secret Teach the customers what this strange stuff in the mail means Properly deal with certificate ...


9

There are details spelled out in RFC 3850. In practice: It is highly recommended to include your email address in your certificate, in a Subject Alt Name extension (or possibly as an extra attribute in the subjectDN but this is deprecated). If the certificate does not contain the email address, your correspondents will have to find another way to associate ...


9

There is another solution apart from disabling HTML rendering - which you nonetheless should. This is a list of affected clients and webmailers1: The efail attack in its current form relies first and foremost on a client vulnerability. If you are using one of the affected clients, you might want to think about changing to another one for the time being, ...


8

The EFF's SSL Observatory has generated a map of all Certificate Authorities. This map is so massive, there is a very high likelihood that one of these is compromised at any given time. The principle of the weakest link makes me quite wary of our PKI. Furthermore, it is trivial for a nation-state to afford that cost of becoming a delegate authority. A good ...


8

Signing emails is useful only insofar as recipients verify the signature. Theoretically, signing the emails might improve deliverability, but only if a recipient configures his filters for incoming emails to verify email signatures and accept emails which have been verified to come from you. However, this is only theoretical; in practice, email filtering is ...


6

Though a CA does not need the private key to issue a certificate, certificates for S/MIME will be used for encryption: once you have an S/MIME certificate, people will send encrypted emails to you, and the emails will remain encrypted in your mailbox. This implies that losing your private key (e.g. your compute hard disk fails, or your laptop is stolen) ...


6

EKU is Extended Key Usage; this is a certificate extension described in X.509 (RFC 5280), section 4.2.1.12. As the RFC says: In general, this extension will appear only in end entity certificates. because, contrary to "Certificate Policies", there is no notion of inheritance and propagation of EKU along a certificate path. The EKU extension tells ...


6

The digest calculation is described in CMS (the new name for PKCS#7), section 5.4. Namely, when there are signed attributes, then what is signed is an encoding of the set of attributes; since one of the attributes contains the hash of the data file on which the signature object applies, this signature extends to the data file. See this paragraph: A ...


6

There are several issues with email: Interaction with other email users without OpenPGP. You either reject them entirely or you have the receiving server do the encryption. Both of these are problematic. Silent circle chose the latter: People expect email to work universally, so we had to accept unencrypted mail from outside clients, which we then ...


6

The current advice is to avoid automatically decrypting the email in your email client. In most cases that means uninstalling the relevant plugin. You then need to copy the encrypted text to a separate application to view it. You should still be able to send encrypted mail, provided that the receiver is taking the appropriate precautions, although that ...


6

Short term fixes There are two short term fixes to choose between: Disable HTML rendering in your email client. (And note that's rendering HTML, i.e. viewing it, not sending it.) Stop decrypting email in your email client (e.g. by disabling the PGP plugin), and instead copy paste the encrypted data into a separate program to do the decryption. The EFAIL ...


5

For a single certificate, a PEM encoded format is common, this is the text/base64 one that is delimited by: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- Most systems should accept .crt and .pem extensions for this file type, the former is slightly preferable for a certificate, .cer may work too. PEM is an encoding of data using base64 for the ...


5

Yes, but this would be difficult to do without it being discovered. From a purely technical standpoint you're correct, there's nothing stopping a nation-state from compelling a Certificate Authority under their jurisdiction from issuing them a fraudulent certificate, and most TLS clients (including web browsers) will silently accept that certificate without ...


5

Theory is that everything works automatically. Practice sometimes differs. I suppose that you are talking about S/MIME and X.509 certificates. With S/MIME, when you send an email: The email is encrypted with the public key of the recipient, so you have to know the current recipient's certificate. The email is signed with your private key and the signature ...


5

1: The advantage of S/MIME over PGP is that you sign/encrypt a complete mime entity, not a text. This makes it possible to sign/encrypt an entire message/rfc822. Yes, headers must be visible and changeable to the MTA, but that can be accomplished by taking the WHOLE mail, S/MIME sign or encrypt it, and then package the signed/encrypted S/MIME entity it in a ...


5

You can sign with both PGP and S/MIME. Contrary to Oliver Schmidt's response, it is possible to create an external signature using PGP (you can sign any file with a PGP key, not just text - a executable (.exe) is not a good candidate for inline signatures). This is referred to as "PGP/MIME". An external signature on a PGP file will be *.sig and S/MIME will ...


4

In X.509, all revocation goes through objects signed by certificate issuers. The decision to revoke or not revoke is not in the hands of the certificate owner, but of its issuing CA. The CA makes its decision known by including or not including the target certificate serial number in the CRL it produces (ditto for OCSP responses, which are just CRL with a ...


4

The theory is that as long as you keep your old keys, your email software will still be able to decrypt your received emails. That the certificate is expired means that other people won't accept to use your old public key to send you new encrypted emails, but reading your mailbox on your side does not entail using your public key or your certificate, only ...


4

OpenSSL's smime app supports an older S/MIME format using PKCS#7 CMS, I'm guessing (partly based on the standards.txt distributed with OpenSSL) this is S/MIME Version 3. The cms app in newer versions supports S/MIME v3.1 format messages, which use a newer CMS specification , so it's still S/MIME. The pkcs7 app handles only PKCS#7 v1.5 data, not any of the ...


4

If you go to Comodo's page for the free S/MIME certificate, you may have a look at the "Subscriber agreement" which includes, in section 3.1, the following: The Subscriber's web browser will automatically generate a Private Key/Public Key pair during the signing up process. So it seems that the process involves a locally generated key pair, as it should. ...


4

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem. The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the ...


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