The ciphered message *is* the private key -- how is that possible?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The ciphered message *is* the private key -- how is that possible?
Lavabit uses Elliptical Curve Cryptography, and http://lavabit.com/secure.html says that the ciphered message is the private key. In a few words, can someone explain that?
I'm accustomed to RSA public key crypto, where the private key is a prime number that's used to decrypt the ciphered message.
Last edited by unSpawn; 06-12-2011 at 01:16 PM.
Reason: //Replace bad slash unnecessary short URI
It's a straight-forward combination of asymmetric and symmetric encryption (you're just reading it out of context):
Quote:
AES is a synchronous encryption scheme that uses a secret passphrase to encrypt/decrypt a ciphered message. In the case of Lavabit’s secure e-mail system, the ciphered message is a user’s private key and the secret passphrase is a hashed version of the user’s password.
As you can see above, the sentence was making reference to the previous sentence (the quick summary of what AES is). So by "message" they are referring to the plaintext (the private key of the asymmetric setup in this case), which has nothing to do with the email message. You're encrypting an asymmetric private key using symmetric encryption, so that the private key is protected if it falls into the wrong hands.
How does asymmetric encryption protect your privacy? The short description is that for users of this feature, incoming e-mail messages are encrypted before they’re saved onto our servers. Once a message has been encrypted, only someone who has the account password can decrypt the message. Like all safety measures, encryption is only effective if it’s used. To ensure privacy, Lavabit has developed a complex system that makes the entire encryption and decryption process transparent to the end user.
This process works by combining three different encryption schemes with Elliptical Curve Cryptography (ECC) as the cornerstone. When a user activates the asymmetric encryption feature, two ECC keys are generated with 521 bits of strength. The first key, or the "public" key, is stored in plain text on the server. This public key is used to encrypt incoming messages. Because of how ECC works, only someone with the second “private” key can decipher messages encrypted with the public key. To protect the private key from attackers, it is encrypted using the Advanced Encryption Standard (AES) (hover:AES Hover) with a 256 bit key. AES is a synchronous encryption scheme that uses a secret passphrase to encrypt/decrypt a ciphered message. In the case of Lavabit’s secure e-mail system, the ciphered message is a user’s private key and the secret passphrase is a hashed version of the user’s password.
To ensure maximum security, passwords are hashed using the Secure Hash Algorithm (SHA). SHA takes the plaintext password as its input and produces a random 512 bit string as the output. With only the SHA output, it is cryptographically impossible to determine the original input. Effectively, hashing is a repeatable one-way process.
@gnuweenie:
I agree, that seems badly confused.
@win32sux:
I understand that Lavabit appears to trying to contrast their scheme with the design of PGP and GPG.
GPG uses public-key cryptography to encrypt a session key for each message. The sender and recipient each have a secret/public keypair; the sender "randomly chooses" a session key and CAST-encrypts the message plaintext with it, and also uses his private key and the recipient's public key to EG-encrypt the session key. He transmits the EG-encrypted session key and the CAST-encrypted message to the recipient, who decrypts the EG-encrypted session key using his private key and the recipient's public key, and then decrypts the CAST-encrypted message using the session key. (Someone please correct me if I am wrong!)
(EG stands for the El Gamal algorithm, while CAST stands for the default block cipher used by GPG.)
But I don't understand your explanation of what Lavabit does.
I guess that an ECC scheme might be used somewhat analogously to the way that the El Gamal algorithm is used by GPG. ECC would use "trapdoor pseudo-one-way" operator based upon the properties of elliptic curves, while El Gamal uses a "trapdoor pseudo-one-way" operator based upon the properties of discrete logarithms. (Someone please correct me if I am wrong!)
However their ECC encryption scheme works, how can they encrypt an incoming email "before it is saved" on their mailserver? Wouldn't it have to exist as a plaintext temp file before they encrypt it? Or is it possible to use a stream cipher to encrypt it as it is being received?
Last edited by win32sux; 06-12-2011 at 10:13 PM.
Reason: Removed OT content.
Peufelon, I've removed the NSL-focused part of your post, as it would lead to off-topic non-technical discussion. If you wish to discuss NSLs, please start your own thread in General. As for my post, I was only addressing the specific issue at hand (the confusion created by Lavabit's sentence construction). I'm not familiarized with Lavabit's processes, so I can't comment on them. Surely someone else can, however. I just ask that a decent effort be made to keep the discussion from straying too far off topic.
If you meant I should do this, then please move this thread to General from Linux/General. Am I catching on? If not, please explain.
Yes, your post in General looks great to me. Thanks for complying with my request. Regarding the other thread you linked, however: I'm not a mod at that forum so there's nothing I can do. The proper procedure in such cases is for you to use the Report button on the relevant post, and then submit a request so that the forum-specific mods may consider it. If you have any further questions/comments regarding moderation issues, please contact me directly via email as this is not the proper venue.
I appreciate the explanations. That answers my question.
I have to say it's a bit disturbing that unSpawn modified my link. I posted a link that highlighted and navigated to the specific phrase I was referring to, and he replaced it with a link that has no highlights, and just goes to the top of the page.
I have to say it's a bit disturbing that unSpawn modified my link. I posted a link that highlighted and navigated to the specific phrase I was referring to, and he replaced it with a link that has no highlights, and just goes to the top of the page.
I didn't see the original thread, so I can't say for certain, but did you 'reply' to an older thread perchance? This is considered necroposting Even when the posts are on topic, it is discouraged here. Knowing unSpawn, I am sure that if the content were modified without a moderation explanation that it was unintentional.
I didn't see the original thread, so I can't say for certain, but did you 'reply' to an older thread perchance? This is considered necroposting Even when the posts are on topic, it is discouraged here. Knowing unSpawn, I am sure that if the content were modified without a moderation explanation that it was unintentional.
I'm talking about this thread, the first post. The reason was "//Replace bad slash unnecessary short URI". The change trashed my highlights.
However their ECC encryption scheme works, how can they encrypt an incoming email "before it is saved" on their mailserver? Wouldn't it have to exist as a plaintext temp file before they encrypt it? Or is it possible to use a stream cipher to encrypt it as it is being received?
I really don't know what Lavabit does behind the scenes, but my guess is their SMTP server has a built-in mechanism to encrypt the mail DATA before it's ever written to disk. It's certainly possible that they are temporarily writing the inbound mail to disk, reading it, encrypting it, writing that to disk, and then shredding the original - but that seems inefficient.
We’ve chosen to offer this feature only to our paid users. We made this decision for two reasons. The first is a belief that with paying customers, there is a money trail. If the account is used for illegal purposes that money trail can be used to track down the account owner. The second reason is that the broader encryption process requires a significant amount of computing power. We can only justify the added expense for premium accounts.
How 'bout that. I have been using Lavabit for some time, and didn't realize this. I should have RTFFP (fine print).
Thanks for fixing that. Short URIs are one of my pet peeves. In fact I'd go further and demand (as a "consumer") that bb software should roboeliminate them, and should even replace "active" (clickable) links to external sites with "inactive" URLs. (Paste and click if you really want to go there.)
@anomie:
I thought someone might say that!
Lavabit's technical description still doesn't scan at my end: does anyone know what they were trying to say?
Thanks for fixing that. Short URIs are one of my pet peeves. In fact I'd go further and demand (as a "consumer") that bb software should roboeliminate them, and should even replace "active" (clickable) links to external sites with "inactive" URLs. (Paste and click if you really want to go there.)
Replacing them makes sense when it's simply a redirection service like tinyurl. When it actually destroys content and sabotages someones message, it's pure incompetence. Your suggestion only makes sense if the bb software can find the highlights, and reproduce them.
When a overpowering pro-censorship-happy admin blocks legitimate content, it actually damages the forum. Unspawn trashed highlights, taking context away from my words. How dare you encourage him for doing so.
Sorry to take things slightly OT, but I'm grateful this thread started -- it forced me to really read carefully about Lavabit's services. As a free account holder, all I was getting was encryption on the wire. Major assumption (and major goof) about on-disk encryption on my part.
As of yesterday, I've moved to using Thunderbird + Enigmail (openpgp) over IMAPS / SMTPS with my regular gmail account. Might as well let the encryption and key management responsibility fall to myself.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.