1. A sends:
2.  
3. 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.
4.  
5. First, I've recently started to doubt about my encryption software. Is Symantec's "PGP Endpoint" a good hard drive encryption software?
6.  
7. In other words, is it trustworthy since it is an American company. And if not, what encryption software is the best for Mac.
8.  
9. Second, is "ProtonMail" as secure as they say it is? If not, what email provider doesen't let the NSA see into my account.
10.  
11. Third, is Jetico inc's "Bestcrypt Container Encryption" trustworthy? If not, what could be an alternative.
12.  
13. Fourth, are these encryption types good? Blowfish, Gost & AES - 256bit. And which encryption type remains the best above all?
14.  
15. Last, is Kaspersky a good anti-virus software? If not, which one is the best for Mac.
16.  
17. _____
18.  
19. Cryptome:
20.  
21. Important, difficult questions, likely to produce a range of answers.
22.  
23. We will publish them for answers.
24.  
25. _____
26.  
27. Answers to cryptome[at]earthlink.net
28.  
29. Cryptome Public Key Key ID: 0x8B3BF75C
30.  
31. -----BEGIN PGP PUBLIC KEY BLOCK-----
32. Version: PGP Universal 2.9.1 (Build 347)
33.  
34. mQENBFG3XG8BCACbsuBHhg2txl4ubbd7bia6fND1j6rxt4oXC2NX0gJJ6MJ+Z3BY
35. nPLCRVX39UsKcXc3NChM4kOF8A650e6nuR3X3pU6UwgwnEUmEi9oSDkAZGDJyKRa
36. XakSU2jz5PPMdudXWK0GgE9mLWVSn5RchC3RRCDvlbWk4ZKa1N04g/5Hp/iDzmuc
37. HUeGPMArhnN+1KGIXT5Swh/VJT6zuhMbWncHM0PCTRn5r4lfqfAivP/A2IJNm70/
38. z6Z6o1rkDVWVN7TXPISi+pEnxbedMtB4aU0RG21v2/kv2Y/ELPTfSjoSkItG7/pK
39. 0LORjgeGR0VIqe3fviWu7rsoFaaExPv3/UYHABEBAAG0IUNyeXB0b21lIDxjcnlw
40. dG9tZUBlYXJ0aGxpbmsubmV0PokBhwQQAQIAcQUCUbdclTAUgAAAAAAgAAdwcmVm
41. ZXJyZWQtZW1haWwtZW5jb2RpbmdAcGdwLmNvbXBncG1pbWUHCwkIBwMCCgIZARkY
42. bGRhcDovL2tleXNlcnZlci5wZ3AuY29tBRsDAAAAAxYCAQUeAQAAAAQVCAkKAAoJ
43. ELZQVyuLO/dcn20H/08Q+GjrCZI9PhK7CEzJRO3xZxTyI21XMgxTu35fsN/TFM09
44. ZpgG6IpJfbu+VpW8mBHWyN0lC97IsH4Ep/gV9dix04Rtlokf2QuSnQUfA4WOqsgN
45. CqVy/fNIYSRoGurqVjIGE+/1eOpahDL4SSeJney9grwqleKxFwWLwnLeAUQoH9xA
46. 8GSrYLW7cL1RJGlfpf0JTKxn3goY8+hcKg1OpM0UjNmeFszJ6iLAUePXTA4P0fpA
47. JHUuSmZ/NTrxjzlmbbC/O+UVrf+jUxM3pVbehGqGWgxEZsdp0JFTaI02z/+Q1GJY
48. +gvRDys0dOcumI/PDRWwVkeePYMYC0OigfYwlDKJASIEEAECAAwFAlG3XdoFAwAS
49. dQAACgkQlxC4m8pXrXyDyQgAknEkbcNKNdhIXlHqF7RliZdtkUdsCByKJqao9Tf/
50. hhAhcOQVN5DcpxkqMnqiDg6hE4DslE2mA9iRUoqmzjpfk2oRKzk4vntBwTrjPxCM
51. kPfbW2kPZKj8X7QtXeuMyBKwGvro59s1i+XBQLZD3Qn75OUvwFDAEi459pc9heEB
52. 6wXK293YhyaB92CyDTglPu3Dlv8Qkvgp4cKbdfFCRGwGbQGa8l7jST15NwAmtorr
53. ydP+IB8rOBku30V31/MFAMrlGhKayhs5vp24b4akQxnrfl4Zdyeoe6Nuq81lr4V6
54. UN4MZ992Af3Cv0L9bQNgyBKgWswWhSqxlc/gzfeFTPsJybkBDQRRt1xwAQgAywDY
55. TFabKR1p37QGO0+77Wp0SAtvEMJCpmwKOgxmNtLCoOc9VS+aTkLypE/zpQ8ZGJz4
56. 2gR1vnGrOjwAJLhP/OuNwpqEKmXZ7SklrCEbIFnK0jXWklvc1nKd2XP4UXxGjaHQ
57. nn2xCzFmDck15a42EBvzdIWr2Xtx8C0cS7i1fXsmdzR8EMfndo/oFMa6lJqu3oil
58. RYZ/3IFdlnEQlzQxZ2AjoLPW0VbWlwDGqPggvKBPfIk+/cH+pcY3SJJg7RlQwHn5
59. DRepaCuS3n4kKK5IV5VlNJziYyVsEN2D5BQCtfqHdzkTitRXOgz40tyneX1bqIfI
60. CRAHhpYYLYIkeEWjPwARAQABiQJBBBgBAgErBQJRt1xxBRsMAAAAwF0gBBkBCAAG
61. BQJRt1xwAAoJEFaLTmSpng5LAZEH/3N4W4HWdN4NwR04oL/ysFLqHRnRYagA30St
62. 78p/MyZJOMX0372zpoBWBSfXRq8XeSwUXoohugGPyyoIwtINn3/ctZqRziUo6wpF
63. c7tYIDNd+duA1jMdLjw/rMYcf2LgkFCCN1piAl1014cixpDMM2PXnNbKHDWP91qd
64. ApdLFnchP/Z4I8gdf4e1itizJ3ONcRT/9iqH3DXCw5CUNckm8ExcBidCC+I4Oh4g
65. 9byDubxQMPzZK54HlK89sUkdvEgQ7QHELNaAP/Y/7IOxAl5AgmIvw/NM4euRL84j
66. USP8NAIqLbRMMp07kSTVArAMOvmTg7+/rpv9UQkfp1ykBJtr61EACgkQtlBXK4s7
67. 91w4QAf9Gflur6PCr9msaa0mEAi0xcqcmzDkp/Ecms+NKiAjz7U6UT9IgdivFPfi
68. iyMUTHgOjw5daY/IKaecO0I69wDYRnmLvx9mLjDY+IiQQlw3L9CrN1JLkcUO250p
69. f3LR/DXFCPgDHdvaTgy0kgg2a4YjKXAirdYyDXGjYgEuM1OvgGLSnDfJ5xJ+Fugq
70. 7IlLoZZQPz/G/k+7c9UDAJ5gaxR9Jyu4aadNsnBD7daO+Mr326fB9M7ded3/gqng
71. gn/oL6ZkF2QMDWMVcF+qq8CsbqaZMg/UO4obxPbDyCRKE+1ggG+t/tWTMvSoUfEZ
72. ySZ+3dIlBIbIaHXQCE4ES8wW0JgtaA==
73. =gjKZ
74. -----END PGP PUBLIC KEY BLOCK-----
75. Response 1:
76.  
77. 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.
78.  
79. 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:
80.  
81.     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.
82.  
83.     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.
84.  
85.     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.
86.  
87.     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.
88.  
89. 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.
90.  
91. With that said, let me elaborate on the above points and include some possible implications for the author.
92.  
93.     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!
94.  
95.     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.
96.  
97.     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.
98.  
99.     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.
100.  
101.     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.
102.  
103.     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.
104.  
105.     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.
106.  
107. 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.
108.  
109.     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.
110.  
111. 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.
112.  
113. Response 2:
114.  
115. I would add unseen.is to the picture. How secure is it?
116.  
117. Response 3:
118.  
119. Don't use unseen
120.  
121. http://cryto.net/~joepie91/blog/2014/04/19/why-you-should-stay-away-from-unseen.is/
122.  
123. Why you should stay away from Unseen.is
124. 19 Apr 2014
125.  
126. It took a bit longer than I expected before I had the time to make this post, but here it finally is.
127.  
128. Not too long ago, I ran across some Anonymous-related Twitter accounts promoting Unseen.is. Unseen is, in their own words, a "private and secure messaging, calling and e-mail application" - which seems great, but really isn't. As it turns out, there are plenty of reasons why you shouldn't ever use them.
129.  
130. They seem to use home-grown cryptography.
131.  
132. The mortal sin of cryptography. You should never, ever, ever roll your own cryptography - or rather, if you do, you shouldn't actually use it in production, or publish it at all. Cryptography is hard to do right, and you will almost certainly fuck up, exposing all your users in the process.
133.  
134. The unseen.is FAQ (mirror) page says the following:
135.  
136. Messages on our service are sent using 4096-bit encryption, which is considered extremely strong. you generate your keys with extremely strong lattice based encryption. To that, we add an advanced symmetrical encryption which is very easy to use with keys 16x longer than those found in AES256, an industry standard. According to our engineers, this will take 23840 times longer to crack than aes256, which is commonly known as "military grade" encryption.
137. Aside from the clear snake-oil marketing there - the amount of bits is absolutely meaningless without context - there is absolutely no mention of what algorithm they use. None whatsoever. According to a thread on StackExchange, they do actually use an existing algorithm, but misrepresent the implications of it in their FAQ. In reality, we have no idea whether they rolled their own or not, because...
138.  
139. It's closed source.
140.  
141. Aside from the ethical side of open-source versus closed-source software, there is a very simple practical reason for open-sourcing any code related to security or cryptography: it allows anybody to audit it. Open-source in cryptography is an absolute necessity. This is not a new idea - it has been around since at least the late 19th century as Kerckhoffs's principle, and was a leading principle behind, for example, the legendary Enigma encryption machines. Even if you're not willing to let people reuse and redistribute your code, your code should at the very least be publicly visible and auditable.
142.  
143. Unseen's code is not. It's completely proprietary, opaque, and unavailable for review. Realistically, you have no idea what the code does, how the cryptography is implemented, or whether it's doing what it advertises at all. You have to trust that it really is as secure as they claim. And if you're going to trust an unfamiliar single party anyway, then why are you looking for a 'private and secure' communications platform in the first place?
144.  
145. You get less security on a free account.
146.  
147. From the FAQ:
148.  
149. The free version provides a modest amount of free encrypted storage and allows sharing of files of up to 50MB. The premium version provides 2GB of encrypted storage, file sharing up to 40GB, group audio/video calling, and premium users can generate and store their own private key.
150. Perhaps it'd be more appropriate to say "no security". This text implies that, on a free account, Unseen would generate and store your private key. This would mean, quite simply, that they could impersonate you and/or decrypt anything at will. At this point, you're effectively just relying on trusting them not to do so - there's absolutely nothing left of the original client-side-cryptography model. Again, why were you looking for a 'private and secure' service to begin with?
151.  
152. They rely on security through obscurity
153.  
154. From the FAQ:
155.  
156. The chat feature is only from Unseen user to Unseen user.. For chat we use a very specific encryption that no other services use, so they would never be able to read the messages you sent them. As a result the chat is a closed system. This makes the chat system significantly more secure.
157. Either they are really bad at wording things, or they claim that their chat being a "closed system" makes it "significantly more secure". This is pretty much a textbook example of "security through obscurity", and is the second mortal sin in cryptography. It is completely fallacious reasoning, and the biggest red flag you could possibly find for a supposedly 'secure' communications provider. There's really not much more to be said about this, other than emphasizing yet again how incredibly bad this is.
158.  
159. They evade critical questions
160.  
161. From the FAQ:
162.  
163. Isn’t a web service less secure?
164. Our services are developed to provide the highest level of security widely available on the web. We expect to continue improving and developing better solutions to protect your information. Applications specific to a particular operating system do offer more security, but the web is extremely convenient because you can get your messages anywhere, even if you are borrowing someone elses computer.
165. Rather than giving a straight-to-the-point answer, they bury an almost tacit admission in a pile of snake-oil marketing. They're clearly more interested in telling you how 'secure' they are, than they are in honestly informing you of how inherently broken browser cryptography is. Their choice to prioritize marketing over honest information, should give you a hint as to whether you should trust them with your data or security.
166.  
167. They are not sufficiently technically competent.
168.  
169. A quick search on Google turned up this very interesting article (mirror), which states the following:
170.  
171. The first thing you’ll notice on line 10 (London) and line 17 (the last router in Iceland) are the large percentage of lost packets. This degrades the performance getting to the server in Iceland. Line 17 is the last router you touch at our data center in Iceland, it’s just a few feet away from our servers and you can see the other hops are all behaving normally. According to our ISP, the only customer that was having problems with their switch was Unseen.is. That shows targeting of packets based on a web site.
172. Notice the high percentage of dropped packets at the same time in London, over 40%.
173. Once our ISP made a fix to the router in Iceland, the next morning, notice what happened to the router in London:
174. (click for image)
175. Now, 88% of the packets were being dropped in London!! Try to get through that!!
176. Kind of interesting that as soon as one of the routers got repaired that the other one acted up even more?!? This is definitely a good way to block traffic to a site, just degrade the performance until people can’t get through, but don’t make it a 100% blockage. It would be a good bet that they also have tools to see exactly who and how many people are getting bounced from a web page or site.
177. [...]
178. First, we’re encouraged about the state of our encryption. It must be pretty good because it takes a lot of work for a security agency to do a truck roll in Finland to hack into our new product manager’s computer and then to control these routers to degrade the traffic to our web site. They wouldn’t waste their time on easily broken “military grade” encryption.
179. A few things become painfully obvious from this excerpt.
180.  
181. The person who wrote this - who is part of Unseen.is, according to the article metadata - lacks basic and essential knowledge of networking, and how ICMP is treated by routers. This phenomenon is very easily explained by understanding ICMP de-prioritization (or your term of choice), and almost certainly has nothing to do with censorship of any kind.
182. They use their - incorrect - conclusion about these traceroutes, as a reason to pat themselves on the back for "having such awesome encryption". This is exactly the wrong attitude to take - if one really does roll their own cryptography, they should be constantly alert and distrusting of their own implementation, and never assume that it is infallible - especially not on such shaky grounds as these.
183. They employ conspiracy thinking. At the vaguest hint of a phenomenon that could possibly be explained as a conspiracy against them, they grab the chance to pinpoint that as the reason - critical thinking completely absent. And that brings us to the next point...
184. They are over-the-top conspiracy theorists.
185.  
186. It's not just their short-circuited reasoning that "there is packet loss, so there must be governments trying to block us" - the actual roots of Unseen are in the conspiracy theorist scene. Some digging brought up this thread (mirror), which clearly outlines a connection between Unseen.is and BeforeItsNews.com, a connection that is even confirmed in this post (mirror) on the Unseen.is blog.
187.  
188. 3 Are we linked to Before It’s News? The companies are completely separate and independent, but we share many of the same shareholders. Before It’s News uses the same mailing box to save money. In fact, we got the idea for Unseen from running Before It’s News.
189. To provide a little context, BeforeItsNews is apparently so bad, that even AboveTopSecret doesn't want their content (mirror).
190.  
191. To run a company providing 'private and secure' communications services, you need to be level-headed. You need to be able to rationally analyze situations, and rationally mitigate threats. This is completely in contrast with conspiracy thinking, where the default modus operandi is to jump to conclusions and "take sides", regardless of any information at your disposal.
192.  
193. They claim to be located in Iceland.
194.  
195. Regardless of whether they actually are (and the traceroute screenshots certainly raise some questions about that), why would this matter? If they offered truly private and secure services - which means no single point of failure, fully client-side cryptography, no ability for Unseen.is to compromise anybody's security - it simply wouldn't matter where they are located, or what the local privacy-related legislation is like. That they feel the need to use "Iceland" as a marketing point, implies that they are unlikely to be as secure as they claim.
196.  
197. Perhaps there are some problems I missed, but I feel that these points in themselves are more than enough to never use Unseen.is.
198.  
199. If you value your security and privacy, I suggest you take the same approach.
200.  
201. Response 4:
202.  
203. Tweet: Tell the users it's not about encryption. It's about implementation. The flaws are usually there.
204.  
205. Cryptomeorg: Perhaps. Crypto producers-advocates use that excuse for failure to deliver on marketing promises. Pretty good fails.
206.  
207. Tweet: Oh come on you can't blame mathematics for the failure of Windows to prevent buffer flaws.
208.  
209. Response 5:
210.  
211. This question has already been answered in some detail at the Cryptome library:
212.  
213. Greenwald Blames the Hostage, November 20, 2014:
214.  
215. "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."
216.  
217. FBI Breaks Crypto, October 31, 2014:
218.  
219. "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."
220.  
221. Apple Wiretap Disbelief, September 20, 2014:
222.  
223. "Because this first release of their encryption software has no security bugs, so you will never need to upgrade it to retain your privacy?"
224.  
225. Natsec the Mother of Secfuckers, June 9, 2013:
226.  
227. "Security is deception. Comsec a trap. Natsec the mother of secfuckers."
228.  
229. In fact, the NSA itself has tipped its hat on this matter essentially echoing Cryptome:
230.  
231. "The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments "
232.  
233. "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"
234.  
235. Response 6:
236.  
237. 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...
238.  
239. ...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 ;)