The overall question is whether bindings or language features that expose direct control of the underlying architecture (such as D) can still be used to implement crypto. The answer is likely yes, though it is uncharted territory that only someone who knows what they are doing should attempt.
STARTTLS was never intended to thwart MITM however. We need to keep that in mind. It allows a way to start a secure channel that is backwards compatible under the assumption that an attacker can eavesdrop but not manipulate the contents of the channel. In this regard it is some measure of an improvement.
For the record I do not think it is a final solution (what is). I do often have mixed feelings about 'the perfect being the enemy of the good'. With STARTTLS my feelings aren't as mixed. A measurable improvement to passive surveillance for minimal changes and no new infrastructure. Swell.
Again, not going to condone it as a panacea - but it's never advertised itself as one.
Let's keep using it until there's something better. And let's get furious at ISPs that strip it (or modify our traffic in any significant way).
> whole explanation boils down to "managed languages are more complex, therefore worse."
I hope that's not what I said...
> Please point me to the specific native features which mitigate timing attacks.
How am I supposed to implement bitslicing to vectorize operations in Java? I can't. Fine grained control of code is important for implementations of ciphers that are both fast and side-channel free. Fine grained control isn't something Java can give you, by definition.
I count exactly two countermeasures that apply to high level languages. Of the first they say "We conclude that overall, this approach (by itself) is of very limited value" and of the second "beside the practical difficulties in implementing this, it means that all encryptions have to be as slow as the worst case... neither of these provide protection against prime+probe/etc".
The rest of the countermeasures suggest bitslicing, use of direct calls to hardware instructions, memory alignment tricks, invocation of hardware modes (i.e. to disable caching), forcing cache ejections, normalizing cache states on interrupt processing, etc.
It is purely the case that high level languages do not offer you the flexibility and control to implement side-channel free crypto.
Crypto is brittle. High level languages are awesome for so many things. But bitslicing isn't one of them. The entire premise of high level languages is that you are freed from working directly on the innards pertinent to the specific target architecture. The entire premise of side-channel free crypto is that you need visibility and control of exactly these things.
The window from disclosure of patches to duplication is narrowing and it appears from the bulletin that client connections are affected as well. Furthermore any computer you take anywhere outside your home router (and can you really trust your home router as security boundary nowdays?!) will be easy to manipulate into an SChannel connection. Inside your home network, clients are still vulnerable to attack - any javascript/flash ad/referer can point a computer behind a router at an attacker server and serve up malicious SChannel packets. That is to say your home computer can be attacked on outgoing connections which your router will be happy to allow.
> Timing attacks are often the result of optimisations within the crypto library which inadvertently give away information, for example a loop which breaks on X != Y, instead of setting a failed = false bool and continuing to iterate through the rest of the array.
I would say this is false. Simple differences in time caused by cache line ejection in table-lookup implementations of AES provide a very strong timing attack. (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf)
In RSA (and in fact DL based cryptosystems), modular exponentiation without extreme care leak tons of timing information about private exponents. 'Blinding' is one way to handle this, but performant solutions typically fiddle at the bit level and exploit CPU guards and features to minimize branch prediction/cache line/etc leaks.
In higher level languages absolute control and care of crypto implementations can not be taken and the JIT layer adds another layer of obfuscation (though I know of no attack employing that...).
The out for memory safe languages is to provide built in crypto operations that have been implemented at a lower level.
> Net neutrality isn't a blanket term for "anything the government does relating to the Internet", it's focused on a specific issue.
Of course.
> I guess you could argue that net neutrality would make it easier to pass pro-surveillance laws, but I'm having a difficult time connecting the two.
The argument wouldn't be that net neutrality itself would make it easier. The argument would be that the regulation - especially if the folds ISPs under telecommunication laws or equivalents - could result in the import of large portions of legislation pertaining to communications access programs.
Much of this has actually already been done at the ISP level and the (surveillance) struggle seems mostly focused on the application layer.
So I guess I might agree that it may not bolster surveillance capabilities - if only for the fact that ISPs have already been mostly captured.
Some here may know me as a critic of overreaching and aggressive cyber enforcement (and related surveillance).
First, I'm quite happy that this activity does not appear to be the result of wide scale infrastructure sabotage.
And I am quite happy that the FBI is doing its job to combat crime that is facilitated using (abusing) the technologies that are bastions for free speech, privacy and whistleblowing.
Of course the flipside is that this means that there are capabilities in place to disrupt anonymizing technologies - the technologies make investigation more expensive but ultimately are merely an inconvenience to the powers that be. So when it comes down to it, anonymizing services and Tor can't be trusted to secure you if you have something to say where your life is in danger.
The FBI (/others) wants the court system to replace technology as the gatekeeper to investigation. The court system, however, is brittle. It takes time, it fails, and it responds to external pressure - there are repeated studies that show that the length of time persons in US court systems are convicted to serve is highly correlated with how long it has been since the precising judge has eaten his last meal. There are also extralegal rights that law enforcement are given by legislature and evolving interpretations of what both these legal and extralegal rights entail.
But law enforcement also is justified from their perspective. They don't want there to be criminals that get away with crimes simply because criminals load up some software that obfuscate their identities, locations and accounts. If you look at this published list there are criminal organizations that you and I as taxpayers do want taken down. (I recognize that the sale and consumption of drugs is a greyer area of morality as drug use is sometimes victimless).
I think that for the most part law enforcement is capable of taking down these services and organizations other ways - ordering assault rifles and monitoring the drops - and that this provides opportunities for the government to enforce the law without sabotaging communications infrastructure. Taking down some .onion addresses doesn't do too much besides annoy the services for a time anyway unless the services operationally are not capable of standing up a new address and communicating with customers anonymously.
All in all it's a blurry line but I feel safer with places that are anonymous and secure than I do by trusting a court system and legal process that can only see, process, and be accountable for so much.
I think implementation bugs are within the spirit of OP, especially provided the NSA claims to have provided an implementation fix for Heartbleed.
The sorts of bugs I'm talking about exist in client and popular software. As far as tempo is concerned this year alone has given us BERserk, gotofail, Android Master Key, OpenSSL fork(), Bitcoin's use of P256, GNUTLS X.509 parsing bug, the OpenSSL compiler optimization+processor family randomness bug, and others.
If we were to entertain OP's point maybe there would be a faster tempo if the NSA were helping out. :)
Bug volume in crypto is extremely high. How many developers reuse IVs in stream ciphers? How many blindly use AES or somesuch other symmetric library and then build in no authentication whatsoever? How many antequated implementations of RSA are used in practice today (see recent Bleichenbacher flaw in NSS)? How many times are poor chaining modes for block ciphers chosen? How many implementations of [anything] fail on side cases (elliptic curves) or massively leak through side channels? How many DH-family protocols miss checks for identity inputs?
Right, NEC3's 'solution' to obscure zones by signing hashes effectively just renames zones that probably come from some small collection ('www', 'ftp', 'ns', 'smtp', 'ilo') and not secure for the same reason hashing phone numbers is ineffective.
Arguments that administrators can choose names with large entropy would miss the point as it puts an undue burden on administrators and users to use 'bizarre' names.
Further arguments that you can brute force names using normal ol' A records also miss the point. The difference is online versus offline enumeration.
> it's based on RSA PKCS1v15
Eww. I had no idea. Next you'll tell me the root key's public exponent is 3. Gross.
> If your most important adversary is GCHQ and NSA, then the Internet is far more threatened by the deployment of DNSSEC than it is by DNSSEC's absence.
Not sure it makes too much of a difference in this case... you can't trust non-signed DNS records if your adversary is NSA/GCHQ, and you can't trust typical PKI to bail you out either.
Six digits sounds about right for a Tor bug for one target depending on the specifics. The RCE bug used by the FBI recently against the Tor Firefox Bundle would have cost something similar, though the payload suspended the process where it could have resumed silently. It's not clear where that exploit was developed (my gut says in house but who knows?)
Oh we're not talking trivial bugs or single-site XSS.
Disappointed that 'mediocre' vulns got interpreted in this thread as 'trivial'.
Mediocre doesn't mean trivial, extremely scoped or useless. Mediocre means that it is for sensitive but not widely deployed software, for widely deployed software on default config but is post-auth or is not reliable, or it is reliable and yiels high auth but requires pairing with another vulns (i.e. memory disclosure) or extended recon (revision number, etc).
A MySQL bug affecting recent revisions that causes arbitrary file overwrites with semi-controlled content but that requires unprivileged (guest) auth would meet this criteria.
Apologies for the confusion with the word 'mediocre' - I figured people here would know.
In general organizations in the offensive world will pay more than those in the defensive world. This is not a hard and fast rule, but mostly it is the case that offensive network operations stand to gain more from the use of 0days than vendors stand to lose by not paying for the disclosure to patch them. It's not really a good calculus to use data from vendors sales to calculate the other.
> But I honestly can't help but feel we've reached pretty close to the bottom of that slope. In the sense that I feel like our government just kind of makes stuff up as it goes along and only occasionally responds well to the strongest forms of shame.
In 2010 the Obama administration added an American citizen (Anwar al-Awlaki) to the CIA kill list, circumventing all due process. In a year they were able to strike and kill him with with a drone. They also hunted and killed his son, a 16-year-old US citizen, a couple of weeks later.
The Obama Administration, when challenged, claimed that it has the right to kill in 'dire situations requiring an immediate action to save lives'. However, they were not able to provide, for al-Awlaki or his son, evidence that there was such an immediate threat. First it's an absurdity because they hunted him, and had him on a kill list, for a year. Furthermore, the US had tried a drone strike on al-Awlaki before but missed. In this case there is no question that there was no immediate threat.
Finally al-Awlaki is not known to have participated in any violent action. Rather he was a radicalizer. As an imam, he preached about Islam and about the West. He was popular online (some called him the 'Osama Bin Laden of the internet') where he would exercise free speech (however extremist) but US government partnership with online companies such as Youtube were able to mostly silence him.
al-Awlaki's father even tried - before his son was killed - to get him removed from the kill list. But he was blocked in court.
You mention MLK. There are some parallels - his carrying a radical message and evangalizing others, and his status as a religious and spiritual leader. I do not mean to draw equivalence - only analogy.
Because I wonder what would happen to the next MLK. If al-Awlaki is any precedent then I worry that our guarantees of a fair and speedy trial - jury of peers and all of that - won't be respected when it isn't convenient.
As an addendum I'd like to note that we're seeing more of this. Snowden is allowed to come home and face trial - on the condition (imposed by the US government) that it is not a trial by a jury of peers.
Actually, it does not look like the UID is a PUF - although it's a very interesting idea!
"Unique ID (UID) - A 256-bit AES key that’s burned into each processor at manufacture. It cannot be read by firmware or software, and is used only by the processor’s hardware AES engine. To obtain the actual key, an attacker would have to mount a highly sophisticated and expensive physical attack against the processor’s silicon. The UID is not related to any other identifier on the device including, but not limited to, the UDID." - https://www.apple.com/ipad/business/docs/iOS_Security_Feb14....
> "To obtain the actual key, an attacker would have to mount a highly sophisticated and expensive physical attack against the processor’s silicon."
This is not true if the UID is generated in some way that allows pilfering by the manufacturer.
> So, generating a list of PUF outputs for all 10,000 4-digit numeric passcode would take Apple ~14 minutes--and it must be done on each device.
The threat model here is not Apple, but the manufacturer. In this case the options I mentioned earlier would allow very fast attacks that could be launched selectively at target devices later on.
> Of course, this is all a moot point, as none of this is verifiable (at least, to me and you).
Definitely not verifiable of falsifiable by you or by me. I would suggest however that the claims and reputation of the Secure Enclave is not deserved. Finally, in crypto, skepticism is a feature.
> Since PUFs typically get their values from random process variation
How sure are we that this is the case, and how can we verify it? You can burn in whatever bits you want to the PUF. If there is a list, a product to UID mapping, a deterministic UID generation process or even PRNG that isn't strong enough the Secure Enclave falls.
First, Tor protects the network communications. It separates where you are from where you are going on the Internet. What content and data you transmit over Tor is controlled by you. If you login to Google or Facebook via Tor, the local ISP or network provider doesn't know you are visiting Google or Facebook. Google and Facebook don't know where you are in the world. However, since you have logged into their sites, they know who you are. If you don't want to share information, you are in control."
> Apple ... can't decrypt data encrypted with the passcode ... today or ever before.
The passcode of 12 bits...
Apple can and will provide ciphertexts, will hand over copies of the large amounts of data customers are encouraged and sometimes forced to upload.
> This whole thread has been about whether they have the keys to decrypt encrypted data on the device. They don't.
From the top of the post: "CALEA, the Stored Communications Act and Section 215 of the Patriot Act all compel corporations (via the Department of Commerce) to build DATA AND key escrow services into their products."
What you're saying is that they don't provide key escrow specifically (while wholly ignoring data escrow). What I'm saying is that by design the crypto doesn't matter in practice and the system had been (still is) architected to allow for data intercept.
When you argue the 'no key escrow!' case you are implicitly condoning 'they won't hand over your data!'.
Not true. It was the case and _still is_ the case that Apple and its manufacturers will give access to your private communications, metadata and data.
We've focused on Apple but Google is not different.