28 November 2014
What Is Good Encryption Software?
A sends:
I have contacted you asking about certain security questions. After reading a few of the Snowden leaked documents, I have started to be more aware of my privacy being at risk. I have a few questions concerning certain programs and safety tips.
First, I've recently started to doubt about my encryption software. Is Symantec's "PGP Endpoint" a good hard drive encryption software?
In other words, is it trustworthy since it is an American company. And if not, what encryption software is the best for Mac.
Second, is "ProtonMail" as secure as they say it is? If not, what email provider doesen't let the NSA see into my account.
Third, is Jetico inc's "Bestcrypt Container Encryption" trustworthy? If not, what could be an alternative.
Fourth, are these encryption types good? Blowfish, Gost & AES - 256bit. And which encryption type remains the best above all?
Last, is Kaspersky a good anti-virus software? If not, which one is the best for Mac.
_____
Cryptome:
Important, difficult questions, likely to produce a range of answers.
We will publish them for answers.
_____
Answers to cryptome[at]earthlink.net
Cryptome Public Key Key ID: 0x8B3BF75C-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP Universal 2.9.1 (Build 347)
mQENBFG3XG8BCACbsuBHhg2txl4ubbd7bia6fND1j6rxt4oXC2NX0gJJ6MJ+Z3BY
nPLCRVX39UsKcXc3NChM4kOF8A650e6nuR3X3pU6UwgwnEUmEi9oSDkAZGDJyKRa
XakSU2jz5PPMdudXWK0GgE9mLWVSn5RchC3RRCDvlbWk4ZKa1N04g/5Hp/iDzmuc
HUeGPMArhnN+1KGIXT5Swh/VJT6zuhMbWncHM0PCTRn5r4lfqfAivP/A2IJNm70/
z6Z6o1rkDVWVN7TXPISi+pEnxbedMtB4aU0RG21v2/kv2Y/ELPTfSjoSkItG7/pK
0LORjgeGR0VIqe3fviWu7rsoFaaExPv3/UYHABEBAAG0IUNyeXB0b21lIDxjcnlw
dG9tZUBlYXJ0aGxpbmsubmV0PokBhwQQAQIAcQUCUbdclTAUgAAAAAAgAAdwcmVm
ZXJyZWQtZW1haWwtZW5jb2RpbmdAcGdwLmNvbXBncG1pbWUHCwkIBwMCCgIZARkY
bGRhcDovL2tleXNlcnZlci5wZ3AuY29tBRsDAAAAAxYCAQUeAQAAAAQVCAkKAAoJ
ELZQVyuLO/dcn20H/08Q+GjrCZI9PhK7CEzJRO3xZxTyI21XMgxTu35fsN/TFM09
ZpgG6IpJfbu+VpW8mBHWyN0lC97IsH4Ep/gV9dix04Rtlokf2QuSnQUfA4WOqsgN
CqVy/fNIYSRoGurqVjIGE+/1eOpahDL4SSeJney9grwqleKxFwWLwnLeAUQoH9xA
8GSrYLW7cL1RJGlfpf0JTKxn3goY8+hcKg1OpM0UjNmeFszJ6iLAUePXTA4P0fpA
JHUuSmZ/NTrxjzlmbbC/O+UVrf+jUxM3pVbehGqGWgxEZsdp0JFTaI02z/+Q1GJY
+gvRDys0dOcumI/PDRWwVkeePYMYC0OigfYwlDKJASIEEAECAAwFAlG3XdoFAwAS
dQAACgkQlxC4m8pXrXyDyQgAknEkbcNKNdhIXlHqF7RliZdtkUdsCByKJqao9Tf/
hhAhcOQVN5DcpxkqMnqiDg6hE4DslE2mA9iRUoqmzjpfk2oRKzk4vntBwTrjPxCM
kPfbW2kPZKj8X7QtXeuMyBKwGvro59s1i+XBQLZD3Qn75OUvwFDAEi459pc9heEB
6wXK293YhyaB92CyDTglPu3Dlv8Qkvgp4cKbdfFCRGwGbQGa8l7jST15NwAmtorr
ydP+IB8rOBku30V31/MFAMrlGhKayhs5vp24b4akQxnrfl4Zdyeoe6Nuq81lr4V6
UN4MZ992Af3Cv0L9bQNgyBKgWswWhSqxlc/gzfeFTPsJybkBDQRRt1xwAQgAywDY
TFabKR1p37QGO0+77Wp0SAtvEMJCpmwKOgxmNtLCoOc9VS+aTkLypE/zpQ8ZGJz4
2gR1vnGrOjwAJLhP/OuNwpqEKmXZ7SklrCEbIFnK0jXWklvc1nKd2XP4UXxGjaHQ
nn2xCzFmDck15a42EBvzdIWr2Xtx8C0cS7i1fXsmdzR8EMfndo/oFMa6lJqu3oil
RYZ/3IFdlnEQlzQxZ2AjoLPW0VbWlwDGqPggvKBPfIk+/cH+pcY3SJJg7RlQwHn5
DRepaCuS3n4kKK5IV5VlNJziYyVsEN2D5BQCtfqHdzkTitRXOgz40tyneX1bqIfI
CRAHhpYYLYIkeEWjPwARAQABiQJBBBgBAgErBQJRt1xxBRsMAAAAwF0gBBkBCAAG
BQJRt1xwAAoJEFaLTmSpng5LAZEH/3N4W4HWdN4NwR04oL/ysFLqHRnRYagA30St
78p/MyZJOMX0372zpoBWBSfXRq8XeSwUXoohugGPyyoIwtINn3/ctZqRziUo6wpF
c7tYIDNd+duA1jMdLjw/rMYcf2LgkFCCN1piAl1014cixpDMM2PXnNbKHDWP91qd
ApdLFnchP/Z4I8gdf4e1itizJ3ONcRT/9iqH3DXCw5CUNckm8ExcBidCC+I4Oh4g
9byDubxQMPzZK54HlK89sUkdvEgQ7QHELNaAP/Y/7IOxAl5AgmIvw/NM4euRL84j
USP8NAIqLbRMMp07kSTVArAMOvmTg7+/rpv9UQkfp1ykBJtr61EACgkQtlBXK4s7
91w4QAf9Gflur6PCr9msaa0mEAi0xcqcmzDkp/Ecms+NKiAjz7U6UT9IgdivFPfi
iyMUTHgOjw5daY/IKaecO0I69wDYRnmLvx9mLjDY+IiQQlw3L9CrN1JLkcUO250p
f3LR/DXFCPgDHdvaTgy0kgg2a4YjKXAirdYyDXGjYgEuM1OvgGLSnDfJ5xJ+Fugq
7IlLoZZQPz/G/k+7c9UDAJ5gaxR9Jyu4aadNsnBD7daO+Mr326fB9M7ded3/gqng
gn/oL6ZkF2QMDWMVcF+qq8CsbqaZMg/UO4obxPbDyCRKE+1ggG+t/tWTMvSoUfEZ
ySZ+3dIlBIbIaHXQCE4ES8wW0JgtaA==
=gjKZ
-----END PGP PUBLIC KEY BLOCK-----
I think the author has not properly defined the problem. The first step to securing any system or information is to construct a threat model: _what_ do you want to defend, against _whom_? _What resources_ and capabilities does your attacker have? Which _compromises_ (usually reducing usability) are you willing to make? These questions have different responses when the above parameters vary.
Additionally, in my opinion, even if such a threat model were properly defined, the author does not approach the problem correctly. Here are some truisms I use when evaluating the security (however defined) of any system:
1) Software (and hardware) which is not publically-auditable is not trustworthy. Note that this does _not_ mean that publically-auditable software is trustworthy; publically-auditable code is a necessary condition, but not a sufficient condition, for trustworthiness.
2) All software which processes untrusted input has exploitable vulnerabilities. This is not true in theory, but decades of surprising exploits prove this in practice. Some software has a higher defect density than others, but the proper approach is to reduce the size of the attack surface.
3) Encryption works only in very constrained threat models. Even assuming the cryptosystem is properly designed and the underlying crypto primitives are indeed "secure", a motivated attacker will easily sidestep these measures in most scenarios.
4) "Antivirus" software is dangerous: it gives a false sense of security. If an attacker can execute code on your system--either by physical access or remote code execution--your entire system is now untrustworthy.
In general, no person can independently audit all security-critical parts of any system. Thus, security relies on trust. You trust chip designers, design IP vendors, EDA tools vendors, the chip fabricator, the fab employees making masks, the supply chain of your system integrator, the system integrator itself, the OEMs who write microcode and firmware, the distribution chain from those OEMs to your actual device, the software vendor, the distribution chain from the software vendor to your actual device, the supply chain of that vendor (was their compiler compromised?), ... and the list goes on. In all, you must, whether wittingly or not, trust literally millions of people and companies, and a violation of that trust at any one point can destroy your entire system security.
With that said, let me elaborate on the above points and include some possible implications for the author.
1) Wherever possible, do not use proprietary services, software, or hardware. This means no Windows and no OS X, no Dropbox, no SkyDrive, no iCloud, etc.--at the very least. No email provider is secure. American companies may be particularly suspect, but this does not mean non-American companies are better. NSA compromised the Swiss crypto-device manufacturer Crypto AG--do you really feel safer using "Swiss secure" Proton Mail? If your mail must remain private, intentionally giving your email to a third party--_any_ third party--is just plain dumb. It's hard enough to defend as it is!
2) Critically analyze the attack surface of your relevant software; determine the size of the trusted computing base (TCB): what software and hardware do you rely on to properly deny or mitigate an attacker? Let's suppose you want to prevent a) hardware access (reflashing BIOS, hard drive firmware, etc.), b) access to the OS core (rootkits), c) access to sensitive data (Cryptolocker, bank info-stealing malware). Let's also suppose you use Microsft Windows and Internet Explorer.
For an attacker to exploit your browser, you rely on millions of lines of code in Internet Explorer for image handling, JavaScript sandboxing, etc. Assuming sensitive data is not already accessible to the attacker, you then rely on thousands to millions of lines of kernel discretionary access control code to prevent access to that data. For an attacker to control the OS core, you rely on millions more lines of kernel code, and maybe millions more lines of user-mode code (e.g. LSASS). For an attacker to control the hardware or firmware, you rely on millions more lines of kernel/driver and firmware code, and the hardware itself.
In other words, your TCB is astronomically large: you must trust so much code, that even if you assume the defect density is incredibly small, you can expect many vulnerabilities.
A better approach is to start from first principles, like Qubes OS or Citrix. Isolate those parts of the system which must be isolated from each other, and rely on as little software, firmware, and hardware as possible to enforce the isolation.
3) Focusing on which crypto primitives are used is likely a waste of time, especially for a non-cryptographer: there are so many potential pitfalls in cryptosystem implementation, that a sophisticated attacker would never bother attacking the crypto primitives themselves, but rather the implementation. And don't forget the cryptosystem necessarily includes _you_, the user--and you're usually the weakest link.
Think about this in traditional military terms: you have some territory to defend against an attacker. If you build an impenetrable 30km-high and 10-km deep wall of Uranium around 30 degrees of your perimeter, no attacker is going to waste time destroying the wall; they'll just go around it.
Specifically for full disk encryption, forget about which primitives are used. Don't worry about whether 20km is tall enough: make sure there aren't giant gaps in the wall. The best way to do this is to use the most-audited code you can. In practice, this means using LUKS.
4) Don't rely on detection. In all cases but the most trivial botnet malware, you need prevention. Once cryptolocker encrypts all your files, it's already too late. Once NSA exploits your browser with QUANTUMINSERT, it's already too late. You must architect your system to provide the maximum defensive capabilities--before it's too late.
Finally, if you really _need_ security, don't use a computer. At the very least, never connect your computer to a network, never process untrusted data or connect untrusted devices, and _physically remove_ as many components as possible to reduce your attack surface.
I would add unseen.is to the picture. How secure is it?
Don't use unseen
Tweet: Tell the users it's not about encryption. It's about implementation. The flaws are usually there.
Cryptomeorg: Perhaps. Crypto producers-advocates use that excuse for failure to deliver on marketing promises. Pretty good fails.
Tweet: Oh come on you can't blame mathematics for the failure of Windows to prevent buffer flaws.
This question has already been answered in some detail at the Cryptome library:
Greenwald Blames the Hostage, November 20, 2014:
"Encryption is a citizen fraud, bastard progeny of national security, which offers malware insecurity requiring endless ‘improvements’ to correct the innately incorrigible. Its advocates presume it will empower users rather than subject them to ever more vulnerability to shady digital coders complicit with dark coders of law in exploiting fear, uncertainty and doubt."
FBI Breaks Crypto, October 31, 2014:
"Protections of promises of encryption, proxy use, Tor-like anonymity and ‘military-grade’ comsec technology are magic acts — ELINT, SIGINT and COMINT always prevail over comsec. The most widely trusted and promoted systems are the most likely to be penetrated, exploited, spied upon, successfully attacked, covertly compromised with faults hidden by promoters, operators, competitors, compromisers and attackers all of whom warn against the others while mutually benefiting from continuous alarms about security and privacy."
Apple Wiretap Disbelief, September 20, 2014:
"Because this first release of their encryption software has no security bugs, so you will never need to upgrade it to retain your privacy?"
Natsec the Mother of Secfuckers, June 9, 2013:
"Security is deception. Comsec a trap. Natsec the mother of secfuckers."
In fact, the NSA itself has tipped its hat on this matter essentially echoing Cryptome:
"The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments "
"Current security efforts suffer from the flawed assumption that adequate security can be provided in applications with the existing security mechanisms of mainstream operating systems"
Are there any "good" anti-virus software? I still keep thinking the best AV is the one you don't install or use at all, since endpoint security is mostly reliant on "secure" user behavior anyway...
...somehow I find the idea of sharing hashes and checksums of all my files with AV industry (or MSFT even due to msrt.exe running all the time) a little disturbing ;)
No comments:
Post a Comment