4 ms·
Why would anyone be surprised about this? If you can't read a whitepaper, and inspect the algorithm to a degree where you can create your own provably-compatib
by nly 8y ago
Why would anyone be surprised about this?
If you can't read a whitepaper, and inspect the algorithm to a degree where you can create your own provably-compatible implementation, or easily inspect the vendors source code, then you should just assume it's implemented incompetently and is completely and utterly compromised.
The same goes for all cellular/mobile phone encryption standards, proprietary VPN solutions, proprietary DRM, crypto used in banking (Chip n Pin etc etc). All compromised. Period. Don't trust it. All crypto implementations should be guilty until proven innocent under serious peer review.
The same attitude should be taken with anything not encrypted. Yes your ISP is spying on your browsing habits, logging everything, and probably will one day sell that data. Yes your bank is analyzing your spending habits. Just assume it's happening. There's enough evidence out there now that this is the new reality.
- yellowapple 8y agoYep, yep, and yep. I've said it enough to sound like a broken record: Transparency is a dependency of trust. If you can't see how it works, then it's objectively impossible to trust it to do the right thing. This applies to everything on a computer, really. Is your browser transparent? Is your operating system transparent? What about the drivers? Device firmware? That "security" solution that unexpectedly ushered in the Year of the MINIX Desktop™? Of course, we sacrifice some of those points in favor of pragmatism, but if you ain't paranoid about your computer's lack of transparency, you should be.
- nly 8y agoIt's not really about vendors being malicious. It's just that both the carrots and the sticks involved in providing secure products are weak. You can slap a "Uses 256-bit military grade encryption" sticker on your product, pull some half-arsed home-baked crap and make more money. When someone exposes you you just go "Darn, those hackers... ruining things for good everyday folk" It's an attitude problem. Most people wouldn't buy a glass house where people on the street could watch you shower and poop, but that's what we have in tech.
- yellowapple 8y agoNever said it was about malice. Incompetence and negligence are just as good of reasons for someone to be untrustworthy :)
- xoa 8y ago>Transparency is a dependency of trust. I think you go too far here. Trust is a dynamic spectrum, not binary. Transparency is one potential avenue to add trust, but is neither necessary nor sufficient in most cases. Every instance must be evaluated in light of its specific details, threat scenarios, and available tradeoffs. >If you can't see how it works, then it's objectively impossible to trust it to do the right thing. For most people "seeing how it works" is utterly meaningless by itself because few are able to properly evaluate the system (both knowledge and time play a role). For complex systems they're simply physically beyond the capability of any human to retroactively fully evaluate, or any system at all for that matter. Transparency can help positively change the incentives all involved players face, lower the upfront resource cost to evaluation which in turn may allow users to expand their trust parties to include actors with more direct interest in their interests, allow more casual white hat investigation even if there is less direct compelling need, etc. In this specific case yes, open should definitely be standard given the stakes and because pure symmetric crypto should be simple, fast and standardized long since. There is no competitive advantage or secret algorithms here to be had. Furthermore as something that is effectively "infrastructure" it can result in less attention then flashier stuff. But transparency is not a panacea, and closed software can perfectly well be probed anyway (as this very software and every single vulnerability ever found in proprietary software demonstrates!). The biggest value of open is less finding issues then fixing them. That was always the big driver of open source, not that it would somehow be magically bug free by the power of a thousand eyes but that when issues were discovered users wouldn't be up shit creek because whoever made it had gone out of business or moved on to new products or whatever. That has happened constantly with proprietary products for decades, the frustration with that is the huge practical driver for OSS. Over a long enough time span a lot of proprietary software devs will die or pivot or abandon useful expensive "old" tools without support and in turn their customers will get screwed. Transparency/openness can help with that, or at least offer more options. But in terms of just finding security vulnerabilities it's much less of a big deal then it gets made out, which again should be obvious given all the security vulns in proprietary software constantly being found.
- basilgohar 8y agoI did not read GP as saying it was a binary choice, but rather a prerequisite. That is to say, without transparency, there can be no trust, but you can also have no trust with transparency. For someone like me, who is somewhat technically competent, but not a security expert, openness means that names and figures I do trust have the chance to examine whatever I intend to use and comment on it, observe it, and make assessments, including shaming poor implementations claiming traits they have no right to. Turns out there are plenty of people more competent than me that can catch these things. Transparency also allows less hiding of incompetency in otherwise commercial and/or proprietary designs.
- tptacek 8y agoReally, not so much. The problem here isn't so much with transparency as with delegating cryptography to non-cryptographers (or, for that matter, trusting that other vendors have had cryptographers review their designs). Based on the track record not only of open source cryptography but also of internal review of closed-source cryptography (that is: closed source software reviewed by the vendor that wrote it), having access to designs and code is of marginal importance. Crypto bugs of comparable severity have lived for many, many years in these systems. What you actually want is an assurance that no link in the security chain of a system protected by cryptography depends on a cryptographic capability had hasn't been formally assessed. Ideally, you want the specific name of the person who assessed it. For instance: Intel's SGX setup has been audited by third parties and was also designed and in some sense overseen by Shay Gueron. You will never see any of that underlying code, but you would probably be crazy to trust an comparably ambitious un-vouched cryptographic enclave more than SGX. Similar story with Amazon and KMS (again: Shay Gueron, but also in-house crypto experts at AWS). If anything, this story illustrates how weak an obstacle closed source really is. This is an academic project, and they tore up something like 8 different drives and game-overed most of them. Of course, I agree with the broader point that Microsoft shouldn't have trusted hardware cryptographic capabilities they clearly knew nothing about (Microsoft also has sharp crypto people, all of whom would have barfed all over any of these designs).
- nly 8y agoSorry no, i don't trust Shay Gueron either and, even if I did, I wouldn't trust what Intel, AWS or anybody else did after he left the building. Same goes for Whatsapp. It might be based on Moxies protocols and excellent work. I might trust Moxie, but I still don't trust WhatsApp to be eavesdrop free because I can't easily create compatible clients, inspect their protocol, or look at their code. That's not to say you shouldn't use TPMs, HSMs, or CPU enclaves. It's just that, if at all possible, you shouldn't elevate them to being the only thing protecting you. In fact, most of these devices can be coupled with software encryption by splitting secrets between them and the users brain. My android phone for instance is encrypted, but only protected by a 6 digit PIN. I'm aware that I'm totally dependent on the SoC vendor here to rate-limit and otherwise fend off bruteforce attacks and protect the key ultimately protecting my data. But you know what? The encryption itself is still done in software and can be verified, and I have the choice to use a ridiculously long passphrase instead. What Microsoft did is choose a stupid default, and put their users at unknown risk.
- pasbesoin 8y agoI've been moving more of my purchases back to cash. Not that I'm purchasing anything nefarious -- well, until I consider how e.g. purchasing medication X may be used against me, something I consider to be nefarious on the part of these companies doing and using said data mining. Anyway, not that I'm purchasing anything nefarious. But to hell with them. P.S. I also occasionally think about the 2-5% price markups we universally face, put in place to compensate for credit card processing fees. Although there are valid counterarguments about the risk and cost for businesses, and people in more personally vulnerable environments, of handling cash.