Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
That is the data is encrypted on the client prior to being sent up into the
Very simple, very effective and should quell people's fear. AES256 should be
plenty. Maybe optional 2-factor encryption for those that are very paranoid.
Howto fix the problem:
Posted Oct 14, 2009 23:42 UTC (Wed) by gdt (subscriber, #6284)
Even with encryption, traffic analysis can still reveal information you'd rather keep private.
Posted Oct 15, 2009 0:11 UTC (Thu) by drag (subscriber, #31333)
I really doubt there is much useful information that anybody could gleam from
syncing to a online backup share other then the location of the firewall I
was operating behind at the time I did my last sync.
Traffic analysis can surprise
Posted Oct 15, 2009 2:27 UTC (Thu) by jreiser (subscriber, #11027)
Posted Oct 15, 2009 4:15 UTC (Thu) by dlang (✭ supporter ✭, #313)
however, if someone is not after you specifically, but is just after things that they can sell, it becomes much easier to have reasonable defenses
"I don't have to outrun the bear, I just have to outrun you"
with "you" being enough other users that the bad guys don't get around to bothering with me.
yes, this is security by obscurity, and if someone decides to go after you it doesn't help much, but the reality is that for the vast majority of people this really is good enough.
Posted Oct 15, 2009 1:19 UTC (Thu) by msebast (guest, #57130)
I guess Elilot Murphy's email was intended for people who already know what couchDB is.
I've heard about couchDB a few times but never seen any mention of encryption. So I've always assumed this is something I don't want and didn't investigate further.
Posted Oct 15, 2009 2:18 UTC (Thu) by drag (subscriber, #31333)
I am very uninterested in any sort of "cloud" backup scheme that does not
integrate encryption on the client side.
Why? (a person may ask) A few reasons. Whether or not a person should trust
a third party corporation is entirely up to debate... when the encryption
on the client side then it is not a matter of debate; whether you trust
them or not is irrelevant.
The other thing is that it makes storage side a lot cheaper and a lot
easier to implement. I don't have to worry so much about security... A
attacker could break the system and corrupt my data, but there is no
information leakage possible. So while things like TLS and hashing of the
data is important from a identity management and data integrity point of
view it is entirely unimportant to prevent things like identity theft or
whatever. The worst thing that could possibly happen is a DOS attack.
This makes things cheaper; I only have to keep a database of hashes and
check those periodically and authenticate writes, but reads can be done by
anybody and I wouldn't really care... so data preservation techniques like
"lots of copies all over the place" is easy to implement and can be spread
out over lots of organizations without having to care exactly what those
organizations are doing.
As you can imagine that if I was a third party provider of storage that
this sort of approach would massively reduce the amount of headaches I have
to deal with.
Posted Oct 15, 2009 4:09 UTC (Thu) by dlang (✭ supporter ✭, #313)
if you loose those keys you loose your data, so it does no good to store your data in multiple places if your keys only exist on one machine.
for many people who do not have good ways to store the keys, they are actually better of in many ways with the data in the clear so that they can pull it back down to a replacement machine if something happens to the first one.
yes, this is not good from a security point of view, but in this case the security risks need to be balanced against the availability risks. which one is more important will vary from person to person.
Posted Oct 15, 2009 5:33 UTC (Thu) by drag (subscriber, #31333)
The choice is simple really.
Do you want to keep track of a password..
or depend on the security of every machine in Canonical, every workstation
in the data center that people come into contact with that people use to
access administrative portions of the "cloud"? Do want to trust the
security of every machine on the cloud? Do you want to trust every
employee, every administrator, every janitor that access to the machines
that house your data?
All in all it is a massive undertaking trying to keep data safe and
security for what will be practically forever if you take the approach that
users should take no responsibility for their data!
And it's hugely expensive undertaking, to boot. It is virtually impossible
to do in correct manner if you think about it.
Meanwhile if your job is to handle already encrypted data then it is much
simpler. You could post your customer's data to craigslist and not have to
worry about it.
It is not difficult to print out copies of your keys into ascii armor
format and put a hard copy in a secure place. People do that shit all the
time with all sorts of documents. They rent out lock boxes in banks, go and
get fire-proof safes at Walmart for 50 bucks, and all sorts of stuff like
(and, frankly, the notion that you should never write down your passwords
or create hard copies of your keys is one of the worst pieces of security
"common sense" I have had the misfortune to run into over and over again.)
If you value your data and want to be able to use Ubuntu's cloud service
for anything other then a toy or a cheap way to sync address books then
client-side encryption is just the obvious way to go from my perspective.
I could be wrong, but it makes sense to me.
Posted Oct 15, 2009 7:22 UTC (Thu) by dlang (✭ supporter ✭, #313)
I would not use their service personally (I would do the client-side encryption and keep track of the key), but I know a lot of users who I would recommend use something like this so that when they trash their system badly enough that they need to reinstall their systems they will still have their data. Many of these users have trouble remembering one password for their system, let alone taking appropriate actions to protect an encryption key.
Posted Oct 15, 2009 8:02 UTC (Thu) by ekj (guest, #1524)
And yes, if that happens AND I've forgotten the password for the encryption, it's acceptable for me to suffer data-loss. We're talking miniscule probabilities here. (I'd have to forget the password I use for logging in every day at the precise same time that something catastrophic happens at home. That's a level of risk that is entirely acceptable to me.)
Sending my entire digital world to some random company on the internet, for them and anyone that aquires, breaks into, subpoenas or otherwise gains access to their servers ? No thank you, not interested.
Posted Oct 15, 2009 17:39 UTC (Thu) by dlang (✭ supporter ✭, #313)
we also don't need a service like this because we can replicate and protect things ourselves.
this service is intended for people who otherwise are not backing things up, let alone replicating an encryption key for the backup.
Posted Oct 15, 2009 13:19 UTC (Thu) by sourcejedi (guest, #45153)
If you can trust someone to hold your launchpad password in escrow, you can surely trust them to do the same with your encryption password.
In practice, I suspect you can just reset your launchpad password by email. So you have to rely on your ISP resetting your email password when you forget _that_. And that they don't go bust or disconnect you for using too much bandwidth making online backups :-)...
Yes, many people are likely to accept this service given the choice. But this is a pretty low bar to pass. We can and should do better.
Posted Oct 15, 2009 16:23 UTC (Thu) by drag (subscriber, #31333)
It is easy to keep a password or key safe. Print it out into a hard copy
and put it in a secure place with the rest of my critical documentation
(automobile title, birth certificate, mortgage information, etc etc)
Then it is win on both sides. As long as you make it absolutely known that
Canonical has no knowledge and cannot ever retrieve the password for you
then I think that is acceptable.
I suppose if customers trust Canonical then they can just send them the
key/password to keep track of. It would be a lot easier to keep that safe
then a "cloud".
Posted Oct 15, 2009 17:37 UTC (Thu) by dlang (✭ supporter ✭, #313)
Posted Oct 15, 2009 10:14 UTC (Thu) by nix (subscriber, #2304)
(Now everyone else can tell me how stupid this idea is.)
Posted Oct 15, 2009 16:33 UTC (Thu) by drag (subscriber, #31333)
The LUKS password is relatively simple (plain english phrase), but it
should be enough to protect it if I drop it somewhere.
When you plug it into a Linux Gnome desktop automatically prompts you for
the password and opens up the folder for you. So it is very convenient.
I can't recommend this approach to normal folks because it only works if
you plug it in rarely. If you leave it plugged in all the time then it is
no better then having it in a folder.
But what is better (in terms of security) would be to print out keys into
ascii armor format or write down passwords to a hard copy. That way they
are impossible to hack! A person would have to physically break into my
house and search through my drawers and filing tower to find it.
Posted Oct 15, 2009 17:36 UTC (Thu) by dlang (✭ supporter ✭, #313)
Posted Oct 15, 2009 11:06 UTC (Thu) by endecotp (guest, #36428)
Does anyone know how to get rsync-like functionality with the data at the other end stored encrypted?
I currently use rsync over ssh for some of my backups, so the data is encrypted on the wire but unencrypted on the remote disk. When I set this up I tried to find a way of storing the remote copy encrypted without losing rsync's efficient incremental transfers, but I didn't find anything satisfactory. Any ideas?
Check out Tarsnap
Posted Oct 15, 2009 12:26 UTC (Thu) by fghorow (subscriber, #5229)
Just a happy user of the service.
(Be aware, it is a *for a fee* service, but the micropayments are truly micro!)
Posted Oct 15, 2009 13:09 UTC (Thu) by sourcejedi (guest, #45153)
Posted Oct 15, 2009 16:01 UTC (Thu) by zooko (subscriber, #2589)
Posted Oct 15, 2009 8:25 UTC (Thu) by job (guest, #670)
Posted Oct 16, 2009 7:40 UTC (Fri) by brouhaha (subscriber, #1698)
Posted Oct 16, 2009 13:02 UTC (Fri) by pharm (guest, #22305)
Leave designing encryption algorithms to the experts: Personally, I know just enough to know that I
don't know anything like enough to start designing my own encryption schemes.
Posted Oct 16, 2009 19:22 UTC (Fri) by brouhaha (subscriber, #1698)
However, that's just the time complexity. The meet in the middle attack also requires storage for 2^n blocks, which is obviously not available for n=112, let alone larger values of n.
Posted Oct 16, 2009 20:08 UTC (Fri) by ABCD (subscriber, #53650)
I think there is a mistake somewhere in there, because 2^(2n) = (2^2)^n = 4^n.
Posted Oct 18, 2009 16:08 UTC (Sun) by pharm (guest, #22305)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds