4 ms·

> I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Who would it be readable to if not the sit

> I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Who would it be readable to if not the site operators? > Mega is an example of where JS crypto might have some value. So it might be useful to someone, somewhere as a legal subterfuge. > For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS Good to know that it's secure in the absence of an attacker.

lawnchair_larry 13y ago
Well you're being snarky, but I'll address those points anyway. Please understand that I'm not advocating for JS crypto or ignoring its other problems. > Who would it be readable to if not the site operators? SSL offers no protection against the following: Amazon AWS employees. Azure employees. External attackers with read-only access. Employees of the website with read-only access. Employees that get curious and want to snoop, but not badly enough to inject code. Anybody with access to the backups. Other tenants on the same cloud who notice that memory or storage wasn't properly zeroed. Someone who breaks into the office and physically steals the server. > So it might be useful to someone, somewhere as a legal subterfuge. If you acknowledge that it's sufficient to prevent evidence recovery, and you have taken the position that is the only practical scenario under which that property has any utility, you're not a very creative thinker. I'll try to expand your mind a little. I tried to use an easy real example. There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them. He or others in his position would not have been able to deploy new gmail code to perform an active attack, but reading offline storage is trivial. If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that. I'm reasonably confident that rogue Google or facebook employees aren't going to target me, insert active attacks, and get away with it. I'm not very confident that nobody there will ever passively snoop (don't even need to speculate, both companies have had public incidents at least once). http://www.informationweek.com/security/vulnerabilities/dropbox-files-left-unprotected-open-to-a/231000111 http://www.informationweek.com/security/vulnerabilities/drop... "Dropbox on Monday acknowledged that its vast store of files was left open to the world on Sunday for four hours as a result of a bug. During this period, any account could be accessed using any password. The flaw, a software bug that rendered the service's authentication mechanism non-functional, only took five minutes to fix, once it was discovered. As if on cue, Wuala, a competing cloud storage service operated by hard disk maker La Cie, published a blog post on Tuesday stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client. "Encrypting your files before they are sent to the cloud makes Wuala inherently more secure than solutions that rely on server-side encryption," the company said." http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-user-passwords-after-hard-drives-lost-in-office-burglary/ http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-use... > Good to know that it's secure in the absence of an attacker. No, I'll give you a few minutes to read it again though ;) Again, to reiterate, JS crypto has major issues, but it's untrue that you can simply use SSL instead. These are different problems. JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address.
- marshray 13y ago
  > If you acknowledge that it's sufficient to prevent evidence recovery Any snake oil is sufficient to thwart some attacker somewhere some of the time. Browser Script Crypto adds a lot of complexity. It also adds a metric crapton of insidious counter-intuitiveness to the security model. These are real and serious engineering drawbacks to BSC. In order for BSC is worthwhile in a given situation, you need to show that any benefits it may bring outweigh the drawbacks and do so better than other solutions. This is never the case in practice, because BSC is vulnerable to all the same attacks as the web browser. > There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them. Solution: Publicly fire the guy. Don't log the chats. > If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that. I think you're assuming that based on the belief that this engineer would not have been able and willing to conduct an active attack. What is your evidence for this belief? > I'm not very confident that nobody there will ever passively snoop Snooping is their (Google/Facebook) business model. It's just a question of whether or not their internal authorization process was followed. BSC doesn't solve the problem of the insider threat. It may make it marginally more risky for some insiders some of the time, but there are already an unlimited number of ways to make life more complicated for insiders (legitimate or not). > The [Dropbox] flaw, a software bug that rendered the service's authentication mechanism non-functional, As a rule, if the authentication is broken, the encryption is too. > [La Cie] stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client Only maybe if the user chose a strong password and there was literally no way for users to recover their data if they lost it. I'm not against client-side encryption. I'm a fan of PGP and Truecrypt. > JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address. I can think of one or two such scenarios, but not many. Mr. Dotcom may well be the exception that proves the rule; his primary adversary is the US DOJ. It will be very interesting to see how this plays out.
  - deleted 13y ago
    [deleted]
  - deleted 13y ago
    [deleted]

lawnchair_larry 13y ago

Well you're being snarky, but I'll address those points anyway. Please understand that I'm not advocating for JS crypto or ignoring its other problems. > Who would it be readable to if not the site operators? SSL offers no protection against the following: Amazon AWS employees. Azure employees. External attackers with read-only access. Employees of the website with read-only access. Employees that get curious and want to snoop, but not badly enough to inject code. Anybody with access to the backups. Other tenants on the same cloud who notice that memory or storage wasn't properly zeroed. Someone who breaks into the office and physically steals the server. > So it might be useful to someone, somewhere as a legal subterfuge. If you acknowledge that it's sufficient to prevent evidence recovery, and you have taken the position that is the only practical scenario under which that property has any utility, you're not a very creative thinker. I'll try to expand your mind a little. I tried to use an easy real example. There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them. He or others in his position would not have been able to deploy new gmail code to perform an active attack, but reading offline storage is trivial. If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that. I'm reasonably confident that rogue Google or facebook employees aren't going to target me, insert active attacks, and get away with it. I'm not very confident that nobody there will ever passively snoop (don't even need to speculate, both companies have had public incidents at least once). http://www.informationweek.com/security/vulnerabilities/dropbox-files-left-unprotected-open-to-a/231000111 http://www.informationweek.com/security/vulnerabilities/drop... "Dropbox on Monday acknowledged that its vast store of files was left open to the world on Sunday for four hours as a result of a bug. During this period, any account could be accessed using any password. The flaw, a software bug that rendered the service's authentication mechanism non-functional, only took five minutes to fix, once it was discovered. As if on cue, Wuala, a competing cloud storage service operated by hard disk maker La Cie, published a blog post on Tuesday stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client. "Encrypting your files before they are sent to the cloud makes Wuala inherently more secure than solutions that rely on server-side encryption," the company said." http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-user-passwords-after-hard-drives-lost-in-office-burglary/ http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-use... > Good to know that it's secure in the absence of an attacker. No, I'll give you a few minutes to read it again though ;) Again, to reiterate, JS crypto has major issues, but it's untrue that you can simply use SSL instead. These are different problems. JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address.

marshray 13y ago
> If you acknowledge that it's sufficient to prevent evidence recovery Any snake oil is sufficient to thwart some attacker somewhere some of the time. Browser Script Crypto adds a lot of complexity. It also adds a metric crapton of insidious counter-intuitiveness to the security model. These are real and serious engineering drawbacks to BSC. In order for BSC is worthwhile in a given situation, you need to show that any benefits it may bring outweigh the drawbacks and do so better than other solutions. This is never the case in practice, because BSC is vulnerable to all the same attacks as the web browser. > There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them. Solution: Publicly fire the guy. Don't log the chats. > If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that. I think you're assuming that based on the belief that this engineer would not have been able and willing to conduct an active attack. What is your evidence for this belief? > I'm not very confident that nobody there will ever passively snoop Snooping is their (Google/Facebook) business model. It's just a question of whether or not their internal authorization process was followed. BSC doesn't solve the problem of the insider threat. It may make it marginally more risky for some insiders some of the time, but there are already an unlimited number of ways to make life more complicated for insiders (legitimate or not). > The [Dropbox] flaw, a software bug that rendered the service's authentication mechanism non-functional, As a rule, if the authentication is broken, the encryption is too. > [La Cie] stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client Only maybe if the user chose a strong password and there was literally no way for users to recover their data if they lost it. I'm not against client-side encryption. I'm a fan of PGP and Truecrypt. > JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address. I can think of one or two such scenarios, but not many. Mr. Dotcom may well be the exception that proves the rule; his primary adversary is the US DOJ. It will be very interesting to see how this plays out.
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]