Modes of operation
in [Cryptography]
|
Prev: Why is Kerberos ever used, rather than modern public key cryptography?
Next: Server and Client Analogy � The New Cryptography Model
From: Kristian Gj�steen on 13 Mar 2010 12:14 Christian Baer <christian.baer(a)uni-dortmund.de> wrote: >Kristian Gj�steen wrote: >> Don't use Blowfish. Don't listen to people who prefer Blowfish over AES. >> And don't listen to people of regurgitate vague feelings people had ten >> years ago when AES was new. > >Well, actually, this was someone who held a lecture at the convention, >so I assumed he knew what he was talking about. That might be incorrect. >>> The article on disc encryption theory in the Wikipedia states that XTS >>> should only be considered secure when the amount of data encrypted >>> (meaning the file system, I guess) is not much bigger thatn 1TB. The >>> limit you mentioned seems to be much bigger (something like 2,7E11GB) for >>> 128-bit ciphers. >> With 128 bit blocks, you have a probability of collisions of about 2^-48 >> after encrypting 2^40 blocks. If you encrypt as much as 2^64 blocks, >> you will most likely have collisions and security will be lost. > >But even 2^40x128bits is a *lot* more than 1TB. So the limitations of >size for XTS seem to come from somewhere else. I don't can't remember. I'd look at the XTS standards and other background material. Though, 1TB = 2^33 bits = 2^26 blocks, giving a collision probability of approximately 2^-76 or thereabouts. >Does this mean, I can securely encrypt files systems using CBC (with >secret IVs and a single key) with sizes of 2TB and more? Well, probably... -- Kristian Gj�steen
From: Kristian Gj�steen on 13 Mar 2010 16:12 Thomas Pornin <pornin(a)bolet.org> wrote: >I am not, unless you use the term "watermarking" with a meaning which I >am not aware of. I think that attacks that break IND-CPA for disk encryption, but do not seem much stronger than distinguishing attacks are often called "watermarking" attacks in disk encryption implementation circles. One more note on XTS vs CBC: XTS has some protection against active attacks, while CBC has no protection. When your threat model is that you worry about theft, active attacks aren't interesting. Then again, the cost of using XTS over CBC might be so small that it is worth it. -- Kristian Gj�steen
From: Christian Baer on 16 Mar 2010 06:38 On 28 Jan 2010 21:11:13 GMT Ilmari Karonen wrote: > Yes, the restriction to four letter words is just an ad hoc rule I > came up with by trial and error. I find that having all the words be > of the same length makes them easier to remember, and four letters > seems to about maximize "entropy per effort to memorize", though five > letter words do come close. YMMV. I suspect that in Finnish, which > tends to have somewhat longer words, five letters would be optimal. The same would apply for German which has longer words too. Additionally, I guess that a Finnish passphrase would drive anyone nuts who isn't a native speaker. Actually, Finnish drives anyone nuts who isn't a native speaker and tries to learn it. :-) > [Python script snipped -- thanks. I have a Perl script that does the > same thing, but yours looks more readable. :)] That is often true to Python. :-) Regards, Chris
From: Christian Baer on 16 Mar 2010 11:18 On Thu, 28 Jan 2010 11:31:32 -0800 Paul Rubin wrote: > Well, Kristian gave the best answer of all: "Note that you do not deploy > a real solution based on random advice from USENET." Which is to say, > you should get specialists involved in your project if you are doing > something serious. Currently, this is research for myself. >> This will not be a 'deployed' system. I intend to set up a server with >> some flavour of Unix on it (NetBSD, FreeBSD or Linux, not sure yet). > ??? What do you mean that it won't be a deployed system? Deployment > just means the system is running with real data and users, rather than > just test data. Slightly dumb description in my case. Sorry. :-) I meant, I am just going to set it up. That's all. No deployment. :-) > The operator is going to type this in on starting the system? Yup. > What happens if the power goes out in the middle of the night? Probably nothing because this is a test system. If there is "real" data on the system, then the operator (probably me) will be kicked out of be. :-) > What happens if the operator is run over by a train? He dies - probably. :-P There will be more than one passphrase to unlock the key and if the system is deployed, then more than one person will be able to unlock the system. > Will one operator have access to the entire key? Probably. See next question. > What happens if s/he is bribed, threatened, given too many drinks, etc.? The alternative would be to create a combo-key, requiring the passphrases of more than on operator to unlock. This reduces the bribe/threaten/drink risk a bit - although it is possible to influence more than one person in this way. At the same time, it raises the train-risk, as the key cannot be unlocked if one operator is incapacitated. So in any case there is a tradeoff. >> 2. A string of random characters with a length of at least 512 bits. >> This will be carried on a usb-stick or something and proabably cannot >> be remembered too easily.... The combination of both unlocks the >> key. I think this should be a pretty safe arrangement. > > That sounds way too casual. How are you going to erase old keys from > the USB stick when you are done with them? How are you going to dispose > of the stick if it electrically fails? Nothing. And I don't have to. I just change the key and have no more problem. :-) See below for more. > Maybe more to the point, do you REALLY have to load the decryption key > into the system in the first place? How many records are you going to > have, who will the users be (e.g. patients who can only access their own > data, or doctors or administrators who can access everybody's data), and > how will they access them (e.g. over the internet with their own > computers? Only in the hospital from terminals that you set up?) How > many queries per second will you have to handle, and how much data will > any query have to touch? Well, I wasn't really going to go into such detail, because what we are discussing here is slightly more than I had asked about - and we are going quite beyond the scope of this group. But, if you'd like to know and want to get bored... :-) A partner and I are working on a new business model or idea. We think we might have found a market gap which we intend to close. I don't want to go into the details, since it is quite possible that we may get competition before we even start. :-) Because of the nature of the business, which involves storing sensitive (medical) data, I'm concerned with security. If the information is stolen, our company could hardly be harmed. Legislation in Germany is very weak when it comes to this. The German Telekom "lost" a few hundred thousand sets of customer information (including bank information). Apart from the image loss, they don't have much to fear. Even though, I don't want anything like that happening to our customers, so I am doing some research. The data would be accessed by us (people in our firm) only and for starters only locally (meaning from within the offices, not via VPN or the like). Information would be passed on by phone. If someone tries to hold up the office, an alarm button would cause the server to shred the keys and shut down. Backups will be stored in a secret location off-site. Concerning the part about the key... What do you mean with that? Do you mean the passphrase? As I understand it, when you initialise a drive with geli (or any other modern crypto-system like Truecrypt or LUKS), a random key is created. This key is used to encrypt the data on the drive. This main key is encrypted with a second key. The second key is created using the passphrase and/or the keyfile. This way you can change the the passphrase without having to re-encode the whole drive. But I'm guessing you already knew that. :-) > Many serious systems simply assume the host computer is insecure, and > they put the sensitive stuff inside dedicated tamper-resistant hardware > modules (that can be as simple as a 5 euro smart card, if something slow > and small is good enough), and in some cases, all sensitive processing > takes place inside the module. Also, key loading is usually done from > smart cards rather than something like USB sticks. In our case a keyfile would come from something like a smart card. >>> What kind of access does the server itself need to the data? >> That is not decided yet. I am currently starting "low-level". > This is a pretty basic question that needs to be attended to much > earlier than details like encryption modes. In this case not really. Encryption modes don't influence the workflow. People using the machine won't notice if we are using CBC or XTS. >> Access to the server can be configured and reconfigured while it is >> running. > I don't understand what you mean by that. That means I can change the workflow without much hassle. Assuming I have a set of information stored on the server, accessing it could be done by several means, like a client for data base or some other software running on the server that allowes accessing the data base with a web browser. These are examples, not actual solutions. My point is that changing these access methods as well as passwords or the workflow around the information can be changed without much hassle. If I have to re-encrypt the drives, that would be much more ball-busting. :-) >> Encryption of data is a pain if it has to be done again. > You have to have an organized scheme for this in place. You will be > doing it more often than you seem to expect ;-). I certainly hope not! :-P > Well, how do they get their hands on the server in the first place? Is > it running when they steal it? If yes, they may be able to keep it > powered and get the keys and cleartext data directly from the RAM, > bypassing all the crypto. (That is part of the reason for using > specialized crypto hardware that resists this approach). It looks like > the data can stay accessible for several minutes after power is lost, > too: http://citp.princeton.edu/memory/ I know about the problem. There was quite an extensive article in a German computer mag about this. But this is being discussed somewhere else in this thread, so I won't go into it here. Regards, Chris
From: Maaartin on 16 Mar 2010 12:23
On Mar 16, 4:18 pm, Christian Baer <christian.b...(a)uni-dortmund.de> wrote: > > What happens if s/he is bribed, threatened, given too many drinks, etc.? > The data would be accessed by us (people in our firm) only and for > starters only locally (meaning from within the offices, not via VPN or the > like). Information would be passed on by phone. This is surely not very secure. In any country where there's a technical possibility to wiretap a phone, it can be done - either because of a court order or because of the responsible person being too curious. > > What happens if s/he is bribed, threatened, given too many drinks, etc.? If he's really given too manu drinks, he wouldn't be able to remember his name, and the passphrase would be more safe than ever. > The alternative would be to create a combo-key, requiring the passphrases > of more than on operator to unlock. This reduces the bribe/threaten/drink > risk a bit - although it is possible to influence more than one person in > this way. At the same time, it raises the train-risk, as the key cannot be > unlocked if one operator is incapacitated. So in any case there is a > tradeoff. Sure, and there's a nice algorithm for this: secret sharing. I know only the one by Shamir, which is quite easy to implement and proven do it its job perfectly. But I don't know if there's a disc encryption software integrating a key sharing algorithm. > > That sounds way too casual. How are you going to erase old keys from > > the USB stick when you are done with them? Doesn't this belong to the wide class of problems solvable by a sledge hammer? |