First, I am new to Thunderbird usage. I might be missing something with the Thunderbird PGP setup. The tutorial states that you send via TBird e-mail your public key to anyone that you wish to receive your encrypted e-mail. OK .............. But that means that e-mail with your public key is sitting on your e-mail provider's server. So the provider can read your unencrypted e-mail that contains the public key and at will unencrypt all your encrypted email. Ditto for any intermediate server along the route. Again, I might be missing something here. But the rule of thumb is to never send a public key via e-mail .............
Hello itman: ...there in lies your misunderstanding. In the classic example of Alice encrypts a message to Bob using Bob's public key combined with Alice's private key + Alice's passphrase, Alice might/could include her public key as a convenience to Bob. Bob then decrypts Alice's ciphertext using Bob's private key + Bob's passphrase to render plaintext. Alice nor Bob needs to include their public key if they are registered with the usual global public key-servers. If Alice's message to Bob was properly encrypted, the ISP, eavesdropper, or any MitM attack, will be unsuccessful because the attacker does not have Bob's private key nor Bob's passphrase. These concepts are always a bit difficult to fathom at first. Just remember you never ever expose/send your private key nor reveal your passphrase to anyone. HTH
That is slightly miswritten. It should say ".... anyone that you wish to receive encrypted e-mail from." The public key is used to encrypt the e-mail. Encrypted e-mail can only be decrypted by the private key, which should never leave your system. Sending someone your public key poses little risk beyond showing others that you use encryption.
Once you send a few dozen pgp/gpg emails you will do so effortlessly. The security is about as good as it gets.
Aside from the metadata/subject exposure (inherent in the email protocols) which I trust the OP is aware of.
There's also no forward secrecy. Once an adversary obtains a copy of the private key, all past and future messages encrypted to it can be decrypted.
I'd replace "once" with "if" in that statement. That also assumes that the same public/private key is used for all the traffic. THat problem can be eliminated by changing keys with each message. An easy way to do that would be to send the next public key to be used as inline text in the message. It's not perfect forward secrecy but it would be nearly as good in regards to the contents. If each key is destroyed after use, there's no way any adversary can decrypt more than one message with any key. Exceptions to this would be: 1, The PC/device itself is compromised. 2, They've broken the cipher that's used. 3, The encryption software is flawed.
@noone_particular That's a very cool idea And it could be scripted. So now I'm wondering if there's already an app that uses that approach.
That was a given, but thanks for highlighting it just in case the awareness wasn't there. I am accustomed to using 100% https email activity so the metadata gets buried in the connection protocol. Not the same but an example: I communicate with several folks via PMs using PGP but the site connections are https. The normal "tip off" headers are not seen by snoops because the https connection renders the metadata encrypted, and therefore unseen even while going through an elevated backbone "visitor's" gear. The subject lines need to be generic for sure, or my style would be; subject %^^&*&*(&( Know what I mean? The subject is also encrypted for the internet snoops, but it would be readable by an Admin at a site while perusing their PM system. Mirimir and Noone particular, Guarding the private key is obvious. Depending upon the severity/need for privacy you may consider an "Air Gap" approach on high need communications. If not a full blown Air Gap, at least an "air gap" via private VM, which would go a long way toward isolating the private key from "getting in the wild"!! I administrated a key ring for quite some time. The suggestion to "script" new keysets would be very inconvenient for users. e.g. lets say I wanted to read an email that was sent 20 transmissions ago. Am I really going to generate a new keyset (even if automatically scripted to do so) and then retain that keyset in order to read my material if desired? If I don't retain the keyset than the email is gone too because I can't read it later if a reference to it is needed. You MUST always retain the full keyset used or don't bother archiving anything because its gone!!
@Palancar Right, old messages would be unreadable once the private key had been deleted. However, the old private keys could be backed up somewhere, encrypted and hidden.
True; but I may be too lazy for that compared to "air gap" of my private key to be somewhat sure its mine ONLY. As a reminder I could send someone my full keyset and I would still be OK because my password is enormous by most user's standards. Here is the kicker for folks like you and I: PGP communication means at least two folks involved and many times a half dozen or more. The weak link is not usually MY key or yours. A compromise of any private key on the communication leaves the whole thing open. I cannot count the times I was informed that one of my users lost their private key (or their whole keyset). If that is happening you know their internet security cannot be where it should be.
Right, never assume that email will remain private. On a related note, I'm looking into https://pond.imperialviolet.org/ .
Thanks, I use a usb3 bootable password/certificate management system protected by LUKS and a strong password for all this key management type stuff. Not too difficult, except it's way too difficult for most people, and needs care every step of the way. Until this changes, one can't rely on your communicating partners to have the same level of security. I was looking at Mailpile, which seems to be doing some nice things as a pgp email client, including having an encrypted email search function (which they, rightly, say is part of the expectation of a store-and-forward system). But they also say that they are not going down the FS line, precisely because it makes historical access difficult/impossible). So that leaves the semi-ephemeral asynchronous messaging option with pfs - thanks for the link to Pond, things to like including padding and timing messing-up. It's my opinion that the only prospect for strong security and privacy is through this type of asynchronous messaging, preferably mediated by semi-structured data (based on XML say), which could be consumed by programmatic agents. I do not see any way in which direct user interaction with current communications mechanisms (whether through browser or email), can result in strong privacy and security. The foolishness of mass surveillance is that it makes the market for such things a flourishing one. By breaking the deal on only-individual-warranted surveillance, they will make that legitimate/constitutional monitoring far harder in the medium/long term.
Right. I recall that GCHQ raised that issue about two years ago as the government was preparing to block IP "piracy". They worried that driving "pirates" to use MSE and VPNs would make their job harder. Still, from what I've read, I gather that the NSA and Five Eyes have always aimed for full mass surveillance. Back in the day, that meant seeing all international mail and telegrams. But then, only governments and large businesses used encryption, and the NSA etc controlled the knowledge and the production of machines for doing it. So the NSA etc could ensure that only they had truly strong encryption, and that they could break the encryption that everyone else used. But that changed with the growth of academic cryptography, and totally blew up after PGP came out.
@mirimir - yes, their desire is to examine all of it, but in that sense, more of it in the past, especially if it were (expensively) encrypted - was going to be of interest, between "known" parties. And it would take effort/money to decrypt and store. That's also what limited the steaming open of envelopes, it would cost too much to do indiscriminately. The ultimate difference now is the economic one of lower and lower processing power and storage costs, coupled with the pathetic weakness of the end-systems and protocols in the current environment. There's always been an arms race in this stuff, but like I say, this current one is extremely foolish because they have taken short-term advantage without legitimacy, which will result in a worse situation medium term. Ineffective and counter-productive, because if "normal" people are forced to use strong crypto routinely, then they (actually we) will have more trouble.
The most annoying aspect of this encryption "arms race" is that those who create encryption software, ciphers, algorithms, etc keep fighting this battle on their (NSA, FBI, government, etc) terms. At the risk of quoting an overused and near meaningless phrase, a little "out of the box" thinking would change the entire balance of power. Consider this. With PGP and most other "strong" encryption software, when one the wrong password/passphrase, the content fails to decrypt. If one employs 2 layers of such encryption, it's easy to tell when the first layer is broken because it decrypts into the 2nd layer. This IMO is a weakness. If the outer layer of encryption were designed so that a wrong password/passphrase resulted in incorrect decryption instead of no decryption at all, there would be realistic way to know if the resulting content was another layer of encryption or total gibberish. The verification that the outer layer of encryption was broken is gone. What I'd like to see is a 2 layer system in which the inner layer is conventional strong encryption and the outer layer is a combination of character shifting and padding. The closest comparison I can think of would be to encrypt a message, file, etc with conventional encryption, then feed the results into an Enigma machine.
Is this thought similar to hidden containers in Truecrypt? That is to say, you would get Lorem Ipsum results from at least some incorrect passphrases? That would require some additional calculations and redundancy in the data of course. The other option, which I have seen people moot, is to put encrypted random data out there as chaff, so there is no message, and this would maximise the costs. My feeling is that we are in a period of asymmetric warfare, but the good news - if you can call having your own government as a threat good (they seem to regard us as the threat) - is that the use of even reasonably well executed encryption requires much more effort to decrypt than encrypt. Of course, they will make such use as difficult as possible because the balance between offence and defence is so badly out of kilter. I do not want to do any of this stuff, it should not be necessary in a democratic society that allows warranted surveillance with suspicion. But regardless of what I do, their actions, and the pathetic response of the politicians, has more or less guaranteed the gradual adoption of hard-to-crack routine encryption and services, which will make the individual surveillance much harder.
I have no idea how Truecrypt works with that. Never used it. What I'm thinking of is similar to a substitution cipher that also adds padding. Refer to this ASCII table. For an extremely over-simplified example: add 1 to the first character add 3 to the 2nd character add padding character repeat Assuming the original strong encryption yields: xKPpG8CjEHq7 Apply the shift/padding cipher and it becomes: yN3QskH;kDmpFKfr: The adversary sees yN3QskH;kDmpFKfr: If they apply the wrong shift/pad they might get mGPNNdKcLYaPLsB or moDJ2iqKS8XlPrg instead of xKPpG8CjEHq7 Depending on the complexity of the shift/padding cipher, there could be thousands of possible answers. The exact shift/padding would be a function of the password. How would an adversary know which is correct? What are their options? Try different combinations of shifts and padding until they get a result that looks like a cipher they know? Definitely. I've made that suggestion a few times. Encrypting cat videos, the feed from a webcam that's pointed at the fish tank. I'd like to see a voluntary "bot" people could choose to run that automated the process. The whole thing is disgusting that we should have to consider such ideas. There's no way that I'll believe that all this surveillance is to protect us from terrorism. It's all about monitoring and controlling the common man for the benefit of the super rich. They've redefined terrorism to mean anything that empowers us and reduces their control, power, or profit. You can see that motive behind most everything that's going on, from global to local.
I installed GnuPG and the Enigmail add-on and all appears fine except for one issue. I set the default to always sign e-mail and never to encrypt. I keep getting asked for my paraphrase each time I send an e-mail. Mozilla's documentation states I should only have to enter the paraphrase when I encrypt. Anyone know a work around for not always being asked for my paraphrase when signing an e-mail?
I'm not sure there is one or that it would be a good idea if there was. Without needing to supply the passphrase, someone else could send and sign e-mails in your name if they got access to your PC.
Yes, I agree now. I posted same question on the Enigmail support forum. Appears the Thunderbird tutorial needs some editing. Paraphase is always asked for signed e-mails for reasons you stated. For encrypted ones, it can be turned off.
