No sniffing allowed
Google won't like that one bit
Computer scientists in Ireland have developed a technology for Google Docs that allows for the "real-time" encryption of data before it is uploaded to the Google servers. The CipherDocs system, developed by computer scientists at Trinity College, Dublin, is designed so that Google would not have access to the keys necessary to …
Google won't like that one bit
Neither will GCHQ or Theresa May
If GCHQ wants to access the files they just need the master passwords, I am sure GCHQ has numerous tools to obtain those if they need them.
You can't crack AES - it's used by the US to encrypt all their sensitive data. Well you can crack it, but you'd be long dead by the time you did, as would be our sun.
British courts can order someone to turn over the encryption keys for their data. There's no fundamental right to silence, to prevent self-incrimination, as there is in the US. British courts really can force you to choose between imprisonment for contempt of court/obstructing the course of justice or for whatever it is you're being charged with.
The US courts are moving away from allowing right to silence in the face of self-incrimination to apply to handing over encryption keys. The EFF & co are fighting it, but they are losing, sadly.
Your company allows you to post/backup/distribute sensitive material through 3rd party services like dropbox and google rather than their own sftp ?
If ever need be, i heard you could encrypt archives for just the occasion...although its a good idea, i dont see it being needed/used in business environments, but maybe thats just my opinion.
Got a feeling that Google will say this infringes on their T&Cs. They won't allow encryption for Google Docs unless they have the ability to decrypt the documents.
I think it's an interesting and laudable idea, but as others have already said, it could fall foul of Google.
I think it might still have some legs with DropBox though.
Dropbox "saves" space and bandwidth on their servers by scanning files / checksumming them so it's not necessary to upload or store a file if another user has already uploaded that same file. If I encrypt a bunch of mp3 (or other files) then the output will be different for each user, so Dropbox's storage costs could increase, passing that increase to Joe Public.
... it leaks quite a bit of information, so doesn't really provide any confidentiality to write home about, much less stake anything important on. In roughly the same sense that encrypted voip (and skype) might be encrypted, but boffins recently figured out (as was reported by el reg too) how to turn it into a transcript with high probability nevertheless.
Other than that, people have burned more cash on lesser ideas. It'd be interesting to see if they can come up with something more robust, something actually usable, because $deity knows we could use it.
Info is certainly leaked - timing patterns plus formatting information. I think this is mentioned in their FAQ. Also there is no security against active attacks. Might be interesting though for specific sensitive fields like social security numbers etc..., but at the moment this beta shouldn't be used for confidential info.
This is the way cloud services should work. It should create an encrypted bubble that only my business has access to. Anyone who works at the hosting company or the outside world should see gibberish.
It might be interesting to redact documents this way.
certainly better then putting a black box over them in a PDF...
I like the nuclear option better.
http://www.rustprivacy.org/TakingWorkHome.pdf Wrote this 5 years ago. It's not hard to set up OpenOffice to redact either ODT (text) or ODS (spreadsheets).
It's so much more fun to exercise the "right to be forgotten" by letting them vacuum, then posting the redacted document in the same place, and letting them vacuum again overwritting the "old" information.
but not important enough to host under your own physical control?
What a crazy world!
To be filed under, "Cool, but why would you?"
Biting the hand that feeds IT © 1998–2017