`Christophe Saout writes:> IV = sector number (little endian, 32 bits), pad with zeroes> The actual content is then encoded using the selected cipher and key in> CBC mode.> C[0] = E(IV     xor P[0])> C[1] = E(C[0]   xor P[1])> ...Ok, that's what I thought.  The above is pretty good, but does have someweaknesses due to the IV selection.  CBC mode needs uniformly random IVsfor security; using a counter can cause occasional information leakage.1) Accidental leakage can happen, if you're a little unlucky.  Supposewe have two sectors, numbered S and S' and with content P and P'(respectively).  Check out what happens if the first block of sectorcontents are related by P[0] xor P'[0] = S xor S': in this case (andonly this case), we have C[0] = C'[0].  Notice that an attacker canrecognize when this happens by just looking for a pair of sectorswhose ciphertexts start with the same block.  If he finds a pair ofsectors like this, he will be able to deduce the value P[0] xor P'[0](since sector numbers are known), and depending on data formats, thismight reveal relevant information about the corresponding plaintexts.So if you're unlucky and two plaintexts are related in a special way,some partial information can leak.  You have to ask how likely it will bethat this special relation will occur.  The answer depends on the formatof plaintexts.  If the first block of plaintexts are totally random,then this relationship essentially never occurs (it has probability1/2^128 for any pair of sectors, a truly negligible chance).But, if blocks have some special formatting that makes them highlynon-random, the chance of information leakage can go up significantly.For instance, suppose the first block of our data always containsa 24-bit counter, little endian and padded with zeros, and supposewe have a disk with 2^24 sectors (64 GB disk?).  Then the probabilityof a special relationship between any pair of disk sectors is 1/2^24.If 2^20 of the sectors hold data of this format, then we expect to findabout 2^20*(2^20 - 1)/2 * 1/2^24 ~= 2^15 pairs of sectors with thisspecial relationship.  In other words, there are about 2^15 pairs ofsectors where some partial information leaks to the attacker.You can see that the information leakage is typically modest and limited;in many cases, there might be no leakage at all.  Nonetheless, this isnot an ideal situation.  As a cryptographer, one would usually considerthis a flawed design (primarily because it is so easy to do better).There are known ways to prevent this attack; for instance, IV = E(sectornumber) or IV = HMAC(sector number) should be much better.2) Intentional leakage can happen, if the attacker can exert any influenceover the data you store on your disk.  If I remember correctly, I thinkthis is M.J. Saarinen's scenario: the attacker specially chooses thecontents of your disk sectors to increase the probability of informationleakage (as described above), the attacker can arrange for this leakageto occur with very high probability.  In the watermarking attack, theattacker uses the absence/presence of leakage to determine whether yourdisk contains a copy of his watermarked file.The above analysis is only directed towards the threat model where theattacker gets physical access to your hard disk once, and you never seeit again.  For instance, think of someone who steals your laptop and thenwants to read what's on your hard drive.  I ignored scenarios where theattacker gets repeated access to your hard disk and can see what's storedon it each time -- e.g., the janitor pokes around inside your machineevery night at midnight.  I also ignored scenarios where the attackergets access to your hard disk, makes some changes to the ciphertext,and then you continue using the machine afterwards.  There is a big pileof devastating attacks in these more sophisticated threat models, andit would be prudent to assume that the current scheme might be totallyinsecure in such scenarios.  I can say more if you want, but I suspectthe current scheme wasn't designed for security against repeated oractive attacks.I also didn't look at key management -- e.g., how keys are generated(passwords?), derived, stored, and destroyed (do they end up on swapinadvertently?).  Be aware that this is another big potential sourceof vulnerabilities.I hope this helps get you started.  Sorry that I know nothing aboutcryptoloop or dm-crypt; thanks for showing me the basic mode of operationthey use.  Feel free to let me know if you want to know more about anyaspect of this problem.> Also see: http://clemens.endorphin.org/OnTheProblemsOfCryptoloopThe reasoning on that web page looks pretty confused to me.  It looksto me like the author of that page does not understand cryptographyvery well.  The author tries to calculate the probability of a specialrelationship between sectors, but overlooks the possibility that datamight be formatted in a way that increases this probability.  This ispretty basic, standard stuff in the crypto world, to be honest, so thiskind of mistake is not encouraging.-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`