[ ... ] >> The questions you ask sound like homework, [ ... ] not the sort of >> questions one would ask out of a genuine desire to understand the >> issues. tacron> Incorrect. You would say that, wouldn't you? :-) For example, consider among several other obvious hints the lack of personal identification on your email address, which might suggest to the cynical :-) a desire not to be caught out soliciting ``assistance''. However, I will try to pretend that I believe your bare "incorrect" statement and be more patient and provide some detailed exposition of the complexities I perceive and that you maybe can't be asked to worry about. But please double check with your friendly neighbourhood professional cryptanalist anything I write because I am just an interested spectator, and I am neither a criptographer nor a cryptanalyst, and just about the only thing I really know about the subject is that it is far more subtle than I think I know. :-) [ ... ] >> "automatically mean" is a meaningless sequence of words. Perhaps that >> should have been written "necessarily mean", but if so then it is >> still pretty pointless because ``security'' is a matter of judgement, >> not logical necessity. tacron> bla bla It's not "bla bla", for me it is very the essence of the discussion. I reckon that: ``Security'' is not an automatic consequence of how many/which features, it is a complex story. Bauer in his cryptanalysis book argues that the Enigma machine, especially as updated, was unbreakable at the time. But its users were sloppy. And sometimes more features mean less ``security''. ``Security'' can only be estimated semi-reliably by professional cryptanalysts and given a cryptosystem architecture and a threat model; a disk encryption scheme is a mere component of a cryptosystem, (of which you give very few details) and I haven't noticed any mention of a threat model either. ``Security'' is intimately related to cost: both the cryptosystem architecture and threat model must included expected budgets for protection and attack vs. the value of preventing or achieving a breach. Without mention of money values even having a cryptosystem architecture and threat models is not that useful. Analogies are usually bad, but consider the meanignfulness of questions like: ``Does an engine with six cylinders automatically mean that it is more reliable than an engine with four cylinders concerning this point?''. ``Is a CPU with 250 instructions always more powerful than a CPU with 110 instructions as far as this point is concerned?'' >> Also, and more importantly, any question like "more secure" at this >> level of detail is ridiculous without a detailed threat model and lots >> of pretty formal work, or a team of professional cryptanalists checking >> it out. tacron> Could you please answer the question? Sorry, my guess is that the question is pointless/unanswerable. This guess in itself may convey valuable information, but hey, that's just my delusion, you are welcome to recoil from sharing it. For me your insistence for an answer reinforces my other delusion that your questions are "not the sort of questions one would ask out of a genuine desire to understand the issues." Perhaps this is also because of my occasional feeling that you only care to get a definite answer to an otherwise pointless question because your teacher does award points to it in marking your essay (``Does the use of 64 vs. 17 keys by itself mean that it is more secure other things being equal? Answer yes or no, correct answer worth 15 points''); if so perhaps he can't be asked to understand the depth of the subject he teaches, or just cynical about teaching. So, not only I reckon that questions about "more secure" based on details like the number of keys are just pointless without a statement of the expected threats and the cryptosystem architecture; some people may even think that having many subkeys is barely useful; it may even be regarded to be a risk, never mind the specific number of keys. Consider this argument, which is not necessarily good, but to me seems to have some merit in some cases: having many keys, no matter whether 17 or 64, means that probably they cannot be easily memorized. If they cannot, they have to be stored _somewhere_, encrypted with a key that has to be memorized (all this said with a particular but obvious family of cryptosystem architectures in mind). Does this improve or reduce ``security'' whatever that is? It's not so obvious, and may depend quite a bit on the threat model, because it seems to me that it trades off some data crypto hazards for some key management hazards. Maybe if you have a single not too complex key you can just hold it in your head. Given that some plausible threat models are mostly about key management mishaps, this might be more ``secure'' than storing the vector of real encryption keys somewhere outside your head, and keeping in your head just the passphrase with which you encrypt that. Then there are counterarguments, like that you can/should put the keys well separated from the data (as part of your original question), but this creates different key management hazards, and so on. Then there are countercounterarguments; for example that if a key is only in your head you know for sure at least some cases when it has been revealed, because you did it, but then there are keyboard loggers that mean you may have revealed the key without realizing it, and so on. Again, it all depends on the threat model and the cryptosystem architecture. [ ... ] tacron> I speculate that PPDD has no significant problems with using tacron> Blowfish and the 64bit blocksize because this becomes only a tacron> problem when encrypting every sector with a single key. >> Good for you that you enjoy speculating about such matters. tacron> Thx :P Glad for the appreciation. However I'll now comment on your enjoyable speculation, just to illustrate why it seems a bit fanciful to me, in particular this bare premise: tacron> becomes only a problem when encrypting every sector with a tacron> single key. This statement seems to me to be based on the assumption that what is relevant is block size vs. *percentage* (100% vs. 5.9% or 1.5% or ..., depending on the number of keys) instead of absolute quantity (and likelyhood of known plaintext in it) of ciphertext potentially available to an adversary. I also wonder if it wouldn't be more useful to worry about key size instead of block size wrt to percentage or absolute amount of ciphertext. If encrypting an 80GB partition with something like 17 keys, the adversary might get almost 5GB of ciphertext per key (some of which may be known plaintext), and perhaps that is still a bit of a concern with 64 bit blocks (or should one worry about key size rather than the block size?), _if_ the block size should be related to the absolute amount of ciphertext one expects the adversary to be able to get, not its percentage. To my untrained eye it would seem more worthwhile to fancy speculating about absolute amount of data encrypted per key vs. key size, rather than percentage of data encrypted per key vs. block size, but you seem happier to speculate about the latter. More generally, it seems to me that one of the challenges with disk encryption schemes is the large amount, especially compared to many other uses of encryption, of ciphertext produced with the same key (and the high likelyhood some of it corresponds to known plaintext) that might fall into the hands of the adversary. This may be a worry, not just because cryptanalysis may be easier (I guess wildly here) but also because the consequence of a breach may be wide. AFAIK for encryption of communication channels keys are often automatically renegotiated every X bytes and/or Y milliseconds, and this looks to me to be pretty hard to do for a disk with anything like the same spatial or temporal frequency. But I am digressing from happy speculations about block sizes and percentage of ciphertext. :-) tacron> PPDD uses this whitening process, to keep the IVs secret. Is tacron> there any match in Loop-AES? >> I suspect that the purpose of whitening in PPDD is not really about >> keeping the IVs secret. [ ... whitening is about spreading data ... ] >> http://mail.NL.Linux.org/linux-crypto/2003-05/msg00079.html tacron> Really? "On 20010920 (Thu) at 1114:48 +0200, Allan Latham tacron> wrote: [..] alatham> PPDD "scrambles" the whole of a 512 byte block before alatham> encryption in such a way that the iv for this action is kept alatham> secret in the same way as the encryption keys and that the alatham> scrambling action diffuses a change in any one byte alatham> throughout the block. My suspicions involve also a misreading of this sentence: to me it states that the IV keys for whitening are kept secret _before_ scrambling, "in the same way as the encryption keys" are kept secret, which is described as follows: http://Koeln.CCC.DE/archiv/drt/crypto/ppdd.Specification.txt «The key for the 1024 byte block is derived from the pass phrase and is used to encrypt most of this block in ecb mode. In the encrypted part of the block are the keys for the database and iv data needed for the encryption process.» Which sounds to me not quite like "uses this whitening process, to keep the IVs secret". The opposite seems more applicable to me: whitening _uses_ the IVs kept secret by the control block passphrase. It is also said explicitly that the purpose of whitening is to frustrate before/after analysis here (and see below too): alatham> If an attacker gets a "before" and "after" copy he can see alatham> that a 512 byte block has changed but has no idea where in alatham> the block the change took place. The scrambling seems to be just just a _data_ block superencryption scheme, rather unrelated to the a goal like "to keep the IVs secret" (the IVs are _metadata_). tacron> http://mail.nl.linux.org/linux-crypto/2001-09/msg00063.html That the purpose of whitening it to frustrate before/after analysis is also what I misunderstand from this other detailed description: http://Koeln.CCC.DE/archiv/drt/crypto/ppdd.Specification.txt «This process requires an IV and this is derived from the block number and from a table of IVs held in the control block. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The whitening process also provides an IV which is used in the cbc encryption of the block using a key from the control block. The control block contains 17 keys and 61 random 4 byte IVs. The key used on a block is derived by dividing the block number by 17 and using the remainder as a subscript to the key array. The whitening IVs are the block number itself and the IVs from the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ control block derived by dividing the block number by 59 and 61 ^^^^^^^^^^^^^ and using these remainders and using these as subscripts. The result is that no block is encrypted the same way. Also any change in the data in a block results in a completely different 512 byte block after encryption.» Now, let's assume for a moment for the sake of argument that PPDD "uses this whitening process, to keep the IVs secret": then, which IVs does whitening "keep secret"? Also, if the IVs are kept secret somewhere, where? Neither is so obvious to me. My impression is that the IVs whitening uses are "derived" from the 61-IV vector in the control block, and those are not in any way subject to whitening. The "key used in the block" is also selected from the 17-key vector in the control block, and that is also kept secret by the passphrase. As to where, in data blocks there is no space to store the IVs, and in the control block they are kept secret by the passphrase. Misteries of the whitening masters! :-) In passing, note the innocence of the author when he concludes that thanks to this particular superencryption scheme: «[ ... ] the scrambling action diffuses a change in any one byte throughout the block.» «Also any change in the data in a block results in a completely different 512 byte block after encryption.» Amazing claims! :-) I am also rather perplexed that whitening «"scrambles" the whole of a 512 byte block before encryption» instead of *after* encryption. [ ... ] >> It would have been nice if you had found the time to read _carefully_ >> the paper that describes PPDD, the loop-AES documentation, and the >> sources, and some web discussions about these subjects... tacron> I did. You would say that, of course, and yes, yes, I believe that and in the tooth fairy :-) and also that you are not just trying to scrounge some quick'n'dirty stuff to cut and paste in your assignment. :-) Yours statements above suggest to me that you may have read (perhaps belatedly) something about whitening, but that it must have been a very superficial read, because despite the fairly clear and repeated statements that the purpose of whitening is to frustrate some sort of before/after analysis even _in the quote you provide_, you only mentioned as its purpose to keep some IVs secret. But reading carelessly is not the only problem I imagine; to me it seems pretty likely that you never bothered to read the loop-AES documentation or its sources, because you seemed quite unaware that since 2002 (according to the 'ChangeLog') the loop-AES driver supports iterations, or that it does not use any random number generator itself. To me it seems fairly funny that you are trying to compare loop-AES with PPDD without apparently reading their documentation or sources with care if at all, or else it's the attitude of a lazy guy that just wants to make his term paper with minimum cut-and-paste effort. :-) tacron> But saying that A has feature x and B has feature y is different tacron> from evaluating the overall impact of x and y on the strength of tacron> A and B respectively. Ahhhh, but you asked questions like "automatically means" ... "more secure" as to a detail like 17 vs. 64 keys. Even if just as "concerning this point" that seems to be a bit more ambitious than listing features, assuming one gets the features right. tacron> Of course I can eavaluate different aspects of encryption tacron> systems separately by going through the literature If only it were so easy! And "evaluate" is not the same as ``list''. tacron> and saying: this system uses a secure hash transform and this tacron> system none at all, Serpent's security margin is widely seen to tacron> be more comfortable than the one of AES etc. Consider performance, another slippery subject: at least one can say it is measured in ``somethings'' per unit of time. One can argue about the ``somethings'', and one can argue about how to measure them, but it is pretty obvious (absolute) performance should be a ``speed''. For ``security'' I cannot even imagine in what units it is expressed; and some people even think it is process and not a quantity. Even making a list of features probably does not help a lot, and making an inaccurate list without reading carefully or at all some of the relevant docs or sources may help very little. tacron> But when it comes to evaluating the overall security of a disk tacron> encryption system, I leave that to crypto experts I hoped to tacron> find here. Unlucky! Most of those people work for the ``good'' (or ``bad'') guys, and poor spectators like me can just offer some cautionary warnings to the lazy :-). Then I suspect that any "crypto experts" would be pretty reluctant to indulge your wildly speculative imagination by "evaluating the overall security" of anything outside decently specified terms of reference (cryptosystem architecture, threat model, budgets), but I have never even talked with one (not that I would know even if I did, as Bauer says it is very dangerous for a professional cryptanalyst to be known as such). Also, have you ever read Eco's novel "Foucault's pendulum"? It says that the number one rule among occultists (includign apprentice sorcerers) is like ``Those who claim they know, don't, and those who claim they don't know, do''. :-) For cryptanalysts it is more like ``Those who talk don't know, those who know don't talk''. Note that I am talking a lot. :-) But then most definitely I am not a cryptanalyst or a "crypto expert"; I have never even tried to solve a decryption problem in a puzzle magazine on a train trip, it just bores me (like crosswords, etc.). tacron> I'll have to wait for Halcrow's paper on Linux symposium (though tacron> he probably won't evaluate PPDD). Perhaps, but even evaluating the _details_ of a disk encryption scheme is not trivial (consider the above discussion of the merits of having multiple keys vs. one key), because even the details can be more ``secure'' (whatever that means) under some threat model and not under others, and in what kind of cryptosystem architecture the disk encryptor is embedded. >From the description of his talk: http://WWW.LinuxSymposium.org/2004/view_abstract.php?content_key=55 it seems he will be reasonably just do "a survey of filesystem security options", quite a bit more doable than evaluating ``security'' as in: tacron> I'd like to know how Loop-AES (used with mulitkey mode, key tacron> stored on external media, root directory encrypted and booting tacron> from CD-ROM) and PPDD compare in terms of security. Could this poor Halcrow guy foretell which cryptosystems and threats and budgets are involved in most/every case? Do you? :-) However, let me add here a personal call of judgement: I like loop-AES, in large part because I have read Jari Ruusu docs and occasional comments and I like his judgement because he seems to think things through, and this gives me confidence that he does his homework, is aware of the existence of limitations and oblique risks, and tries to fix or avoid trouble. For me the cost of cryptosystem architecture/threat model/cost estimates and hiring a team of professional cryptanlysts wildly exceeds the possible cost of really making sure nobody can read my email :-), and so I use the crude proxy of trusting the judgement of the author as tacron> Nevertheless thx for the informative part of your (educational) tacron> pamphlet :D Thanks for the appreciation! - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
