On 16/09/2013 15:27, susecmail wrote:[color=blue]
Interesting conversation & I thought I’d add my two-cents to the topic:
I use Claws-email with the GPG plugins enabled. I avoid using ANY
“free” email providor, especially if their company makes $10.74 billion
in selling OUR information to whomever it wants; I had used Lavabit.com
until the owners closed it due to NSA pressure. Sadly, it is now
necessary to find an offshore (for those living in the U.S., that is)
company that supports privacy & encrypted communication. After
evaluating several, I ended up on Countermail.com.[/color]
I tend to use enigmail - not because there is anything wrong with claws
(I even have it, it came with one of the pgp4win installs) but because I
find the feature-rich plugin community fills a lot of my other needs
(plus of course gpg users are the exception)
I also have a copy of https://www.quicksilvermail.net/ but of course I
don’t use that for anything, honest 
[color=blue]
Sadly, I do not encrypt hardly any of my email as most people I know do
not use encryption. I have used One-Time-Encryption keys for emails as
well as GPG/PGP for those users who employ that security.[/color]
That is a problem for me too. I can count on, ok, more than one hand,
but less than two, the number of people I know who have a secure key,
and of that, less than half would routinely encrypt their mails to me
(even in reply to a secure mail) unless I set up their enigmail for them
for secure-reply as a default
[color=blue]
Another sad, pathetic development for the Internet:
http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security
The lessons I would take away from the conversation above and my post:
- Do NOT rely on any encryption technology to store extremely sensitive
data; do not store that data on any computer at any time, somebody
somewhere will be able to get it;[/color]
Some data really cries out for computer storage. One takeaway from the
snowden affair was that a physical airgap and encrypted exchange
(physical) media was acceptable to Snowden; I believe truecrypt was used
for the latter, but don’t have a reliable source on that.
[color=blue]
- Do NOT use “free” services without checking them out, first:
2a. I remember being a young lad when I was told that nothing in
this life is free; everything comes with a cost; what’s the cost for a
free email provider? Loss of privacy? Ads?[/color]
If you aren’t paying, you are the product. Who are you being sold to.
Sadly, if you are paying, maybe they are getting paid twice.
[color=blue]
2b. Do you trust the Linux developers up & downline of your distro?
How many of us check the kernel anymore? I know I have not; has the NSA
worked with Torvalds or any other major developers?[/color]
I would be surprised if they had, but you have to recall that the NSA’s
own patches to the kernel are mainstream, so worth checking. That said
though, it would appear the NSA are more interested in compromising
binary installs of browsers and servers, mostly on the windows platform,
and can substitute downloaded installers “on the fly” for targets of
interest. And who is to say everyone isn’t a target of interest?
[color=blue]
2c. For SUSE, from what repositories are you installing? Has Novell
opted to put in a backdoor? Who develops that driver you just
installed? etc.[/color]
At some point, the paranoia has to get too much. It is worthwhile noting
that, even in the very earliest days of the unix project, a way was
found to booby trap compilers so that they would always compile in a
backdoor in certain executables (such as openssh) not present in the
source. They would also always compile in the above code if the
compiler is recompiled, and also the code to compromise the compiler (so
compiling the compiler multiple times would not remove it)
Usually, a compiler is compiled using a hand-coded and very inefficient
compiler. The resulting binary doesn’t work fast, but does produce
efficient code (much better than the hand-coded compiler). The efficient
compiler is then recompiled with its inefficiently compiled self, to
produce an efficient compiler that runs efficiently. If that first
bootstrapping compiler, hand-coded in assembler for which no source code
is usually supplied, had the backdoor, no copy of the binaries for the
efficient compiler would ever exist without the backdoor, despite that
backdoor never, ever appearing in the source of the compiler.
obviously, what keeps me awake nights is a bit more complex than what
you worry at
[color=blue]
- If you do store data on your system, encrypt your hard drive with
whole-disk-encryption; or, lacking that, encrypt your swap file & home
directory.[/color]
Actually, the opposite.
If you store data, then ideally you want a read-only operating system
such as a boot cd, that has no networking support. You can then boot to
that os, mount the encrypted partition, decrypt (from the unencrypted
windows drive) encrypted inbound data, work on it within your secured
environment, then store encrypted outbound data on the windows partition
and reboot back into your untrusted os.
Now all you have to worry about is that the tpm/uefi bootstrap has some
code in it to compromise stored in memory keys after your secure
partition is mounted.
[color=blue]
- Choose a good email program that supports encryption and privacy;
many of them do; however, some are less effective than others.[/color]
A good choice of key is crucial, but from statements made so far I am
reluctant to believe that the MS cryptographic core remains untainted,
and it is possible the openssl core is compromised too. Not sure WHAT
that leaves, given 95% of the crypto code out there is rooted in one or
the other of those.
[color=blue]
It may all be a moot point, given that the NSA has a quantum computer
available to them, even if it is “just” using their tech subsidiary,
Google, Inc. 
And, the CIA program, Facebook, makes it easy to keep
track of most people on the planet: Although this is tongue-in-cheek,
PRISM proved it to be probably true:
https://www.youtube.com/watch?v=cqggW08BWO0[/color]
Quantum Cryptanalysis is overrated. Just as in theory you can break
symmetric keys by running “enough” processors in parallel, a QC has to
have sufficient qbits, in sufficient parallel probability fluxes, to
hold all possible states simultaneously - as I understand it, each of
those possible states must be powered, so at some point you are forcing
enough power into the solution that it will fuse atoms below iron. That
practical limit is thought to lie far below what we can already achieve
by brute force (although, it would be cool to have a RSA key broken
near-instantaneously rather than over months by a server farm the size
of a small town)
The new DWave approach, should it prove viable, may give a significant
improvement to the limit - DWave qbits are, as I understand it, much
less stable than classical QC qbits, so may (or may not) yield a correct
answer. However, it may be the case that sufficient runs of the QC,
tested using a conventional computer, might still find results for
larger keys in the EC/DSA space in a realistic timespan (days or weeks)
where conventional computing is likely to take centuries. Scientists are
alternatively enthusiastic and skeptical about DWave’s claims though. So
it would be wise to remain on the fence. I have not seen any suggestion
that the factorization hard problem underlying RSA is likely to be
suitable for the DWave though, so as long as that is true, I am going to
use Schneier’s own actions (of issuing a new gpg 4K key using trusted
code) as a guide for mine
And, the CIA program, Facebook, makes it easy to keep track of most people on the planet: Although this is tongue-in-cheek, PRISM proved it to be probably true: https://www.youtube.com/watch?v=cqggW08BWO0