#26493  08/20/13 05:21 PM
secure email?

Registered: 08/04/09
Loc: Iowa

So with the snowden stuff and other nsainyourshower stuff going around lately I've been engaged in numerous related conversations about protecting one's privacy.
I was asked how I have private communications. I described how I have a public key for my email and mail auto signs my messages, and anyone can reply to me and click the lock and their reply is encrypted. And if they also had a key, I would get their public key and my replies to them would also be secure. I went into just how easy this is to use in Mac Mail and how it's automatic and transparent. This was important to do because even if you use ssl with your email provider, the nsa etc can simply demand your mail and gag them. (assuming they didn't just plain snatch the packets as they were traveling to your isp)
So I was describing how to get a key. Comodo offers them for free, you just... um..... wait a minute. OK ignore everything I just told you. Why?
Because the nsa just has to demand comodo give up all the private keys they've signed and gag them, and now they can read anything I try to encrypt.
so now I feel kinda dumb.... how do I go about rolling up my own keypair for email use? I realize the key being not signed by a "trusted" (can we all just roll around on the floor and laugh at that now?) authority will pop a message saying this is unsigned do you want to accept it?, but that's obviously the only "actually secure" method I see. Or is there something else?
(at least I roll up my own ssh keypairs, good luck with that...)
_________________________
I work for the Department of Redundancy Department

Top



#26497  08/20/13 09:40 PM
Re: secure email?
[Re: Virtual1]

Registered: 08/04/09

_________________________
The new Great Equalizer is the SEND button.
In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top



#26498  08/21/13 05:00 AM
Re: secure email?
[Re: artie505]

Registered: 08/04/09
Loc: Iowa

I'd rather just make a key and use osx's mail directly. I see no reason to run an addon for this. mail already does everything I need it to, I just need a keypair that I can trust. I'd be very surprised if OPENSSL can't create the keypair, but I don't know the proper way to do it. And with security, not knowing exactly how to do it makes it very insecure. (little innocent mistakes can easily break it in sometimes very hard to notice ways) Comodo makes .p7s files that my keychain auto imports. Opensl's man page mentions "PKCS#7" in several places, they are probably the same thing. After a brief search this morning I ran into this which may be what I need to do, but I don't have time this morning before work to play with it.
_________________________
I work for the Department of Redundancy Department

Top



#26514  08/24/13 06:08 PM
Re: secure email?
[Re: Virtual1]

Registered: 08/04/09

Because the nsa just has to demand comodo give up all the private keys they've signed and gag them, and now they can read anything I try to encrypt. A Certificate Authority never sees (nor signs) a private key. It creates certificates, which package public keys with identifying information, and signs the whole package to say, in effect "We the CA attest that to the best of our knowledge this public key belongs to the entity so identified." Someone you conduct a conversation with knows they're talking to you because:  We are successfully communicating when I use this public key, therefore you are in possession of the matching private key.
 The certificate says the public key belongs to the person I think I'm talking to.
 The CA says (by having signed it) that the certificate is truthful.
 I have checked the validity of the signature (by using the CA's root certificate).
 I believe the CA's root certificate (because it's in my keychain).
 I trust that the CA would not attest to something they do not believe (because why else would their root certificate be in my keychain?)
Therefore, you are the person I think I'm talking to. Only someone in possession of your private key can eavesdrop on the conversation. Your private key never leaves your hands. The only weakness is that certificates can be forged. A government may be able to compel a CA to issue an untruthful certificate, but the more likely scenario is that you're sitting behind a corporate firewall, and the firewall is forging certificates and signing them with a private key that matches a certificate that your employer installed on your keychain. A forged certificate allows a maninthemiddle attack. If you're behind such a firewall, you aren't necessarily talking to whom you think, and your company can eavesdrop on conversations protected only by outside certificates. They still can't eavesdrop on conversations protected by your keys. If it's the government forging your key, they can trick people into telling them things they think they're telling only you, and trick them into thinking you've signed things you haven't. But they still can't trick you. The remedy is to eschew certificates as a reliable way to validate public keys. For example: PGP uses the "web of trust" to validate public keys. Each public key is digitally signed by any number of people who attest thereby that they know it's your key. You review the list of people signing any given public key, and decide in your own fashion how much you trust each of them, and whether there is enough trust in all for you to trust this public key. To forge a public key, the NSA would have to compel many people you trust to sign their fake key. Fat chance of them doing that without word of that getting back to you. For example: iOS devices maintain a secure TCP connection with Apple all the time they're on. (Push notifications and suchlike come through this connection. Funneling disparate traffic through a single TCP connection reduces the battery cost to keep the session alive.) Your iPhone is born knowing Apple's pubic key, because it's built into iOS. There's no certificate involved. No way for NSA or anyone else to trick your device into thinking any other public key is the one to use. (And the public/private keys are used only to encrypt a DiffieHellman exchange to establish an ephemeral session key. Even if they record all the packets and later learn Apple's private key, they still can't decrypt the session.) And there's no way NSA could ever obtain Apple's private key, even using military force, and get away with it. Apple has lots and lots of highpriced lawyers who are all familiar with the final clause of the Fifth Amendment, which says "... nor shall private property be taken for public use without just compensation." The value of a company's private key is the value of the company itself. Nor would Apple's lawyers be the least bit daunted by any National Security Letter. They also know the First Amendment, which protects "the right ... to petition the government for a redress of grievances." If nothing else, even an NSL cannot prevent you from complaining to your congresscritters, who outrank the NSA. Trying to muzzle a large corporation from talking about the attempted theft of something as valuable as a corporate private key with something as flimsy as an NSL would start a firestorm on capitol hill that even the NSA would not survive. And they know it. (Actually, I secretly hope they don't. I'd love to see them knocked down a peg or too. Senator McCarthy thought he was above the law, too.)
Edited by ganbustein (08/24/13 06:14 PM)

Top



#26743  09/16/13 01:12 PM
Re: secure email?
[Re: ganbustein]

Registered: 08/04/09
Loc: Iowa

The last several times I have gone through the process, I logged in, requested a key, and was emailed a link to click to download the certificate (a .p7k file iirc) Double clicking that on os x automatically imports it to my keychain. the certificate can be viewed in keychain access.
Double click the cert and tick down the arrow to expand details. you will see it contains many things, but the most relevent here are:
 public key (256 bytes)  signature (256 bytes)  rfcc822 name (your email address)  key usage: verify, wrap, derive
Public/private key pairs work on one basic principle. You generate a private key, and from that a public key. the public key can be used to encipher something that requires the private key to decipher. (barring supercomputers in buildings with 3 letter initials)
This public key isn't really used as a public key for you. it has both an encipher/wrap AND derive, so it contains both a private and a public key.
After composing a message, the content, along with the public portion of the certificate, and with your email address are checksummed. this checksum is then encrypted using the private portion of the key, to form a signature. it's impossible to create the signature without the private portion, but due to the 'encipher/wrap' nature of the key, it's possible to verify the entire message was signed by the private portion of the key. Thus altering the message (which is still in plain text) cannot be done without updating the signature, which cannot be done without the public key, which only you have, therefore the receiver knows the message has not been altered or invented.
the public portion of the key is itself already signed by the issuing authority. in this way, the receiver knows the public portion is legitimate, (since OS X loads all the common CA's public keys/certs into the system and can verify their signatures) and already knows that certificate was used to sign the message (because it can be checksummed and encrypted using the public part of the key, and arrive at the same checksum), and therefore knows the message came from the person that had control of that email address at the time the certificate authority issued the cert.
This whole thing is called a "chain of trust". You have to trust your OS. from there, it contains "anchors", certs of major certificate authorities (CAs), and they in turn sign things like https/ssl things, presumably in an accountable way. There are also provisions in the os to override/cancel/replace an anchor if it becomes compromised. (we've seen this happen twice in the last few years, when a CA lost control of their private key)
This also means of course that if you "lose control" over your certificate, you have lost control over your private key portion of it, and therefore anyone with that key could sign an email that appears to come from your email address. That's why it's stored in your keychain, to protect it.
Now... reflecting on all of the above. It's impossible to ignore the fact that the CA generated the private portion of your key. You would have had to roll up a key pair locally on your machine, and then sent THAT to the CA to sign and return back to you. But you didn't. You downloaded a complete cert, with the private key they generated for you, in addition to the public key which they have signed for you. (which you could not do without their help, using their private key)
So they had your private key. They had to have it to do their job. Do they still have it? They have no reason to keep it. But who's to say they don't? or haven't just handed them all over to someone every day?
Just for completeness I'll throw in a bonus. When you receive a signed (and non enciphered) message, it includes their public key. OS X automatically imports that into your keychain. (look, you probably have a few already!) Now if that person sends you a message again, it will IGNORE the key for verification purposes, and use your local key. If they change, you WILL get a warning. Also, booya, you have their public key, and you KNOW it's their key, so you can hit reply and tick the padlock and mail will encipher the message before sending it. It's not signed, but just enciphered. you can't read it anymore. The only one that can is the one with the private key, the sender. (AAAND therefore, the CA that issued them their key too!) The receiver can also verify the message was not tampered with in the reply, but has no way of knowing for sure if it was YOU that sent it. Unless you have a keypair of your own. Once you two have exchanged public keys however, the system is secure. You may hear about a "key signing party", where people get together and sign each others public keys, and hand them around. If you work in a secure business, you may be required to roll up a key and have the business sign it. If they're doing things properly, they either won't ever have your private key, or will be keeping a VERY tight lid on it, even internally.
Correct me if I'm wrong on any of this. It's been awhile since I went through the jungle that is the official full explanation.
the only way around this is for you to roll your own key pair, and only send the public part of it to your CA to sign, and then get that back and merge it into a .p7k file. Unless you've done this, the CA had/has your private key. It is not under your absolute control, and may be copied secretly by force. (or stolen for that matter)
_________________________
I work for the Department of Redundancy Department

Top



#26750  09/17/13 03:56 PM
Re: secure email?
[Re: Virtual1]

Registered: 08/04/09

Public/private key pairs work on one basic principle. You generate a private key, and from that a public key. the public key can be used to encipher something that requires the private key to decipher. (barring supercomputers in buildings with 3 letter initials) That is incorrect. The public and private keys are generated in tandem. It is impossible (well, technically, it is infeasible, but in practice they're the same thing) to generate either key from the other. The two keys are completely symmetric. Which one you call "public" and which one you call "private" is entirely up to you. (In practice, the choice will be made by the software that generates the pair for you.) Anything that is encrypted by one of them can only be decrypted by the other. More precisely, encrypting anything by either key, and then encrypting the result with the other key gives you back the original. We sometimes refer to the second encryption as "decryption", but with public keys they're really the same thing. This public key isn't really used as a public key for you. it has both an encipher/wrap AND derive, so it contains both a private and a public key. This makes no sense. The public key is just that: a public key. The public key can be used both for encryption and decryption. (There's no difference in the algorithm. "Decryption" is just encryption with one key of something that was already encrypted with the other key from the same pair.) You can sign something by encrypting it (or more generally a checksum of it) with your private key; the recipient verifies the signature by decrypting (i.e. reencrypting) with your public key, which you've broadcast to the whole world. Conversely, someone can encipher something for your eyes only by encrypting it with your public key. That encryption can only be reversed by decrypting (i.e., reencrypting) with the private key, which ONLY YOU know. Notice that both of these operations are performed by having someone else encrypting with your public key, and you encrypting with your private key. The only difference between signing and enciphering is which of these is done first. (Either way, publickey encryption is dogslow. For efficiency, signing is generally done by computing a message digest (a "checksum") and encrypting/decrypting only that. Enciphering is generally done by generating a random ad hoc symmetric key, encrypting the message with that, and attaching the symmetric key itself encrypted with the public key. You decrypt the symmetric key with your private key, and then decrypt the message itself with that. The idea is that keys and digests are short enough that you don't mind having to run them through publickey encryption; whereas computing a message digest or applying a symmetric key is relatively fast.) This also means of course that if you "lose control" over your certificate, you have lost control over your private key portion of it, and therefore anyone with that key could sign an email that appears to come from your email address. There is no private key in a certificate. You will typically keep your private key in your keychain. The corresponding public key will be saved as a separate entry in your keychain, possibly but not always as part of a certificate. You cannot "lose control" of your certificate. Quite the contrary. You shout it from the rooftops to anyone who will listen. What can happen is that someone can forge a certificate that claims that they're you. The big weakness of the whole certificate system is that forgery is so easy. (Corporations do it routinely in their firewalls; governments can direct CAs in their jurisdiction to forge certificates for them. Validating a certificate only involves verifying that it's signed by some CA, not necessarily the right one. For this purpose, the definition of a "CA" is "any selfsigned root certificate that you trust".) But even a forged certificate does not have your private key in it, because it doesn't have any private key in it. It's impossible to ignore the fact that the CA generated the private portion of your key. You would have had to roll up a key pair locally on your machine, and then sent THAT to the CA to sign and return back to you. But you didn't. You downloaded a complete cert, with the private key they generated for you, in addition to the public key which they have signed for you. (which you could not do without their help, using their private key) The CA did not generate your private key. You, in fact, did generate the key pair (both keys) on your machine, and did send the key you (or your software) decided would be the public key to the CA. The private key was saved on your machine and never left it. It's entirely possible to generate the key pair in your browser, using Javascript. This can be done without intruding on your consciousness, so you may not be aware that it was done, but it was. The Javascript would have saved the private key somewhere on your machine (probably the keychain), and sent only the public key (and whatever other data you've entered on the page) to the CA. Or better, combined the certificate the CA sent back with the private key it was holding onto to produce the .p7k file on the fly, on your machine. That would put the private key in a file that you ostensibly downloaded from the CA, without the CA ever having had the private key. So they had your private key. They had to have it to do their job. If your CA ever sees your private key, they aren't doing their job right. Get another one that understands security. The rule with no exceptions is: your private key is born in your possession, and NEVER leaves it. (Well, it is sometimes useful to encrypt your private key with your public key, and send that to someone for safekeeping. I know that sounds pointless, but it turns out to be highly useful in conjunction with PBKDFs (Password Based Key Derivation Functions), where you want to be able to change your password without losing access to data protected by the old one. Because the private key is encrypted such that only you can read it, you haven't really given it to anyone.) Correct me if I'm wrong on any of this. My pleasure.

Top



#26753  09/17/13 08:19 PM
Re: secure email?
[Re: ganbustein]

Registered: 08/04/09
Loc: Iowa

Correct me if I'm wrong on any of this. My pleasure. I just had the intense disgust of entering a fairly large post, and while I was checking my facts in another safari window, safari spontaneously reloaded my abouttoclickpost window (which was BEHIND the frontmost window I was using), causing it to wipe my entire text. Nothing quite so annoying as watching a different window of your browser decide to go rogue. I don''t know how much of that I want to try to type up again but I'll give it a shot. Normally I copy a post in progress frequently in case of a browser crash etc, but I was copying a formula at the time... *big sigh* First thing I want to address is asymmetry. The public and private keys are NOT interchangeable. Here are two links you need to watch. The first one is better for the casual reader and gives an easier to follow example, but uses the same exponent for encrypt and decrypt which is downright confusing, and fails to describe the computation of D. The second one is a lot drier, but is complete. http://www.youtube.com/watch?v=M7kEpw1tn50http://www.youtube.com/watch?v=Jt5EDBOcZ44(oh and btw, in safari as of this instant, every single tab I have open reloads its page when I switch to that tab.... good grief... heck of a safari bug there) Sorry but you will have to have that second one fresh on your mind for the following. I summarize his example: P = 53 (prime 1, selected at random) Q = 59 (prime 2, selected at random) N = P*Q = 3127 (public key 'large component') phi(E) = (P1)(Q1) = 3016 (this is merely used as a safety limit, E must be chosen LESS than this) E = 3 (integer less than N, selected at random, not a factor of N (meaning not P or Q), less than phi(E) Public key is (N,E) this, combined with an address, would also be considered a public certificate, useful for encrypting and verifying signatures only D = (2 phi(E) + 1 / E = 2011 (this is the secret part of your private key) private key is (D,E) but is often referred to simply as D. E is however required for decrypting and signing (N,E,D) is a private certificate, capable of encrypting, decrypting, signing, and verifying signatures, among other things) (N,E) can be extracted at any time from (N,E,D), thus a public cert can be extracted from a private one. When a CA sends you your private (N,E,D) key, they sign it, but only the (N,E) part, since you won't be revealing your D to anyone else. note! D and N are not interchangeable because D may be prime. (and in this example, I think NOT by coincidence, 2011 is prime) If N is prime, it has no factors P and Q with which to generate the complementary D. This key pair is not symmetrical. M = 89 (plaintext example message) C = M^E mod N = 89^3 mod 3127 = 1394 (the encrypted message) M = C^D mod N = 1394^2011 mod 3127 = 89 (the decrypted message, my calculator can't do that one) That last one is the doozy that keeps the message safe. C may not be too big, but D is pretty good size, making C^D downright massive, even by modern computer standards, when D is 2048 bit for example. And yes, due to the intense math in this process, it's only used to securely exchange a randomly generated symmetrical key (that is much faster to use) that is used to encipher the actual message. (I wanted to see if the example D and N could be swapped and still continue to function, but I don't have any way to deal with numbers of that size) Now that we have that cleared up, on to the "who has the private key" question. When you request a cert from comodo etc, you just give them your email address, and not much else. THEY generate a P and a Q, calculate the N, calculate the phi(E), generate an E restricted to phi(E), and calculate the D. The N, D, and E are then wrapped up in a cert. They add in your email address and name etc, and sign all of it (except the D) fire off an email to you with a link for you to click, and then when you click that, it downloads the (N,D,E) private cert to your computer. This is the ONLY thing on your computer with regard to this keypair. There is only the one cert, that is a full (N,E,D). (there's probably a name for that, I don't know what it is) When you email someone, or want to publish it, you are stripping out the D because you can't let anyone else see that. anyone with that cert can look like you can decrypt messages encrypted with the (N,E) public cert made from it, and can sign something that your (N,E) will verify as authentic. There is nothing else on your computer that matters. Only what they send you in the form of that certificate. They go to the lengths of forcing you to use a link they emailed you to make sure nobody else gets ahold of it. If it wasn't the part that you were supposed to keep secure, they wouldn't need to do that. And since you can click that link a week from now and get it again, they're obviously keeping ahold of it. Also of note, it's probably difficult for you to figure out the (P,Q) they selected for you, given only your cert. They have no actual reason to tell you what your P or Q are. The other certificates on your computer, the anchors from places like verisign, are only (N,E) certs, and are good for encrypting and verifying only. When you send an email and sign it, your (N,E) is attached in addition to the signature, and the receiver can verify the cert because that part of it was signed by verisign, for which they have the public (N,E) cert as one of their anchors or within their chain of trust. You can roll up your own key using openssl. I found several places online that show how. But it won't be signed by any authority, and will probably not be imported to your keychain automatically. At least not as trusted. I don't think comodo etc will let you send your public key to them to sign. That being the case, if you want the cert in your email to be trusted and used automatically, you have to let them roll it up for you, and that means they have your D. And the government that controls them can have it at any time too, without your knowledge. OR if they have a security breach, anyone might end up with it. If they were inclined to do it the "safe" way for you, here's how the process would have to work: you run something on your own computer to generate P,Q. From there you also calculate N, phi(e), E, and D. You then send them your email address, as well as (N,E). You do NOT send them D, and certainly not P or Q. They sign that and send it back via email or whatnot. You assemble a (N,E,D) cert and tack on their signature, which will validate your email with N and E. Done. They don't have your D, and you have a signed cert that your email program can use to sign and extract/insert your (N,E) cert into. But that's not how any of them do it. I could be tinfoilhatty about it, but this is just people doing their jobs, and should be expected. And this is why I originally was asking how to roll my own cert. I can live without it autoimporting as trusted into others' keychains. I'd just like to know I'm really the only one in the world that can read my mail, when I so choose to. If the above is actually occurring on my computer when I request a cert, then ok it's safe. Considering some of the oddness that goes on when getting one of these certs, it wouldn't terribly surprise me if clicking the request cert form caused my computer to do the above local work and merely send them my email, N, and E, and then stash my D somewhere in a cookie or something. And then somehow be able to access it again when I click the email link, to assemble the single cert that has N, E, D, my email, and their sign all in it. But I'd have to have that explained to me to believe it's all happening that way. I've rolled up many an SSH keypair and it always takes openssl awhile to do it, and I've never seen that delay in my browser when I click to request the cert. I do recall at least one of them telling me I had to do the retrieval on the same computer, using the same browser, so that raises my hopes a tad bit. "Pictures, or it didn't happen." I have explained the process in greater detail rather than try to address your individual concerns one at a time. If you feel any of them have survived the above, speaketh bonus addition after I reread it... I think the reason they said that E must not be a factor of N is that I suspect for ease of P,Q generation, they select them from a (large) table of known primes, and then multiply them by another pair of randomly selected primes in their table, or perhaps a large fairly prime number. To make a P and Q that aren't "very" prime, but are close to it, to increase the size of N without having to try to find a large P and Q to work with. Then, E would need to be checked to make sure it's not a factor of N, (not P and not Q) because it may be a factor without being P or Q. interesting... LAST edit. wolframalpha to the rescue! first make sure it can hack the normal N and D: 89^3 mod 3127 = 1394 1394^2011 mod 3127 = 89 booya, it works. swapping N and D: 89^3 mod 2011 = 1119 1119^3127 mod 2011 = 146 bzzzzt, doesn't work! process is not symmetrical.
_________________________
I work for the Department of Redundancy Department

Top



#26759  09/18/13 08:22 AM
Re: secure email?
[Re: ganbustein]

Registered: 08/04/09
Loc: Iowa

After a bit more digging I found better information on this process: http://wiki.cacert.org/EmailCertificates(this may apply more to email and web servers, ssl certs, rather than strictly private email certs, but the process should be fundamentally the same) The key to keeping your private key safe is to extract a "Certificate Signing Request" (CSR) and send that to the CA. It's your full cert with the D removed, ready to be signed. They verify your identity (however they do it) then sign it and return it to you to have your D merged back in. So the D never leaves your computer, they never see it. (and most certainly aren't the ones generating it) The core question remains, in the above process with comodo etc, is the php or whatnot running on your machine really generating (Q,P), rolling up the other stuff to make a CSR, sending that, and then stashing it somewhere locally to be reassembled when you click the link they email you? (Or is it generating those things for you and just sending you back a full (N,E,D) certificate with your secrets already in it?) It might be. But I still would expect a substantially longer delay in the process, as generating a suitable (Q,P) is usually a lengthy process on a home computer, taking at least several seconds here. Generating a DES public key pair for ssh takes between 3 and 15 seconds when I roll one up, depending on the machine, and those are fewer bits iirc.
_________________________
I work for the Department of Redundancy Department

Top



#26760  09/18/13 09:00 AM
Re: secure email?
[Re: Virtual1]

Moderator
Registered: 08/04/09

I just had the intense disgust of entering a fairly large post, and [...] safari spontaneously reloaded my abouttoclickpost window [...], causing it to wipe my entire text. I'm sorry to hear that. It isn't necessarily the browser but (updated) web pages that initiate a reload. Because of the seemingly increasing frequency of this happening, I cannot recommend strongly enough NOT to compose or edit posts in text entry boxes on web pages. Instead, use a text/word processor on your computer and Copy/Paste the finished post. This issue has come up before, and I'm sure anyone who has suffered a text loss like you will appreciate the utility of this advice.
_________________________
alternaut • moderator

Top



#26763  09/18/13 10:37 AM
Re: secure email?
[Re: alternaut]

Registered: 08/04/09
Loc: Iowa

I'm sorry to hear that. It isn't necessarily the browser but (updated) web pages that initiate a reload. Because of the seemingly increasing frequency of this happening, . Did you catch my latter comment? Every tab of another window triggered an automatic reload when I clicked on them, and they were unrelated. Basically every open render in safari got a reload.
_________________________
I work for the Department of Redundancy Department

Top



#26767  09/18/13 02:05 PM
Re: secure email?
[Re: alternaut]

Registered: 08/04/09
Loc: Iowa

Yes, I read that comment. Let's say that particular issue was underlying your text loss incident, and let's assume it will be fixed. Would you still risk working in a web page's text entry box with lots of text and no backup? oh, no I usually copy it to the clipboard periodically while entering something, due to having lost text on a few prior occasions. It's just this specific time, I happened to be using the clipboard and got stung
_________________________
I work for the Department of Redundancy Department

Top



#26768  09/18/13 02:17 PM
Re: secure email?
[Re: Virtual1]

Registered: 08/04/09

oh, no I usually copy it to the clipboard periodically while entering something, due to having lost text on a few prior occasions. It's just this specific time, I happened to be using the clipboard and got stung I use Butler's "Recent Pasteboards" (multipeclipboard) functionality for just that reason. A single clipboard is inadequate; I wonder why Apple's never addressed the issue.
_________________________
The new Great Equalizer is the SEND button.
In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top



#26772  09/19/13 05:55 AM
Re: secure email?
[Re: artie505]

Moderator
Registered: 08/04/09
Loc: Fort Worth, Texas

A single clipboard is inadequate; I wonder why Apple's never addressed the issue. Most likely because not enough people have expressed a desire for the feature. Have you submitted your Feedback on the subject?
_________________________
joemikeb • moderator

Top



#26783  09/19/13 02:29 PM
Re: secure email?
[Re: Virtual1]

Registered: 08/04/09

First thing I want to address is asymmetry. The public and private keys are NOT interchangeable. Here are two links you need to watch. They absolutely are. I was a Math major before I got seduced by the dark side (Computer Science). I do understand the math. As you say, RSA key generation starts by finding two large primes, p and q, and computing N=pq. The strength of RSA encryption relies on the infeasibility of factoring N to recover p and q. Then numbers E and D are found such that E*D is congruent to 1 modulo phi(N). (If N = pq as stated, then phi(N) = (p1)(q1).) If E is any number that is relatively prime to phi(N), then such a D can be easily computed using a properly instrumented implementation of the Euclidean algorithm. More generally, if a and b are any integers, then the Euclidean algorithm can be used to find integers x and y such that ax + by = gcd(a,b), where gcd() is the greatest common divisor. In our special case, where E is relatively prime to phi(N), that means we can find x and y such that Ex + phi(N) y = gcd(E,phi(N)) = 1. Modulo phi(N), the phi(N)*y term drops out, and we can take D=x to see that ED = 1 (mod phi(N)). Note that gcd(E,phi(N)) is calculated along with D, so the check that E and phi(N) are relatively prime comes for free. The next mathematical property we need is that a^z = a (mod N) whenever N is squarefree and z = 1 (mod phi(N)). We've chosen N to be the product of distinct primes, so it's squarefree. And we've chosen E and D such that ED = 1 (mod phi(N)). That means a^(ED) = a (mod N) for every integer a. But a^(ED) = (a^E)^D = (a^D)^E. We can represent any plaintext message as a (very large) number p, and "encrypt" it by computing c = p^E mod N. Then we can decrypt it by computing p = c^D mod N. The symmetry comes about because E*D = D*E. It doesn't matter which power you raise your plaintext number to first. Raising the result to the other power gives you back the original. You can arbitrarily call (E,N) the public key, and (D,N) the private key. Or vice versa. Choosing E=3 is a convenience. The primes p and q will generally be chosen to be of the form 6n1, so that neither p1 nor q1 will be a multiple of 3. If either prime were of the form 6n+1, then you couldn't use E=3, but the method would still work with a more suitable choice for E. One of the two parties is going to have to compute p^E mod N. It is a convenience for that party to choose E as small as possible, which is why E=3 was an early recommendation. Modern thinking is that that's not the best choice. note! D and N are not interchangeable because D may be prime. (and in this example, I think NOT by coincidence, 2011 is prime) Nobody ever suggested D and N were interchangeable. The "public" key (E,N) and the "private" key (D,N) are interchangeable. That D=2011 happens to be prime in your example is a coincidence. If N is prime, it has no factors P and Q with which to generate the complementary D. This key pair is not symmetrical. As long as E is relatively prime to phi(N) you can find D such that ED = 1 (mod phi(N)), and if N is also squarefree the encryption/decryption will work. However, anyone who can deduce phi(N) from N can easily get from (E,N) to (D,N). That is, the private key is easily deduced from the public key if phi(N) can be computed. THAT's what's wrong with setting N to a prime. In that case, phi(N) = N1, which is rather easy to compute. M = 89 (plaintext example message)
C = M^E mod N = 89^3 mod 3127 = 1394 (the encrypted message)
M = C^D mod N = 1394^2011 mod 3127 = 89 (the decrypted message, my calculator can't do that one) Sure it can. In Terminal, type irb. ( /usr/bin/irb is "Interactive Ruby", my desk calculator of choice.) At the prompt, enter 1394**2011%3127 and press return. That last one is the doozy that keeps the message safe. C may not be too big, but D is pretty good size, making C^D downright massive, even by modern computer standards, when D is 2048 bit for example. All the arithmetic is done modulo N. You can keep reducing modulo N as you go along, so that intermediate calculations never exceed N^2 and the final result never exceeds N. The size of C (unreduced modulo N) is not what keeps the message safe, because that huge number is never calculated. What keeps the message safe is the infeasibility of factoring N and thereby computing phi(N). (It goes the other way too. If you know N and phi(N), it's easy to recover p and q, so factoring large numbers and computing phi of large numbers are problems of equal computational complexity.) When you request a cert from comodo etc, you just give them your email address, and not much else. THEY generate a P and a Q, calculate the N, calculate the phi(E), generate an E restricted to phi(E), and calculate the D. The N, D, and E are then wrapped up in a cert. They add in your email address and name etc, and sign all of it (except the D) fire off an email to you with a link for you to click, and then when you click that, it downloads the (N,D,E) private cert to your computer. (You said phi(E), but you meant phi(N).) If Comodo or any other CA is generating P and Q for you, they're doing it wrong. They should never see your private key, nor any information that they can derive your private key from. They should be sending you code which, when executed on your machine (possibly in your browser), will generate the keys on your machine and send them ONLY the public key. They combine the public key with your identifying information, and sign and send them back to you as a certificate. (This is what you refer to as a "public certificate", and what I'm calling simply a "certificate".) Software on your machine is free to append the private key to that to form what you call a "private certificate", but that will never leave your possession. If they were inclined to do it the "safe" way for you, here's how the process would have to work:
you run something on your own computer to generate P,Q. From there you also calculate N, phi(e), E, and D. You then send them your email address, as well as (N,E). You do NOT send them D, and certainly not P or Q. They sign that and send it back via email or whatnot. You assemble a (N,E,D) cert and tack on their signature, which will validate your email with N and E. Done. They don't have your D, and you have a signed cert that your email program can use to sign and extract/insert your (N,E) cert into. That's exactly the right way to do it. The whole thing can be done in your browser, using HTML5/AJAX. No need for an email exchange, which would introduce its own security concerns. But that's not how any of them do it. I could be tinfoilhatty about it, but this is just people doing their jobs, and should be expected. They'd better all do it that way. They're in the tinfoil business, and had better know how to use it. Otherwise, they ARE NOT doing their jobs. And this is why I originally was asking how to roll my own cert. I can live without it autoimporting as trusted into others' keychains. I'd just like to know I'm really the only one in the world that can read my mail, when I so choose to. You've already mentioned openssl. Or you could explore Keychain Access→Keychain Access→Certificate Assistant...→... . Create your own CA, which will be trusted on only the machines you install the certificate onto. Use it to sign as many intermediate certificates as you'd like. bonus addition after I reread it... I think the reason they said that E must not be a factor of N is that I suspect for ease of P,Q generation, they select them from a (large) table of known primes, and then multiply them by another pair of randomly selected primes in their table, or perhaps a large fairly prime number. To make a P and Q that aren't "very" prime, but are close to it, to increase the size of N without having to try to find a large P and Q to work with. Then, E would need to be checked to make sure it's not a factor of N, (not P and not Q) because it may be a factor without being P or Q. interesting... The math is interesting, but it doesn't work the way you're imagining it. The number of primes less than M, for large values of M, is about M*log(M). That means if you want to find a prime that is about equal to M, you pick random numbers around M and test each to see if it's prime. On average, you will have tested about log(M) numbers before finding a prime. To get a 2048bit number N, they want P and Q to be about 1024 bits each. Since log(2^1024) = 710 (approximately), they need to examine about that many possibilities for each. They don't necessarily choose P and Q randomly. As I mentioned, they want them to be of the form 6n1. The don't want them too close to each other. (So, for example, one of them might be 900 bits long and the other 1148 bits long.) They want N to be larger than 2^2048 but not by much, say between 2^2048 and 2^2048 + 2^2000. They want P1 and Q1 to have certain desirable properties that I won't go into here. Once they have a "nice" value P (or Q) that they hope is prime, they run a probabilistic test on it. The test uses P and a random number A. If P is prime, it will always pass the test no matter what A is. If P is not prime, it will fail for at least half of the possible values for A. If P passes the test for, say, 30 different values of A, then there's only a oneinabillion chance that it's not prime. That's close enough for gummint work, as they say, and they proceed as if they were sure it was prime. If P and/or Q isn't prime, they'll get the wrong value for phi(N), and encryption/decryption won't work, so even the rare false positive will probably be detected in short order. Picking P and Q from a "short list" of only a trillion or so known primes would be a disaster. The bad guys can run through a trillion guesses in a matter of seconds. (They only need to guess one of them. Q = N/P.) LAST edit. wolframalpha to the rescue! first make sure it can hack the normal N and D: 89^3 mod 3127 = 1394 1394^2011 mod 3127 = 89 booya, it works. swapping N and D: 89^3 mod 2011 = 1119 1119^3127 mod 2011 = 146 bzzzzt, doesn't work! process is not symmetrical. You did the calculation wrong. You should be computing 89^2011 mod 3127 = 545 and then 545^3 mod 3127 = 89. That is, you should be swapping E and D. N stays fixed.

Top



#26784  09/19/13 02:58 PM
Re: secure email?
[Re: ganbustein]

Registered: 08/04/09
Loc: Iowa

Ahh excellent, thank you for the corrections and education. I'm not a math major, I just play one on TV By "symmetrical" I was thinking "interchangeable". By A and B symmetrical you're meaning x = A((B(x)) = B(A(x)) I believe (I'll need to do a bit more reading on using ruby for a scientific calculator, that's terribly useful) I'd like to believe that they're doing this in php etc locally on my machine. The process you've explained looks plausible on a laptop in fast time... any idea then why it takes openssl so long to generate an ssh keypair? Also that would mean I can't have them resend my email certificate if I lose it? I don't recall them ever giving me that warning. I might try it here in a bit an see if it's doable. Obviously if it's possible, they've still got both the public signed and the private key? Looking at E and D as the things being reversed, I assume they are selecting an E that is going to make a similar magnitude D, regulated by N?
_________________________
I work for the Department of Redundancy Department

Top



#26790  09/19/13 11:47 PM
Re: secure email?
[Re: joemikeb]

Registered: 08/04/09

A single clipboard is inadequate; I wonder why Apple's never addressed the issue. Most likely because not enough people have expressed a desire for the feature. Have you submitted your Feedback on the subject? Ages ago.
_________________________
The new Great Equalizer is the SEND button.
In Memory Of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Top



#26798  09/21/13 12:39 PM
Re: secure email?
[Re: Virtual1]

Registered: 08/04/09

By "symmetrical" I was thinking "interchangeable". By A and B symmetrical you're meaning x = A((B(x)) = B(A(x)) I believe Yes, "interchangeable" is a better word. In cryptography, a "symmetric cipher" is one that uses the same key for both encryption and decryption (usually by running the algorithm backwards for decryption), and public key cryptography is decidedly not a symmetric cipher. By "symmetric", I did mean that A(B(x)) = B(A(x)). I'd like to believe that they're doing this in php etc locally on my machine. The process you've explained looks plausible on a laptop in fast time... any idea then why it takes openssl so long to generate an ssh keypair? Not php, which is usually run serverside. They're (probably) using cryptographic features that are new in HTML5. (Those features haven't been officially standardized yet, but that doesn't stop anyone from implementing them now.) Specifically, under HTML5, Javascript can set up a custom algorithm (for example, to generate RSA keys of a specified length) and then invoke its generateKey method. The key is generated asynchronously. That is, the Javascript can start the calculation running and then go off and do other things (like, waiting for you to press a "Submit" button). Eventually, the Javascript tells the algorithm either "OK, now I need the result. I'll wait for you to finish if you haven't yet" or "Never mind, I don't need it." It may still take several seconds to generate the key pair, but you won't notice because its done in the background, in anticipation of being needed. Looking at E and D as the things being reversed, I assume they are selecting an E that is going to make a similar magnitude D, regulated by N? I thought of that, but can't see an easy way to do that. This is closely related to the "discrete logarithm" problem. What they could do is generate several (E,D) pairs and pick the one they like best. (Once you've got phi(N), calculating an (E,D) pair is very fast, so they can afford to generate several.) But I can't see why they would want to. I also thought this might be useful, but on reconsideration couldn't find a justification. The motivation for always using E=3 was that that would be convenient for "the public". When ssl was new, the private keys were all being used on powerful servers and the public keys were being handed out to browsers often running on woefully underpowered client machines. That asymmetry no longer exists. Still, it might be "polite" to pick E small, and let D fall wherever it may. Trying to make them both small is too hard. Consider, if you're generating 2048bit keys, phi(N) will also be nearly 2^2048. Only one onemillionth of the possible values for E will have fewer than 2028 bits, and likewise for D. Only one in a trillion pairs will have both E and D shorter than 2028 bits. That's a lot of work for not much gain. For your example, with phi(N)=3016, the pair (E,D) that has the smallest sum is (95,127), both of which are larger than sqrt(N) and therefore each have more than half as many bits as N. That suggests that at best you're not going to be able to reduce the total time to encrypt/decrypt to less than half what you'd get with a random pair. The pair with the smallest product is (7,431), but you wouldn't want to use that, because it gives a hint at phi(N). (The smallest product comes from factoring phi(N)+1. In this case 7*431 = 3017 = phi(N)+1. Just knowing 7 tells the bad guy that phi(N) is one less than a multiple of 7, which is way more than you want them to know.)

Top




