You cannot trust anything / encryption / privacy ... least of all M$ and NSA ... perhaps not even TOR
Hi, Well worth the read. - back doors, possible Intel CPU compromises - encryption with NSA /help/ which renders encryption to possibly be worthless. - many encryption programs deliberately using less strong ciphers (and defaults lower than recommended) Essentially, anything from US may be a problem and if the US is doing this, then why not China, and other countries? It may be hardware and/or software, it may be by government will or other bodies, bottom line is that nothing is safe. Even TOR is not as safe as has been made out, the original creators of TOR whom worked with DARPA originally now say so..... [as per Steve Gibson SN 0420, no other reference found yet] N.S.A. Foils Much Internet Encryption By NICOLE PERLROTH, JEFF LARSON and SCOTT SHANE Published: September 5, 2013 664 Comments https://www.accessnow.org/page/m/3717cfad/13a757b0/7348f2b8/1de05321/2009894... The above link redirects to: http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html... Cheers AndrewM
Andrew McGlashan wrote:
Even TOR is not as safe as has been made out, the original creators of TOR whom worked with DARPA originally now say so..... [as per Steve Gibson SN 0420, no other reference found yet]
I can't comment on that, but obs. this recent attack on Tor users that didn't keep their patches up to date: Ars technica is one of many sites with coverage of the Firefox exploit that was used to attack the anonymity of Tor users. "The attack code exploited a memory-management vulnerability, forcing Firefox to send a unique identifier to a third-party server using a public IP address that can be linked back to the person's ISP. The exploit contained several hallmarks of professional malware development, including 'heap spraying' techniques to bypass Windows security protections and the loading of executable code that prompted compromised machines to send the identifying information to a server located in Virginia, according to an analysis by researcher Vlad Tsrklevich." http://lwn.net/Articles/562219 Re your Subject field, this property has been well understood since [Thompson 1984], at least: https://en.wikipedia.org/wiki/Reflections_on_Trusting_Trust#cite_note-5
On 6/09/2013 7:39 PM, Trent W. Buck wrote:
Yes, part of the problem, as posed by that article, was clearly the use of Firefox and the vulnerability in javascript. The TBB (TOR Browser Bundle) fixed this issue, but because javascript is, unfortunately, a heavy requirement for many bloatware websites, turning it completely off can effectively render many sites completely unusable. So, TBB turns on js by default these days :( But I think the problem is greater than just this exploit, it sure helps if people patch, but some, if not a huge number of, exploits are in the wild long before they are patched, if even they are found in the first place. Patching helps, not using Windows helps, lots of things help, but don't be too sure that even TOR with the best environment setup isn't going to give you everything you are told to expect by using TOR ... although even the TOR project doesn't give you any guarantees themselves, simply because they can't. But they do try to keep users informed [1].
Re your Subject field, this property has been well understood since [Thompson 1984], at least: https://en.wikipedia.org/wiki/Reflections_on_Trusting_Trust#cite_note-5
Yes, absolutely true, thanks for the reference. [1] https://research.torproject.org/ - which has this link (amongst others) http://freehaven.net/anonbib/ Cheers A.
On Fri, 6 Sep 2013, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
On 6/09/2013 7:39 PM, Trent W. Buck wrote:
Yes, part of the problem, as posed by that article, was clearly the use of Firefox and the vulnerability in javascript. The TBB (TOR Browser Bundle) fixed this issue, but because javascript is, unfortunately, a heavy requirement for many bloatware websites, turning it completely off can effectively render many sites completely unusable. So, TBB turns on js by default these days :(
Surely a good solution to this class of problem would be to use iptables to prevent the UID which runs the web browser (which need not be the same as the UID for the X session) from doing any IP access other than talking to the TOR server. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Hi ZZZZZ, On 7/09/2013 3:47 AM, ZZZZZZZ wrote:> Yeah but gpg is still safe!! Yes, but this article [1], points to the "Intel Secure Key" technology [2] (in newer Intel CPUs). The first intro line of the Intel link says: "Intel Secure Key, was previously code-named Bull Mountain Technology." The earlier NYT article mentions "Bullrun" as a program, that neatly fits with "Bull Mountain" .... So, if we have a new enough [3rd gen or later] Intel CPU, then chances are that the random number generator will bring in issues that will interfere with the security of GPG when generating keys, due to NSA "requirements". The plot thickens somewhat, doesn't it? Perhaps we need to stick with older Intel CPUs to protect against possible issues with the random number generator functions. On a side note, my own current GPG key isn't long enough, I may follow the details from this article [3] to increase the key size to 8192 bits. Besides the current 4096 bit limit may be the result of NSA input.... to help them have a better chance of cracking GPG data. Cheers AndrewM [1] http://blog.cryptographyengineering.com/2013/09/on-nsa.html [2] http://software.intel.com/en-us/blogs/2012/05/14/what-is-intelr-secure-key-t... [3] http://gagravarr.livejournal.com/137173.html?nojs=1 (Creating a 8192 bit GPG key to replace my 1024 bit one)
On 7 September 2013 04:30, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
So, if we have a new enough [3rd gen or later] Intel CPU, then chances are that the random number generator will bring in issues that will interfere with the security of GPG when generating keys, due to NSA "requirements".
On 7 September 2013 07:41, Rick Moen <rick@linuxmafia.com> wrote:
Fortunately, there's no special reason to rely primarily on built-in microcode routines for things like RNGs.
I'm glad Ted Ts'o also understands the need to avoid opaque instruction sets that can't be independently audited, and has resisted pressure from Intel engineers to allow /dev/random to rely solely on the RDRAND instruction. ~J
Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
It may be hardware and/or software, it may be by government will or other bodies, bottom line is that nothing is safe.
I've been advising for years to be wary of making crypto rely on arcane hardware features. Fortunately, there's no special reason to rely primarily on built-in microcode routines for things like RNGs. And, as to 'commercial encryption', if I'm for some reason obliged to use corporate VPN software and such, I either layer on top of that userspace crypto I have more control over or say/do nothing I wouldn't want on the front page of a newspaper.
participants (5)
-
Andrew McGlashan -
Joel W Shea -
Rick Moen -
Russell Coker -
Trent W. Buck