Tag Info

Hot answers tagged

9

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


9

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


6

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


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


5

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


5

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


5

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


3

1) FTP is a bit odd that it's still done, but phone and SMS don't normally require keeping logs of the content, so there is less information that can be subpoena'd. It's also the least easy for them to encrypt in such a way that information would reliably be protected from their legal requirements to cooperate for any insecure e-mail sent to them. 2) The ...


3

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


3

PGP only works when both users are using PGP and already exchanged each others public keys over a trustworthy channel. When you want to send an email to someone you never had contact with you can not do that. Also, there is no good way for a web-based service to store the users keys on their own computer. There are features like cookies and localstorage to ...


3

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


3

One cannot tell whether an implementation of CMS (aka "PKCS#7) is secure by looking at the produced file; at best, one could spot interoperability issues. I did not spot any interoperability issue right away; you use OAEP padding with RSA, which might be considered as bold (OAEP support is not completely widespread right now) but still conforms to the ...


3

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


3

It depends if the CA is behaving properly when issuing certificates and if the person has been to your site before. If a CA is behaving properly when you get your certificate, they should not keep your private key. In fact in many cases, you can actually form your own private key if you wish. Provided that you have the only copy of the private key, all ...


3

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


2

If you have confidence in the security and policies of the company issuing the certificate (that they would not issue one to someone else for addresses in your domain) there should be no difference. Most of these shops offer the free e-mail certificates as a way to advertise to you for Web server certificates and the like. Many of the paid offerings provide ...


2

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


2

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


2

Openssl has all the command-line utilities you need. It can work on x509 certificates and can also deal directly with S/MIME content. The verify utility is specifically for doing certificate chain validation, but that function is also built in to the S/MIME utility.


2

That's because of "enforced". PGP uses a Web of Trust which is, by nature, decentralized. To enforce things, you need some hierarchical structure with a central point of decision, which X.509 provides (in this case, through the "self-signed CA at headquarters). In the PGP model, each user is the center of his own world and cannot be dictated his trust.


2

Let's give it a chance: If you have a key which expires in a year, all the data sent signed with that key within that year is valid forever (unless the key have been exposed), the problem here is, has the data or the application which uses it the correct information about when it was generated? (date signature stamp). A different problem may be, hey, you ...


2

Some established CA will agree to sell you an intermediate CA certificate, but at a rather steep cost. There are several forces at hand here: An "established CA" is "established" by virtue of having its root key included in the usual browsers and OS. The CA operator could achieve that by signing a heavy contract with Microsoft, in which he promised to ...


1

When you say password, are you referring to the password for the email account, the password to secure the s/mime cert, or the smartcard password (pin)? Ultimately the attacker needs access to the private keys so it depends how they're stored. If they're on a smartcard, then the smartcard must be present to perform the cryptographic operations. If they're ...


1

Lavabit indeed had a master private key, and it was used to encrypt the username and password as it was sent to Lavabit's servers. No matter what Lavabit did from that point on to secure the data, the NSA had collected the SSL session data and saved them for later use. With the private keys, they could decrypt the passwords that were sent over the Internet. ...


1

Just save a very small script. You could even run it using a cron job. This code will read a file, search for each line on the default keyserver, extract found key IDs and recieve them. Call as search-friends-keys.sh myfriendlist.txt if file names used accordingly. If using as cron job, watch out to run the script in the correct user context (not as root)! ...


1

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


1

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


1

The de jure standard is RFC 5751. In particular, see section 2.5.3: among the attributes which can be attached to a signature (a SignerInfo) is one called "SMIMEEncryptionKeyPreference" which identifies the certificate that the sender would like people to use when they send encrypted replies to him. The certificate itself is supposed to be included in the ...


1

AS2 builds over S/MIME, so you need a certificate for S/MIME. Certificates for S/MIME are very similar to certificates for SSL, but some details may vary. See this answer for some details. You might want to generate your own certificates with some tool like OpenSSL. Godaddy is an established CA whose main asset is that their root public key is already known ...


1

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a ...



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