TrueCrypt 4.0 Out

68 views
Skip to first unread message

Ari Silversteinn

unread,
Nov 2, 2005, 12:05:47 PM11/2/05
to
http://www.truecrypt.org/
--
Drop the alphabet for email
Message has been deleted
Message has been deleted
Message has been deleted

Luc The Perverse

unread,
Nov 2, 2005, 8:00:42 PM11/2/05
to
"traveler" <nor...@nym.alias.net> wrote in message
news:7qmim19i2khbugf4c...@4ax.com...
> On Wed, 2 Nov 2005 12:05:47 -0500, Ari Silversteinn
> <arisilv...@yahoo.com> wrote:
>
>>http://www.truecrypt.org/
>
> As someone who knows very little about disk encryption, I'm
> just wondering how good can a program like this can be? The last
> release was just over half a meg in size, can they build a truly
> dependable and secure program at that size?

With native libraries, and encryption algorithms being very very simple, you
should be able to write one far smaller than that size!

--
LTP

:)


clark

unread,
Nov 2, 2005, 11:51:33 PM11/2/05
to
On Wed, 02 Nov 2005 16:38:23 -0800, traveler <nor...@nym.alias.net>
wrote:

>On Wed, 2 Nov 2005 12:05:47 -0500, Ari Silversteinn
><arisilv...@yahoo.com> wrote:
>
>>http://www.truecrypt.org/
>
>As someone who knows very little about disk encryption, I'm
>just wondering how good can a program like this can be? The last
>release was just over half a meg in size, can they build a truly
>dependable and secure program at that size?

Yes they can.

They just have a different paradigm for writing software than most of
the bloatware you are used to seeing.

This is a known-to-be-good disk crypto product that is based on (but
improves on) an older known-to-be-good disk crypto product called E4M.


tomst...@gmail.com

unread,
Nov 3, 2005, 12:13:51 AM11/3/05
to

clark wrote:
> On Wed, 02 Nov 2005 16:38:23 -0800, traveler <nor...@nym.alias.net>
> wrote:
>
> >On Wed, 2 Nov 2005 12:05:47 -0500, Ari Silversteinn
> ><arisilv...@yahoo.com> wrote:
> >
> >>http://www.truecrypt.org/
> >
> >As someone who knows very little about disk encryption, I'm
> >just wondering how good can a program like this can be? The last
> >release was just over half a meg in size, can they build a truly
> >dependable and secure program at that size?
>
> Yes they can.
>
> They just have a different paradigm for writing software than most of
> the bloatware you are used to seeing.

Which is odd because portable crypto libraries exist. There is no
reason why they couldn't just link against them instead of munging
crypto routines from a dozen authors.

I'm not saying the program is insecure [I'm also not saying it's
secure] but it seems they have a total miss of priorities. There are
source files that are NOT tables and over 100KB in size. They use
inconsistent coding style and indentation [mostly because they lifted
code from everywhere] and they also employ the magical "multiple cipher
passes" modes of operation.

If they were serious about security they would worry less about the
number of passes with different ciphers they utilize and more about the
quality of the code that implements their system.

Tom

Message has been deleted

Kristian Gjųsteen

unread,
Nov 3, 2005, 3:19:52 AM11/3/05
to
clark <cl...@barbell.com> wrote:
>This is a known-to-be-good disk crypto product that is based on (but
>improves on) an older known-to-be-good disk crypto product called E4M.

Here's a possible usage scenario and attack on TrueCrypt. The problem
this exploits is that (as far as I could determine from the
documentation) IV's for CBC-mode are derived simply as the xor of
a secret value and the sector index. This means that the difference
between the IV's for two different sectors is predictable by an
attacker.

Note that this is based on a brief look at the documentation, I
have not looked at the source code. But it should be easy to verify
this in practice. TrueCrypt doesn't run on any machine I have access
to, so I cannot verify it. (For all I know, the attack has been
pointed out before.)

Suppose Alice wants to steal some data from Bob. She plans to put
the data in a TrueCrypt container, so that if she is caught, she
will claim that she has forgotten the passphrase and nobody should
be able to prove that the stolen data is inside the container.

If Bob is able to insert certain patterns inside the data that Alice
steals, these patterns will show up in the ciphertext TrueCrypt
produces.

Example pattern: Assume 128 bit/16 byte block size, and consecutive
sectors, first sector on an even index. Then because of the way the
IV's are derived, the difference between the IV's for the two sectors
is going to be 0x0000000000010000000000000001 (if I counted correctly).
If Bob in his data inserts two sectors where the first two blocks
differ by exactly this difference, the first block of the ciphertext
will be the same. By continuing with plaintext blocks that are the
same for some distance, then different, Bob can create a very special
pattern in the ciphertext that is unlikely to occur randomly.

How do we create such patterns? If the data is source code, suitably
aligned comments should work:

/* NB! 2:20051114 This should be looked into. */

/* NB! 3:20051115 This must be looked into. */

By creating many such patterns in his data, Bob can argue convincingly
that the TrueCrypt container does contain his data, without knowing
Alice's passphrase.

(Note: I haven't checked if this attack works with some of the
composed-cipher modes.)

Such attacks are well-known, I see that people who write disk
encryption programs call them "watermarking attacks". Disk encryption
programs should protect against them, and it is easy to protect
against them. FreeBSD's gdbe and geli do this. It is possible to
convince linux loopaes to do this as well.

This means that TrueCrypt should not be considered a "known-to-be-good"
product, but a "thought-to-be-defective" product. If someone confirms
that my attack works, its status will be "known-to-be-defective".
If it turns out that I misread the documentation, it should be
considered a "may-be-good" product until someone has had a serious
look at the product.

--
Kristian Gjųsteen

Kristian Gjųsteen

unread,
Nov 3, 2005, 3:32:35 AM11/3/05
to
Sebastian Gottschalk <se...@seppig.de> wrote:
>So far, TwoFish is broken.

Is it TrueCrypt's implementation of TwoFish that is broken, or the
block cipher itself?

If the latter, would you mind documenting it?

--
Kristian Gjųsteen

clark

unread,
Nov 3, 2005, 3:38:12 AM11/3/05
to
On 2 Nov 2005 21:13:51 -0800, tomst...@gmail.com wrote:

>
>clark wrote:
>> On Wed, 02 Nov 2005 16:38:23 -0800, traveler <nor...@nym.alias.net>
>> wrote:
>>
>> >On Wed, 2 Nov 2005 12:05:47 -0500, Ari Silversteinn
>> ><arisilv...@yahoo.com> wrote:
>> >
>> >>http://www.truecrypt.org/
>> >
>> >As someone who knows very little about disk encryption, I'm
>> >just wondering how good can a program like this can be? The last
>> >release was just over half a meg in size, can they build a truly
>> >dependable and secure program at that size?
>>
>> Yes they can.
>>
>> They just have a different paradigm for writing software than most of
>> the bloatware you are used to seeing.
>
>Which is odd because portable crypto libraries exist. There is no
>reason why they couldn't just link against them instead of munging
>crypto routines from a dozen authors.

That is a lame, self-serving statement.

These are some of the authors:

Paul Le Roux
Eric Young
Dr. Brian Gladman
Markus Friedl

I don't see anyone in that list that I wouldn't trust at least ten
times more than, say, some fat assed blabbermouth who is almost unable
to make a post that doesn't reference his own work as being brilliant
while denigrating everyone else's products and efforts.

>
>I'm not saying the program is insecure [I'm also not saying it's
>secure]

Whatever it is your saying, it has a near 100% likelyhood of devaluing
someone else's work and harping your own.

> but it seems they have a total miss of priorities.

Really? A total miss? Then you must be an idiot.

The product stands on its own as one of the best disk encryption
products that can be obtained anywhere.

It is well written. Works very well and is stable. It is free to
anyone who wishes to use it under Windows or Linux.

There are other products that will encrypt the entire disk including
the OS, but for partition and container (virtual disk) encryption the
TrueCrypt product is a decent and trustworthy piece of software.

And it has its roots in another well-known disk encryption product
that was called Encryption for the Masses or E4M. It is a worthy
successor.

Are you physically unable to recognize anyone else's accomplishments
except your own?

> There are
>source files that are NOT tables and over 100KB in size. They use
>inconsistent coding style and indentation [mostly because they lifted
>code from everywhere] and they also employ the magical "multiple cipher
>passes" modes of operation.

Yeah. They lifted code from Dr. Brian Gladman and Eric Young.

Hmmmm. Sounds like they knew what they were doing.

>
>If they were serious about security

You pompous fat drooling coward.

> they would worry less about the
>number of passes with different ciphers they utilize and more about the
>quality of the code that implements their system.

Then why don't you shut your big fat mouth and write an interface
around LTM that will implement stable and secure, easy to use disk
encryption?

Why don't you do that instead of lying about a good product?

You take a coward's position.

TrueCrypt is a good product written on solid principles and it works
well. And it is free for anyone who needs to secure their data.

It is easy to use. It works on Windows 2000/XP/2003 32/64-bit.

It is ported to some major versions of Linux and you can make the
version from source for other flavors.

The source code is published and free for download and analysis.

TrueCrypt has MOST, if not all, the things that you want in a disk
encryption product.

And for some big-mouthed fat-assed group coward to say otherwise,
without giving any reasonable cause is lame.

And I'll tell more truth: Eric Young's and Dr. Brian Gladman's code
are fielded MANY times more often than a certain sci.crypt blowhard's
precious library and there are many good reasons for that.

Most of the reasons are technically-based.

But some of them likely have more to do with him being an asshole then
for technical reasons.

David Wagner

unread,
Nov 3, 2005, 3:59:51 AM11/3/05
to
Sebastian Gottschalk wrote:
>So far, TwoFish is broken.

???

Can you elaborate?

clark

unread,
Nov 3, 2005, 4:23:38 AM11/3/05
to
On Thu, 3 Nov 2005 09:19:52 +0100, Kristian Gjųsteen
<kristi...@item.ntnu.no> wrote:

[...]


>
>(Note: I haven't checked if this attack works with some of the
>composed-cipher modes.)
>

[...]

It doesn't sound like you've checked anything at all.

Maybe I missed something.

I've got a suggestion. Why don't you elaborate with facts or examples
instead of guessing?

That would be interesting.


clark

unread,
Nov 3, 2005, 4:55:26 AM11/3/05
to
Please give a concrete example of why TrueCrypt is not well-made

Here is some documentation (taken from User Guide)

For the example we'll use AES-256 w/CBC

algorithm=AES-256 mode=CBC

Ci = EK(Pi ^ Ci - 1); C0 is IV.

IV (initialisation vector) is a random value (unknown to adversary),
which is unique to each sector* and volume. This value is generated as
follows:

1. Bytes 256-263 (for a 128-bit block cipher, bytes 256-271) of the
decrypted volume header are retrieved (see the sections TrueCrypt
Volume Format Specification and Encryption Scheme).

2. Data retrieved in (1) are XORed with the 64-bit sector number (each
sector is 512 bytes long; sectors are numbered starting at 0). In case
of a 128-bit block cipher, the upper and lower 64-bit words of the
128-bit value retrieved in (1) are XORed with an identical value. The
resultant 64-bit value (or 128-bit value for 128-bit block ciphers) is
the IV.

i.e.,
For a 128-bit block cipher:
T1 = upper 64-bit word of the value retrieved in (1)
T2 = lower 64-bit word of the value retrieved in (1)
S = sector number (64-bit integer)
IV = (T1 ^ S) || (T2 ^ S)

For a 64-bit block cipher:
T = 64-bit value retrieved in (1)
S = sector number (64-bit unsigned integer)
IV = T ^ S

Note: Step (1) is only performed once, right after the volume is
mounted. Then the retrieved data remain in (non-swappable) RAM.

Ciphers in a cascade use mutually independent keys (note that the
header keys they use are independent as well, even though they are
derived from one password – see Header Key Derivation, Salt, and
Iteration Count).

Whitening

To make obtaining a plaintext/ciphertext pair more difficult [16], the
following technique, similar to one that is sometimes called
whitening, is applied: Every eight bytes of each sector (after the
sector is encrypted) are XORed with a 64-bit value, which is unique to
each sector and volume (and is unknown to an adversary). The value is
generated as follows:

1. Bytes 264-271 (for a 128-bit block cipher, bytes 272-279) of the
decrypted volume header
are retrieved† (see TrueCrypt Volume Format Specification and
Encryption Scheme).

* Each sector is 512 bytes long; sectors are numbered starting at 0.

† All necessary data are retrieved from the volume header right after
the volume is mounted, and they remain in (non-swappable) RAM until
the volume is dismounted.

2. Bytes 272-279 (for a 128-bit block cipher, bytes 280-287) of the
decrypted volume header are retrieved.

3. Data retrieved in (1) are XORed with the 64-bit sector number (each
sector is 512 bytes long; sectors are numbered starting at 0).

4. Data retrieved in (2) are XORed with the 64-bit sector number.

5. A 32-bit CRC-32 value of the first eight bytes of the resultant
value in (3) is calculated.

6. A 32-bit CRC-32 value of the second eight bytes of the resultant
value in (3) is calculated.

7. A 32-bit CRC-32 value of the first eight bytes of the resultant
value in (4) is calculated.

8. A 32-bit CRC-32 value of the second eight bytes of the resultant
value in (4) is calculated.

9. The value calculated in (5) is XORed with the value calculated in
(8).

10. The value calculated in (6) is XORed with the value calculated in
(7).

11. The 32-bit value calculated in (9) is written to the upper 32-bit
word and the value calculated in (10) is written to the lower 32-bit
word of the 64-bit whitening value. Remark: Steps 5-8 are performed to
increase the Hamming distance between individual whitening values.

Summary:
T1 = 64-bit value retrieved in (1)
T2 = 64-bit value retrieved in (2)
S = sector number (64-bit unsigned integer)
T1 = T1 ^ S
T2 = T2 ^ S
Q1 = upper 32-bit word of T1
Q2 = lower 32-bit word of T1
Q3 = upper 32-bit word of T2
Q4 = lower 32-bit word of T2
W = (CRC32(Q1) ^ CRC32(Q4)) || (CRC32(Q2) ^ CRC32(Q3))
Actual whitening is applied as follows:
For a 128-bit block cipher:
T1 = upper 64-bit word of C
T2 = lower 64-bit word of C
C’ = (T1 ^ W) || (T2 ^ W)
For a 64-bit block cipher:
C’ = C ^ W

Header Key Derivation, Salt, and Iteration Count

Header key is used to decrypt the encrypted area of the TrueCrypt
volume header (see the sections Encryption Scheme and TrueCrypt Volume
Format Specification). The technique that TrueCrypt uses to generate
header keys is PBKDF2, specified in PKCS #5 v2.0; see [7] (the PKCS #5
v2.0 document is also available at:
http://www.truecrypt.org/docs/pkcs5v2-0.pdf).

512-bit salt (random values generated using the built-in random number
generator during the volume creation process) is used, which means
there are 2512 keys for each password. This significantly decreases
vulnerability to 'off-line' dictionary attacks (pre-computing all the
keys for a dictionary of passwords is very difficult when a salt is
used) [7]. The header key derivation function is based on either
HMAC-RIPEMD-160, or HMAC-Whirlpool, or HMAC-SHA-1 (see [8, 9, 20,
22]) – the user selects which. The length of the derived key does not
depend on the size of the output of the underlying hash function
(e.g.., header key for the AES-256 cipher is always 256 bits long,
even if HMAC-SHA-1 or HMAC-RIPEMD-160 is used). For more information,
refer to [7].

Two thousand iterations (or one thousand iterations when
HMAC-Whirlpool is used as the underlying hash function) of the key
derivation function have to be performed to derive a header key, which
increases the time necessary to perform an exhaustive search for
passwords (i.e., brute force attack) [7].

Header keys used by ciphers in a cascade are mutually independent,
even though they are derived from one password. For example, for the
AES-Twofish-Serpent cascade, the header key derivation function is
instructed to derive a 768-bit key from a given password. The
generated key is then split into three 256-bit keys, out of which the
first key is used by Serpent, the second key is used by Twofish, and
the third by AES. Hence, even when an adversary has one of the keys,
he cannot use it to derive the other keys, as there is no feasible
method to determine the password from which the key was derived
(except for brute force attack mounted on a weak password).


Kristian Gjųsteen

unread,
Nov 3, 2005, 5:21:52 AM11/3/05
to

I forgot the whitening. The documentation isn't too clear: is the
whitening applied on a block-by-block basis after the block has
passed through the block cipher, or is the whitening applied after
the entire sector has been encrypted in CBC mode? Or is something
else happening?

I'll assume the first option. After the first plaintext block xored
with the IV has been encrypted, the ciphertext is xored with a given
whitening value that is (again as far as I could determine) computed
as a linear function of the sector index and a secret value.

I can ensure as described above that the first block of sectors 4i,
4i+1, 4i+2, 4i+3 all encrypt to the same ciphertext block before
whitening. The difference between what is written to disk at sector
4i and 4i+1 is then the difference of the two whitening values, and
this is just the linear function applied to the difference, and the
only difference is that of the sector numbers, which is known. The
same argument applies to sectors 4i+2 and 4i+3, so the difference
between sectors 4i and 4i+1 should be the same as the difference
between sectors 4i+2 and 4i+3.

>How do we create such patterns? If the data is source code, suitably
>aligned comments should work:
>
>/* NB! 2:20051114 This should be looked into. */
>
>/* NB! 3:20051115 This must be looked into. */
>
>By creating many such patterns in his data, Bob can argue convincingly
>that the TrueCrypt container does contain his data, without knowing
>Alice's passphrase.
>
>(Note: I haven't checked if this attack works with some of the
>composed-cipher modes.)

Let me turn that into a positive insted: As far as I can determine,
this will work when AES is the cipher used.

Kristian Gjųsteen

unread,
Nov 3, 2005, 5:33:26 AM11/3/05
to
clark <cl...@barbell.com> wrote:
>Please give a concrete example of why TrueCrypt is not well-made
>
>Here is some documentation (taken from User Guide)

This is available from TrueCrypt's web-site. (And to be fair, this
much technical documentation is infinitely more than what is provided
with other products. This is in my opinion a clear plus for the
TrueCrypt!)

>For the example we'll use AES-256 w/CBC
>
>algorithm=AES-256 mode=CBC
>
>Ci = EK(Pi ^ Ci - 1); C0 is IV.
>
>IV (initialisation vector) is a random value (unknown to adversary),
>which is unique to each sector* and volume. This value is generated as
>follows:

CBC mode requires an unpredictable IV to be secure, not just a
secret and unique IV. I can predict the difference between the IVs
of sector 2i and sector 2i+1, and that is a problem with CBC mode.

One amusing fact is that counter mode would be secure (in a certain
sense) with this IV derivation scheme!

>For a 128-bit block cipher:
>T1 = upper 64-bit word of the value retrieved in (1)
>T2 = lower 64-bit word of the value retrieved in (1)
>S = sector number (64-bit integer)
>IV = (T1 ^ S) || (T2 ^ S)

A sensible way to do this would be to say:

IV = SHA-256(T1||T2||S) truncated to correct length.

This (or equivalent stuff) is done by e.g. FreeBSD's geli and Linux'
loopaes (when in the proper mode).

>Whitening
>
>To make obtaining a plaintext/ciphertext pair more difficult [16], the
>following technique, similar to one that is sometimes called
>whitening, is applied: Every eight bytes of each sector (after the
>sector is encrypted) are XORed with a 64-bit value, which is unique to
>each sector and volume (and is unknown to an adversary). The value is
>generated as follows:

Does this mean that the jth block of the ciphertext written to
disk is the xor of the whitening value and the jth block of the
ciphertext coming out of the CBC mode encryption? Or does it mean
something else?

--
Kristian Gjųsteen

BRG

unread,
Nov 3, 2005, 5:47:32 AM11/3/05
to
tomst...@gmail.com wrote:
> clark wrote:
>> On Wed, 02 Nov 2005 16:38:23 -0800, traveler <nor...@nym.alias.net>
>> wrote:
>>
>>> On Wed, 2 Nov 2005 12:05:47 -0500, Ari Silversteinn
>>> <arisilv...@yahoo.com> wrote:
>>>
>>>> http://www.truecrypt.org/
>>> As someone who knows very little about disk encryption, I'm
>>> just wondering how good can a program like this can be? The last
>>> release was just over half a meg in size, can they build a truly
>>> dependable and secure program at that size?
>> Yes they can.
>>
>> They just have a different paradigm for writing software than most of
>> the bloatware you are used to seeing.
>
> Which is odd because portable crypto libraries exist. There is no
> reason why they couldn't just link against them instead of munging
> crypto routines from a dozen authors.

There are reasons for avoiding cryptograhic libraries in some situations.

Libraries are typically collections of basic algorithms combined with
higher level protocols and code structures in which the library designer
has imposed his or her views on both code and security design.

Those who want to use their own higher level security and code design
philosophies (and are expert enough to do so) will hence often prefer to
bring together individual open source algorithm implementations in which
they have developed a lot of trust rather than rely on a library and
hence become subject to the prejudices of its author.

I am not suggesting libraries should be avoided but simply that you are
wrong to discount the alternative approach used by TrueCrypt. Neither of
these approaches is invariably better than the other.

[snip]

Brian Gladman

Paul Cooper

unread,
Nov 3, 2005, 6:03:34 AM11/3/05
to
On Thu, 3 Nov 2005 09:19:52 +0100, Kristian Gjųsteen
<kristi...@item.ntnu.no> wrote:


>If Bob in his data inserts two sectors where the first two blocks
>differ by exactly this difference, the first block of the ciphertext
>will be the same.

First:

If Bob could insert data to the volume (i.e., encrypt his arbitrary
data using your *secret* key), as your threat model assumes, then you
wouldn't have to use encryption, because he would easily insert a trojan
(key logger, etc.) anything. This threat model just does not make any
sense. There's a difference between disk encryption and network
communication encryption (public key etc.).


However (second):

TrueCrypt applies whitening to the entire sector so you can't get any
plaintext/cipher text pair. It's a very simple mechanism, which prevents
CBC mode exploits. Your "attack" (if you want to call it like that)
does not work.


>By creating many such patterns in his data, Bob can argue convincingly
>that the TrueCrypt container does contain his data, without knowing
>Alice's passphrase.
>

> (Note: I haven't checked if this attack works with some of the
>composed-cipher modes.)

It doesn't work if a cascade of ciphers is used. But it doesn't work
even if a single cipher is used. It doesn't work at all.


Paul Cooper

unread,
Nov 3, 2005, 6:05:53 AM11/3/05
to
On Wed, 02 Nov 2005 16:38:23 -0800, traveler <nor...@nym.alias.net>
wrote:

> The last release was just over half a meg in size

Yes, this realease is about 500 KB bigger. I checked what caused the
increase and fond out that it was the manual, whose size increased by
500 KB.

Paul Cooper

unread,
Nov 3, 2005, 6:37:05 AM11/3/05
to
On Thu, 3 Nov 2005 09:19:52 +0100, Kristian Gjųsteen
<kristi...@item.ntnu.no> wrote:

>Such attacks are well-known, I see that people who write disk
>encryption programs call them "watermarking attacks".

Actually, "watermark" attack is something else.

"Watermark" attack is based on a database of ciphertext blocks resulting
from common known-plaintext blocks being encrypted using a key derived
eg. by doing SHA1(password), which isn't the case with PKCS-5 (which
TrueCrypt uses). The requirement for this attack is also that IVs must
be known. TrueCrypt volumes have secret IVs (unique seed for each
volume). Therefore, "watermark" attack does not work on TrueCrypt
volumes. IIRC, it works on encrypted Linux loop devices.

Kristian Gjųsteen

unread,
Nov 3, 2005, 7:23:02 AM11/3/05
to

Since I'm having a hard time convincing people, let's figure out
where I'm mistaken:

I'm only interested in the first block of each sector, and only when
the cipher is AES. So let E(k, ) denote encryption with AES under key
k, and let P be the first block of the plaintext.

TrueCrypt has three secrets k1, k2 and k3 involved in encrypting this
block, as well as the sector number n.

Define the functions

IV(k,n) = k xor (n||n).

and let W(k,n) be a linear function of n so that

W(k,n1 xor n2) = W(k,n1) xor W(k,n2) .

The first block will be encrypted as

C = E(k1, P xor IV(k2,n)) xor W(k3,n)
= E(k1, P xor k2 xor (n||n)) xor W(k3,n) .

It is my understanding that C as computed above from P,k1,k2,k3 and
n is the first block that gets written to the sector. If this is
correct, then the attack proceeds precisely as below. If I have
misunderstood, I'll be happy to apologize.

Suppose we have four sector indexes n1, n2, n3, n4, such that
n1 xor n2 = n3 xor n4 = X.

We arrange so that the plaintexts 0, X||X, 0, X||X are written to
the sectors at index n1, n2, n3 and n4, respectively.

Then because X||X = n1||n1 xor n2||n2 = n3||n3 xor n4||n4 we get

C1 = E(k1, 0 xor k2 xor (n1||n1)) xor W(k3,n1) ,
C2 = E(k1, X||X xor k2 xor (n2||n2)) xor W(k3,n2)
= E(k1, 0 xor k2 xor (n1||n2)) xor W(k3,n2) ,

C3 = E(k1, 0 xor k2 xor (n3||n3)) xor W(k3,n3) , and
C4 = E(k1, X||X xor k2 xor (n4||n4)) xor W(k3,n4)
= E(k1, 0 xor k2 xor (n3||n3)) xor W(k3,n4) .

Then

C1 xor C2 = W(k3,n1) xor W(k3,n2) = W(k3,n1 xor n2) and
C3 xor C4 = W(k3,n3) xor W(k3,n4) = W(k3,n3 xor n4),

and since n1 xor n2 = n3 xor n4, we get that

C1 xor C2 = C3 xor C4 .

So by choosing the first blocks of sectors that are to be written
at indexes that are related (for example sequential, starting at
an index divisible by 4), I can distinguish encryptions of my
plaintext from encryptions of random plaintexts.

Note that this is easy to verify if the TrueCrypt software is
available.

tomst...@gmail.com

unread,
Nov 3, 2005, 7:59:37 AM11/3/05
to
BRG wrote:
> There are reasons for avoiding cryptograhic libraries in some situations.
>
> Libraries are typically collections of basic algorithms combined with
> higher level protocols and code structures in which the library designer
> has imposed his or her views on both code and security design.

That's a bit infantile. Libraries like OpenSSL allow you to have
direct access to the crypto primitives. If you don't like the SSL
protocol you don't have to use it. You can still use the crypto
though.

> Those who want to use their own higher level security and code design
> philosophies (and are expert enough to do so) will hence often prefer to
> bring together individual open source algorithm implementations in which
> they have developed a lot of trust rather than rely on a library and
> hence become subject to the prejudices of its author.

I don't see the benefit. Different authors have different coding
styles, interfaces, etc. Bringing dozens of random pieces of code
together only means you have to work the source code so that they're
uniform. And really, if you can't trust a library author why can you
trust a cipher implementation author?

Not every crypto library implements high level protocols like SSL, TLS
or SSH or PGP, etc. libgcrypt for example is a general purpose crypto
library. It presumably is trustworthy is it not?

> I am not suggesting libraries should be avoided but simply that you are
> wrong to discount the alternative approach used by TrueCrypt. Neither of
> these approaches is invariably better than the other.

If you looked at the code for TrueCrypt you'd see the same horrors I
did. But because your code was used you assume the development process
was flawless?

No offense but since I know "better can be done" I have to disagree
with the method they chose. It's sloppy and prone to mistake.

Tom

Paul Cooper

unread,
Nov 3, 2005, 8:19:22 AM11/3/05
to
On Thu, 3 Nov 2005 11:21:52 +0100, Kristian Gjųsteen
<kristi...@item.ntnu.no> wrote:

> The documentation isn't too clear:

IMO, it is actually quite clear. It says that whitening is applied
"after the sector is encrypted". Inspection of source code confirms
that.


>I'll assume the first option.

But the second option is correct.

tomst...@gmail.com

unread,
Nov 3, 2005, 8:19:16 AM11/3/05
to
clark wrote:
> >Which is odd because portable crypto libraries exist. There is no
> >reason why they couldn't just link against them instead of munging
> >crypto routines from a dozen authors.
>
> That is a lame, self-serving statement.

How's that? Last I checked OpenSSL was available in windows.
libgcrypt and Crypto++ as well.

I never said "THOR SAYS LIBTOMCRYPT!!!". Get your head out of your ass
and stop trying to flame people because you feel inadequate.

> These are some of the authors:
>
> Paul Le Roux
> Eric Young
> Dr. Brian Gladman
> Markus Friedl
>
> I don't see anyone in that list that I wouldn't trust at least ten
> times more than, say, some fat assed blabbermouth who is almost unable
> to make a post that doesn't reference his own work as being brilliant
> while denigrating everyone else's products and efforts.

I never once referenced my work in that post. And in fact Eric is the
author of some [most?] of the OpenSSL kit is he not? I'm sorry, but
if you looked at the code for that package and said "wow, that's
proper!" you're just an ignorant and don't know any better.

As for "trusting this fat assed blabbermouth" ... it's a good thing my
survival doesn't count on your approval alone. Phew.

> >I'm not saying the program is insecure [I'm also not saying it's
> >secure]
>
> Whatever it is your saying, it has a near 100% likelyhood of devaluing
> someone else's work and harping your own.

Where did I mention my own? Oh right I didn't. You assumed that
because you're a two-bit troll.

> > but it seems they have a total miss of priorities.
>
> Really? A total miss? Then you must be an idiot.
>
> The product stands on its own as one of the best disk encryption
> products that can be obtained anywhere.

.... Right.

> It is well written. Works very well and is stable. It is free to
> anyone who wishes to use it under Windows or Linux.

Working and being properly written are TWO different things.

> And it has its roots in another well-known disk encryption product
> that was called Encryption for the Masses or E4M. It is a worthy
> successor.

I don't care where it came from. Bad devleopment processes should not
be acceptable.

Keep in mind I also challenged the GnuPG team last year concerning the
quality of their code too. Just because you're popular doesn't mean
it's acceptable to develop inferior software.

> Are you physically unable to recognize anyone else's accomplishments
> except your own?

Yup. That's why I take credit for all the patches to LibTom projects.
The names that appear in the changelogs are all made up just to cover
and make me look less selfish.

> > There are
> >source files that are NOT tables and over 100KB in size. They use
> >inconsistent coding style and indentation [mostly because they lifted
> >code from everywhere] and they also employ the magical "multiple cipher
> >passes" modes of operation.
>
> Yeah. They lifted code from Dr. Brian Gladman and Eric Young.
>
> Hmmmm. Sounds like they knew what they were doing.

So what? Cryptographer != software developer. Gladman may write fast
code but his style lacks consistency [or documentation]. I'd trust his
code too. However, what TC requires is a crypto library. It would be
better served by not including the crypto itself.

> >If they were serious about security
>
> You pompous fat drooling coward.

Um? I don't drool that much.

> > they would worry less about the
> >number of passes with different ciphers they utilize and more about the
> >quality of the code that implements their system.
>
> Then why don't you shut your big fat mouth and write an interface
> around LTM that will implement stable and secure, easy to use disk
> encryption?

Because LTM is a math library? :-)

Presuming you mean LTC it's precisely because I'm busy working on
LibTomCrypt [and the others] that I don't branch out and do things like
that.

> Why don't you do that instead of lying about a good product?

Well, first off because I wouldn't use. I find disk encryption to be
totally useless. It's a waste of energy and space and for the most
part people are totally f'ing confused by it.

Secondly is because I'm busy with other tasks.

> You take a coward's position.

Um ok. If it's corwardly to be differenced and speak your mind then
that's me. Tom the open minded vocal coward!

> TrueCrypt is a good product written on solid principles and it works
> well. And it is free for anyone who needs to secure their data.

working well != secure and working well != developed well

> It is easy to use. It works on Windows 2000/XP/2003 32/64-bit.
>
> It is ported to some major versions of Linux and you can make the
> version from source for other flavors.

Big deal?

> The source code is published and free for download and analysis.

Apparently not. Because if you speak negatively about it you get
people like this "Clark" guy calling you a "pompous blathering ass" ...


Seems it's a "only speak good" policy.

> And for some big-mouthed fat-assed group coward to say otherwise,
> without giving any reasonable cause is lame.

I don't see why the personal insults help your argument. Me being a
fat-ass coward doesn't really have any bearing on the complaints I
raised.

You might as well call me a Jew or something. That's about as
relevent.

> And I'll tell more truth: Eric Young's and Dr. Brian Gladman's code
> are fielded MANY times more often than a certain sci.crypt blowhard's
> precious library and there are many good reasons for that.

Um, Erics yes because it's part of OpenSSL as for Gladmans ... that's
hard to tell. You see I have users like Demonware and SCEA which put
my software on things called "video games". Then I have texas
instruments putting it in DSL routers and I have anothe San Jose
company putting it in power managers for Dell and IBM servers ... :-)

I have a "few" users too.

> Most of the reasons are technically-based.

So ... me being the cowardly pompous-ass is technical?

> But some of them likely have more to do with him being an asshole then
> for technical reasons.

This is the price of being charitable I guess. I never onced charged a
dime for my software and in return I get people like you flaming me in
open discussion.

First off, I never mentioned LTC specifically. I could just as easily
been talking about libgcrypt, openssl or crypto++ which are all
accessible, decent crypto libraries that can work in win32 as well as
linux [among other platforms].

Second, being critical of software is not a sign of disrespect. I'd
say blindly supporting it does more harm. Have you reviewed the code?
Or are you just assuming because some random stranger glued "BRG"
source together it MUST be secure? You do him more disservice by
promoting apathy in the review process.

Third, you being insulting to me won't change my ways, doesn't
invalidate my points and just shows that you're incapable of having an
adult discussion.

Fourth, who the fuck are you to call me incompetent and a blathering
idiot? I'd like to see what you bring to the table [under the flag of
Public Domain no less] that makes you so amply qualified to rain down
the insults on others.

Tom

Paul Cooper

unread,
Nov 3, 2005, 8:26:54 AM11/3/05
to
On Thu, 3 Nov 2005 13:23:02 +0100, Kristian Gjųsteen
<kristi...@item.ntnu.no> wrote:

>I'm only interested in the first block of each sector

That's right. And the first block of every sector is XORed with a secret
and unpredicatable value (no matter what cipher you use) -- and that
value is different for each sector. That's what's referred to as
"whitening".

So your method to create two identical sectors (which you refer to as
"attack" for some reason) does not work.

Paul

Kristian Gjųsteen

unread,
Nov 3, 2005, 8:57:46 AM11/3/05
to
Paul Cooper <p_co...@dsvca.org> wrote:
>On Thu, 3 Nov 2005 13:23:02 +0100, Kristian Gjųsteen
><kristi...@item.ntnu.no> wrote:
>
>>I'm only interested in the first block of each sector
>
>That's right. And the first block of every sector is XORed with a secret
>and unpredicatable value (no matter what cipher you use) -- and that
>value is different for each sector. That's what's referred to as
>"whitening".

Yes, I think I got that a few posts back.

>So your method to create two identical sectors (which you refer to as
>"attack" for some reason) does not work.

It would help a lot if you actually looked at the details I provided
in the previous post and explained where I went wrong. Just saying
that I'm wrong doesn't actually explain why I'm wrong.

And note that I never create two identical sectors of ciphertext.
I create two pairs of sectors, and their difference is the same.

--
Kristian Gjųsteen

BRG

unread,
Nov 3, 2005, 10:36:28 AM11/3/05
to
tomst...@gmail.com wrote:

> BRG wrote:
>> There are reasons for avoiding cryptograhic libraries in some situations.
>>
>> Libraries are typically collections of basic algorithms combined with
>> higher level protocols and code structures in which the library designer
>> has imposed his or her views on both code and security design.
>
> That's a bit infantile. Libraries like OpenSSL allow you to have
> direct access to the crypto primitives. If you don't like the SSL
> protocol you don't have to use it. You can still use the crypto
> though.

That's your view but one I do not share. If you truly see this as
infantile, then you have a great deal to learn about information security.

>> Those who want to use their own higher level security and code design
>> philosophies (and are expert enough to do so) will hence often prefer to
>> bring together individual open source algorithm implementations in which
>> they have developed a lot of trust rather than rely on a library and
>> hence become subject to the prejudices of its author.
>
> I don't see the benefit. Different authors have different coding
> styles, interfaces, etc. Bringing dozens of random pieces of code
> together only means you have to work the source code so that they're
> uniform.

I would not expect you to see the benefit but the fact that you don't
see it doesn't mean that it doesn't exist.

Do you have any evidence to back your assertion that the TrueCrypt team
selected their algorithm implementations randomly? What leads you to
conclude that they did not make their selections with care?

If the right choices have been made, there will be no need to make
significant changes to the source code of imported algorithm
implementations.

And really, if you can't trust a library author why can you
> trust a cipher implementation author?

This is not an issue that is determined in any major way by the choice
between the use of a library or non-library approach.

> Not every crypto library implements high level protocols like SSL, TLS
> or SSH or PGP, etc. libgcrypt for example is a general purpose crypto
> library. It presumably is trustworthy is it not?
>
>> I am not suggesting libraries should be avoided but simply that you are
>> wrong to discount the alternative approach used by TrueCrypt. Neither of
>> these approaches is invariably better than the other.
>
> If you looked at the code for TrueCrypt you'd see the same horrors I
> did. But because your code was used you assume the development process
> was flawless?

No.

> No offense but since I know "better can be done" I have to disagree
> with the method they chose. It's sloppy and prone to mistake.

Of course it could be better. But not for the reasons you suggest.

Brian Gladman

tomst...@gmail.com

unread,
Nov 3, 2005, 10:48:57 AM11/3/05
to
BRG wrote:
> > That's a bit infantile. Libraries like OpenSSL allow you to have
> > direct access to the crypto primitives. If you don't like the SSL
> > protocol you don't have to use it. You can still use the crypto
> > though.
>
> That's your view but one I do not share. If you truly see this as
> infantile, then you have a great deal to learn about information security.

But why stop there? How do you know strncat() from your C library is
correct? I wouldn't trust a non-cryptographer to get that aspect of
security right either!

> > I don't see the benefit. Different authors have different coding
> > styles, interfaces, etc. Bringing dozens of random pieces of code
> > together only means you have to work the source code so that they're
> > uniform.
>
> I would not expect you to see the benefit but the fact that you don't
> see it doesn't mean that it doesn't exist.

Why would expect me not to see the benefit? I've done embedded
development. Let's not forget that in less than 100KB of ARM7 code you
can have a fully function RSA+AES+SHA256 based crypto system [along
with ASN.1, PKCS#1 and #5, HMAC and the Yarrow PRNG] fast enough to be
practical [add another 40KB to get highly optimized 1024-bit
multipliers, etc].

Just because *you* can't or won't do work with flexible libraries
doesn't mean others can't.

My libraries *are* used in space contrained environments and it's
precisely because the library is flexible enough to work anywhere that
people use it.

For example, you can use the library on your embedded ARC controller
for a flash chip AND on the desktop device driver. Why learn two
pieces of code?

> Do you have any evidence to back your assertion that the TrueCrypt team
> selected their algorithm implementations randomly? What leads you to
> conclude that they did not make their selections with care?

If they cared about the security of the design they would have just
used a crypto library which provides the algorithms they need in a well
formed package [including the chaining modes] and not worried about
things like "multi-pass inner-outer CBC mode".

Do you honestly think that those chaining modes address the actual
legitimate threats that face the user of the program?

Really?

> If the right choices have been made, there will be no need to make
> significant changes to the source code of imported algorithm
> implementations.

Except that your interfaces are not exact. Can I call your twofish and
AES code with the same variables as arguments? Last I checked you had
context structures for both that were not equivalent.

etc, etc.

> > And really, if you can't trust a library author why can you
> > trust a cipher implementation author?
>
> This is not an issue that is determined in any major way by the choice
> between the use of a library or non-library approach.

I don't see the value in using standalone algorithm implementations.
Specially since he's not just doing AES or just SHA256. They are using
a half dozen block ciphers. It's very easy to get those from a proper
crypto library instead.

> > No offense but since I know "better can be done" I have to disagree
> > with the method they chose. It's sloppy and prone to mistake.
>
> Of course it could be better. But not for the reasons you suggest.

On this we'll have to disagree.

Tom

Message has been deleted

clark

unread,
Nov 3, 2005, 11:15:23 AM11/3/05
to
On 3 Nov 2005 05:19:16 -0800, tomst...@gmail.com wrote:

[...]

According to you, blabbermouth, the product is a total miss and they
aren't serious about security. What a lamer you are.

You miserable fat assed twit.

Shut the f*** up for one moment in your angry self-important existence
and listen for once in your vitriolic life...

YOU are the one that disperaged TrueCrypt. Not anyone else.

You are not charitable. There is nothing charitable in your me-me-me
self-imporatant existence. You do what you do for one reason and one
reason only. Gee, I wonder if anyone can hazard a guess what that is?

Quit lying. You lying sack of dung.

TrueCrypt is a good security product.

You said they weren't serious about security. That is ignorant and
incorrect. So deal with it. They are obviously serious.

You said they have a total miss of priorities. Total miss. You
idiot. They have one of the best if not the best, easy to use,
secure, well-planned disk encryption products available. Where is the
total miss? The product is free for everyone and really good.


TrueCrypt is a known-good disk encryption product.


clark

unread,
Nov 3, 2005, 11:23:07 AM11/3/05
to

Please detail what you are saying, because it appears that you are
possibly confused about what Paul Cooper is saying.

It looks on the surface that you are incorrect on all counts.

Maybe I missed something. Please provide details.

Thank you.

tomst...@gmail.com

unread,
Nov 3, 2005, 11:31:09 AM11/3/05
to
clark wrote:
> On 3 Nov 2005 05:19:16 -0800, tomst...@gmail.com wrote:
>
> [...]
>
> According to you, $INSULT, the product is a total miss and they

> aren't serious about security. What a lamer you are.
>
> You miserable $INSULT.

What a convincing argument you have here. I don't know why I didn't
see it your way in the first place.

> Shut the f*** up for one moment in your angry self-important existence
> and listen for once in your vitriolic life...

Ok, take note that in my original reply I was *not* talking about
myself. You brought my work into this.

You did, not I.

> YOU are the one that disperaged TrueCrypt. Not anyone else.

Because the rest either don't care, have a vested stake or well... are
you.

> You are not charitable. There is nothing charitable in your me-me-me
> self-imporatant existence. You do what you do for one reason and one
> reason only. Gee, I wonder if anyone can hazard a guess what that is?

Yes, I talk about myself more than others. But so what? Part of the
reason I mention my doings is because I'm learning from them [e.g.
making faster bignum code for instance]. If I'm learning from it
probably someone else can as well.

And you think I'm harmful? If the worst thing I do in my life is talk
about myself on sci.crypt as I present public domain work that takes
thousands of hours of my time. Then so be it. I'll die a happy man.

> Quit lying. You $INSULT.

When have I ever lied in this context?

> TrueCrypt is a good security product.

Ok, assume everything I said is wrong. *Why* is it a good product?

> You said they weren't serious about security. That is ignorant and
> incorrect. So deal with it. They are obviously serious.

What have they done that demonstrates they're serious about the
development process and outcome?

> You said they have a total miss of priorities. Total miss. You

> $INSULT. They have one of the best if not the best, easy to use,


> secure, well-planned disk encryption products available. Where is the
> total miss? The product is free for everyone and really good.

None of that is proof or an argument in favour of their design. You
say it's "really good". I actually gave concrete reasons why I
disapprove of the design. You say "easy to use" ... big deal. I can
make programs that are both easy to use and trivially insecure
[actually... windows comes to mind...]

> TrueCrypt is a known-good disk encryption product.

Known by who? I've never heard of anyone who uses it and I know a lot
of people in the information security world.

Tom

clark

unread,
Nov 3, 2005, 12:09:29 PM11/3/05
to
On 3 Nov 2005 08:31:09 -0800, tomst...@gmail.com wrote:

[...]


>
>> TrueCrypt is a good security product.
>
>Ok, assume everything I said is wrong. *Why* is it a good product?

Because it does what it is supposed to do, based on safe practice.

Because it does what it is supposed to do, across Windows and Linux.

Because it does what it is supposed to do, for free.

Because it does what it is supposed to do, and they provide source.

Because it does what it is supposed to do, and they have good docs.

Because it does what it is supposed to do, and it is stable.


That is why it is a good disk encryption product for most users.


>> You said they weren't serious about security. That is ignorant and
>> incorrect. So deal with it. They are obviously serious.
>
>What have they done that demonstrates they're serious about the
>development process and outcome?

They have fielded a well-made, competently designed crypto product.

They have used best practice in the design.

They have achieved a stable, reliable product. Release after release.

They have used code from known-good authors as well as their own
careful coding.

They have made the commitment to keep the product free for all users.


This demonstrates that they are serious about the developement process
and that they are serious about the outcome.


BRG

unread,
Nov 3, 2005, 12:08:09 PM11/3/05
to
tomst...@gmail.com wrote:

> BRG wrote:
>>> That's a bit infantile. Libraries like OpenSSL allow you to have
>>> direct access to the crypto primitives. If you don't like the SSL
>>> protocol you don't have to use it. You can still use the crypto
>>> though.
>> That's your view but one I do not share. If you truly see this as
>> infantile, then you have a great deal to learn about information security.
>
> But why stop there? How do you know strncat() from your C library is
> correct? I wouldn't trust a non-cryptographer to get that aspect of
> security right either!

I didn't say you should stop there.

>>> I don't see the benefit. Different authors have different coding
>>> styles, interfaces, etc. Bringing dozens of random pieces of code
>>> together only means you have to work the source code so that they're
>>> uniform.
>> I would not expect you to see the benefit but the fact that you don't
>> see it doesn't mean that it doesn't exist.
>
> Why would expect me not to see the benefit? I've done embedded
> development. Let's not forget that in less than 100KB of ARM7 code you
> can have a fully function RSA+AES+SHA256 based crypto system [along
> with ASN.1, PKCS#1 and #5, HMAC and the Yarrow PRNG] fast enough to be
> practical [add another 40KB to get highly optimized 1024-bit
> multipliers, etc].
>
> Just because *you* can't or won't do work with flexible libraries
> doesn't mean others can't.

If you read what I have said carefully, you will see that I am saying
that the choice between a library and non-library based approach depends
on the circumstances - neither approach is invariably better than the other.

I regularly use two cryptographic libraries and I contribute my code to
a several more.

So perhaps you can tell me what evidence you have for your assertion
that I "can't or won't do work with flexible libraries".

> My libraries *are* used in space contrained environments and it's
> precisely because the library is flexible enough to work anywhere that
> people use it.
>
> For example, you can use the library on your embedded ARC controller
> for a flash chip AND on the desktop device driver. Why learn two
> pieces of code?

My code is used in all sorts of places but I don't talk about this since
I am not in the business of self promotion.

>> Do you have any evidence to back your assertion that the TrueCrypt team
>> selected their algorithm implementations randomly? What leads you to
>> conclude that they did not make their selections with care?
>
> If they cared about the security of the design they would have just
> used a crypto library which provides the algorithms they need in a well
> formed package [including the chaining modes] and not worried about
> things like "multi-pass inner-outer CBC mode".

The first part of this is a circular argument that carries no weight
since it just repeats the point at issue.

Moreover you have avoided answering my question - what evidence do you
have for your assertion that the TrueCrypt team selected their algorithm
implementations randomly?

[snip]


>> If the right choices have been made, there will be no need to make
>> significant changes to the source code of imported algorithm
>> implementations.
>
> Except that your interfaces are not exact. Can I call your twofish and
> AES code with the same variables as arguments? Last I checked you had
> context structures for both that were not equivalent.

My code uses several different calling interfaces. Last time I looked
there was no regulation that specified that all cryptographic algorithms
had to be designed and implemented with the same calling interfaces.

The fact that a common interface makes sense in a library does not
justify any conclusion that this is necessarily desirable in other contexts.

>>> And really, if you can't trust a library author why can you
>>> trust a cipher implementation author?
>> This is not an issue that is determined in any major way by the choice
>> between the use of a library or non-library approach.
>
> I don't see the value in using standalone algorithm implementations.
> Specially since he's not just doing AES or just SHA256. They are using
> a half dozen block ciphers. It's very easy to get those from a proper
> crypto library instead.

Tell us something new - we already know that you don't see value in any
approach other than that which you advocate.

>>> No offense but since I know "better can be done" I have to disagree
>>> with the method they chose. It's sloppy and prone to mistake.
>> Of course it could be better. But not for the reasons you suggest.
>
> On this we'll have to disagree.

Agreed.

Brian Gladman

David Wagner

unread,
Nov 3, 2005, 12:16:08 PM11/3/05
to
Sebastian Gottschalk <se...@seppig.de> wrote:
>So far, TwoFish is broken.

Sebastian Gottschalk wrote:
>http://www.wilderssecurity.com/showpost.php?p=584362&postcount=109

That URL says only:

``Twofish is broken. The best attack now is around O(2^52), against
the theoretical O(2^256) brute force attack. There is a paper by
Moriai and Yin, two japanese researchers called "Cryptoanalisys of
TwoFish" that presents the technique.''

I'm guessing the writer is referring to this unpublished paper:

Shiho Moriai, Lisa Yiqun Yin, "Cryptanalysis of Twofish (II)",
Technical report, IEICE, ISEC2000-38, July 2000.

Unfortunately, I couldn't find a copy of the paper online, nor is
it obvious to me where I would go to get a copy. The abstract appears
to be as follows:

``We present truncated differential cryptanalysis of the block
cipher Twofish, which is one of the five finalists for the
Advanced Encryption Standard(AES). From our experimental results,
we found a 16-round truncated differential with probability of
about 2^<-57.3>. One can expect to get one good pair following the
truncated differential from 2^<51> chosen plaintexts, and there are
a total of 2^<77> such good pairs. We also found 5-round truncated
differentials which can be useful in distinguishing Twofish reduced
to 5 rounds from a random permutation. This was considered to be an
open problem by Knudsen.''

http://info.ipsj.or.jp/members/SIGNotes/Eng/27/2000/010/article016.html
http://66.102.7.104/search?q=cache:4foX4_B8eCwJ:info.ipsj.or.jp/members/SIGNotes/Eng/27/2000/010/article016.html+%22cryptanalysis+of+Twofish%22+moriai+yin&hl=en&client=firefox-a

The abstract seems to suggest they can break 5 rounds of Twofish.
It also mentions a truncated differential for 16 rounds, but there is
no statement about whether it can be used to distinguish Twofish from
a random permutation. But it's sometimes very hard to figure out the
content of a paper just by looking at the abstract; we'd really need to
see the whole paper to know for sure.

Does anyone know where to find a copy of that paper? Sebastian, have
you read the paper yourself, or are you just going by what it said on
the URL you listed?

I have to say that I would find it surprising if Moriai and Yin had
broken Twofish five years ago but never bothered to inform any of us on
the Twofish team or publish it anywhere. That's what makes me wonder
whether perhaps there could be a misunderstanding here.

Kristian Gjųsteen

unread,
Nov 3, 2005, 12:34:09 PM11/3/05
to
clark <cl...@barbell.com> wrote:
>It looks on the surface that you are incorrect on all counts.

Why? It would help if you actually point out where my mistake is.

--
Kristian Gjųsteen

Bryan Olson

unread,
Nov 3, 2005, 12:40:12 PM11/3/05
to
David Wagner wrote:
[...]

> Sebastian, have
> you read the paper yourself, or are you just going by what it said on
> the URL you listed?

And if the former, how does one break TwoFish? If the later, how
could you possibly be so gullible?


> I have to say that I would find it surprising if Moriai and Yin had
> broken Twofish five years ago but never bothered to inform any of us on
> the Twofish team or publish it anywhere. That's what makes me wonder
> whether perhaps there could be a misunderstanding here.

Gee, you think?


--
--Bryan

clark

unread,
Nov 3, 2005, 1:00:49 PM11/3/05
to
On Thu, 3 Nov 2005 18:34:09 +0100, Kristian Gjųsteen
<kristi...@item.ntnu.no> wrote:

>clark <cl...@barbell.com> wrote:
>>It looks on the surface that you are incorrect on all counts.
>
>Why? It would help if you actually point out where