TrueCrypt 4.0 Out
Ari Silversteinn
Luc The Perverse
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
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
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
Kristian Gjųsteen
>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
>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
>
>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
>So far, TwoFish is broken.
???
Can you elaborate?
clark
<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
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
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
>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
> 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
<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
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
<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
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
> 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
<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
> >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
<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
>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
> 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
> > 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
clark
[...]
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
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
> aren't serious about security. What a lamer you are.
>
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
[...]
>
>> 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
> 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
>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
>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
[...]
> 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
<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 my mistake is.
I think it is in the part where you claim you can distinguish
TrueCrypt encrypted data from random plaintext.
Using the example of AES-256 encryption, I don't think you can
distinguish ANY data (no matter how you prepare it) after it has been
normally encrypted with TrueCrypt.
I find it difficult to believe at this time, based on your arguments.
They are not convincing. The design of TrueCrypt appears to prevent
you from succeeding at this.
tomst...@gmail.com
clark wrote:
> 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 my mistake is.
>
> I think it is in the part where you claim you can distinguish
> TrueCrypt encrypted data from random plaintext.
Whoa whoa whoa. Where did I say that?
> Using the example of AES-256 encryption, I don't think you can
> distinguish ANY data (no matter how you prepare it) after it has been
> normally encrypted with TrueCrypt.
... So you're saying using Key="hello world" with AES-256 is secure
against eavesdroppers? Interesting.
> I find it difficult to believe at this time, based on your arguments.
I never said it's weak. I said it's poorly designed and that the
design COULD be the root of any bugs or flaws found in it.
Even if TC is secure [something you haven't really proven here, you
just rely on some weak reduction to AES as your security proof] writing
code properly is ALWAYS a good idea.
It's called a profession for a reason.
> They are not convincing. The design of TrueCrypt appears to prevent
> you from succeeding at this.
I never said I could. You have to to stop trying to harp on the first
chance to troll someone and actually read what they are writing.
At the game of usenet you lose my friend.
Tom
Jeffrey F. Bloss
>> 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!
If you start from scratch you can get even smaller. I think IDEA was coded
to compile to something like 560 bytes, and AES was pruned down to under
450. This would tend to indicate that size really doesn't matter after
all.
Of course raw implementations don't account for things like temp file
issues, fancy GUI stuff, or "drivers" to provide any sort of virtual disk
capability. But the above paradox between the "old" IDEA and the "new and
improved" AES should tell us that coding more secure fluff doesn't
necessarily dictate that we generate more of it. ;-)
No personal jab intended, but I'm left wondering if the OP isn't a victim
of Winitis... that insidious disease which causes people to believe that
since our standard software choices have grown over time, and tell you
they've become more "worthy", it's somehow necessary for a behemoth to
grow fatter to become more useful.
<sigh>
Often the inverse is the fact. It's usually more desirous to discard the
chafe and retain the wheat to bake the better bread. Chocolate chips and
sweet frosting only make it more appealing to people who get distracted
by empty calories.
Which I suppose would include most of us to one degree or another. ;)
--
_?_ Outside of a dog, a book is a man's best friend.
(@ @) Inside of a dog, it's too dark to read.
-oOO-(_)--OOo-------------------------------[ Groucho Marx ]--
grok! Registered Linux user #402208
tomst...@gmail.com
> > 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.
And for all but the most constrained tasks that's just immature. Even
the most basic ARM based microcontroller can fit a decent C lib.
Re-writing standard C calls is a good learning experience but really of
little professional value.
> > 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.
For *this task* a library would suit it better. It makes the code
easier to audit and expends less time overall. E.g. had they used
libgcrypt we could base security assumptions in TC on "they implemented
it securely in libgcrypt".
Instead now we have to audit both. Even if he used your code we still
have to audit it. How do we know it hasn't been altered [either
explicitly or semantically].
> 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".
What libraries in the OSS world do you contribute to?
> > 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.
That's why you mandate a copyright banner with your name. No promotion
there!
> > 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.
Um ok. If you can't see that this userspace DESKTOP application can't
benefit from offloading the crypto to a library I guess there is no
hope for this discussion.
> Moreover you have avoided answering my question - what evidence do you
> have for your assertion that the TrueCrypt team selected their algorithm
> implementations randomly?
Ok, tell me why they picked non-standard algorithms? Serpent?
Twofish? What of the inner-outter CBC mode? What standard is that
part of?
> > 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.
Nobody said you had to use MY way of doing it. My point was if he
wanted to rip all these diff algos he should have ported them to one
calling interface [of his choosing].
> 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 it doesn't impact performance in the slighest. So what does it
matter? If you can both write clean code and well structure code then
do it.
> > 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.
Yeah that's it Brian. You pegged me.
Dude, the days of standalone crypto packages with say AES only or
whatever are long gone. Get over it. If you can learn to use [both
calling and linking/building] one library which provides all of your
crypto primitives in one spot is that not better than shopping around
for code from different authors with different styles, coding
standards, etc... ?
Tom
clark
[...].
>
>At the game of usenet you lose my friend.
>
No. I believe my comments were correct to Kristian Gjųsteen.
I was not playing games with anyone.
YOU just pull YOUR head out of YOUR ass and quit playing games, OK?
Kristian Gjųsteen
Actually, there is no need for you to believe anything. I have given
enough details for anyone to actually go and do some specific writes
to their TrueCrypt container and then check that a simple relation
holds for the ciphertext, a relation that doesn't hold for random
plaintext. Go back, read the details, and perform the experiment.
(I would have done it myself if I had a computer that could run
TrueCrypt available.)
Then you can report back. There is no need to believe or disbelieve.
--
Kristian Gjųsteen
BRG
> BRG wrote:
>>> 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.
>
> And for all but the most constrained tasks that's just immature. Even
> the most basic ARM based microcontroller can fit a decent C lib.
> Re-writing standard C calls is a good learning experience but really of
> little professional value.
Again you show that you know very little about information security.
>>> 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.
>
> For *this task* a library would suit it better. It makes the code
> easier to audit and expends less time overall. E.g. had they used
> libgcrypt we could base security assumptions in TC on "they implemented
> it securely in libgcrypt".
Expressing your opinion does not make it a fact. We know that, in your
opinion, they should have used a library approach rather than a
non-library one. They didn't. Maybe they have a good reason for their
choice, maybe they don't, but it's not necessarily the wrong approach.
> Instead now we have to audit both. Even if he used your code we still
> have to audit it. How do we know it hasn't been altered [either
> explicitly or semantically].
>
>> 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".
>
> What libraries in the OSS world do you contribute to?
I will tell you off list if you wish.
>>> 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.
>
> That's why you mandate a copyright banner with your name. No promotion
> there!
It's not promotion, it's part of a fairly standard license. People only
see this after they obtain the product itself so its an odd form of
promotion.
>>> 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.
>
> Um ok. If you can't see that this userspace DESKTOP application can't
> benefit from offloading the crypto to a library I guess there is no
> hope for this discussion.
>
>> Moreover you have avoided answering my question - what evidence do you
>> have for your assertion that the TrueCrypt team selected their algorithm
>> implementations randomly?
>
> Ok, tell me why they picked non-standard algorithms? Serpent?
> Twofish? What of the inner-outter CBC mode? What standard is that
> part of?
You are STILL not answering the question - posing another question is
not an answer.
In my view you cannot give an answer because your assertion of a 'random
selection' is a pure invention on your part without a shred of evidence
to back it up. In my view you used this characterisation to cast their
approach in a derogatory light simply because they had the audacity to
use an approach that you don't agree with.
>>> 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.
>
> Nobody said you had to use MY way of doing it. My point was if he
> wanted to rip all these diff algos he should have ported them to one
> calling interface [of his choosing].
There are very good reasons not to change other people's code unless
this is unavoidable.
>> 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 it doesn't impact performance in the slighest. So what does it
> matter? If you can both write clean code and well structure code then
> do it.
The calling interface for a cryptographic algorithm can sometimes have a
devastating impact on both speed and security. The right interface in
one context can be quite wrong for another. And, of course, this is
quite separate from any debate about well designed code - I don't see
anyone here arguing for poorly designed code.
>>> 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.
>
> Yeah that's it Brian. You pegged me.
I think you have been pegged well before I came along.
> Dude, the days of standalone crypto packages with say AES only or
> whatever are long gone. Get over it. If you can learn to use [both
> calling and linking/building] one library which provides all of your
> crypto primitives in one spot is that not better than shopping around
> for code from different authors with different styles, coding
> standards, etc... ?
Sometimes it is, sometimes it isn't. I am not advocating one approach
over the other irrespective of circumstances. That is what you are
trying to do.
Brian Gladman
tomst...@gmail.com
BRG wrote:
> > And for all but the most constrained tasks that's just immature. Even
> > the most basic ARM based microcontroller can fit a decent C lib.
> > Re-writing standard C calls is a good learning experience but really of
> > little professional value.
>
> Again you show that you know very little about information security.
Where did this come from? I'm talking about software development
practices here.
> > For *this task* a library would suit it better. It makes the code
> > easier to audit and expends less time overall. E.g. had they used
> > libgcrypt we could base security assumptions in TC on "they implemented
> > it securely in libgcrypt".
>
> Expressing your opinion does not make it a fact. We know that, in your
> opinion, they should have used a library approach rather than a
> non-library one. They didn't. Maybe they have a good reason for their
> choice, maybe they don't, but it's not necessarily the wrong approach.
Explain to me how including the crypto directly in the package makes it
in ANY way better.
This is exactly like all the packages which include zlib in their
trees. Despite the fact that you can build and install zlib on your
own [even as a shared object!!!] and link it in otherwise.
> >> 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".
> >
> > What libraries in the OSS world do you contribute to?
>
> I will tell you off list if you wish.
I know your code is in the Kernel but that's hardly a good example
given that people question the crypto in the kernel as it is anyways.
[e.g. /dev/random debates]
> > That's why you mandate a copyright banner with your name. No promotion
> > there!
>
> It's not promotion, it's part of a fairly standard license. People only
> see this after they obtain the product itself so its an odd form of
> promotion.
Not really. I don't care about your code, I want TrueCrypt, oh what's
this? BRG code inside? boohiss! It's like the Dolby advertisements
before movies ...
Also what I "promote" is public domain to be used however anyone sees
fit. I don't promote my commercial services here because I realize
that's inappropriate.
> > Ok, tell me why they picked non-standard algorithms? Serpent?
> > Twofish? What of the inner-outter CBC mode? What standard is that
> > part of?
>
> You are STILL not answering the question - posing another question is
> not an answer.
Exactly though. There isn't a good reason for those choices they made.
Hell, if you can't answer those questions how can you advocate the
design?
> In my view you cannot give an answer because your assertion of a 'random
> selection' is a pure invention on your part without a shred of evidence
> to back it up. In my view you used this characterisation to cast their
> approach in a derogatory light simply because they had the audacity to
> use an approach that you don't agree with.
Yeah, that's it BRG [I'm beginning to suspect this isn't the real
BRG...], Again you pegged me.
OR could it be I do disagree with it but for good reason?
> > Nobody said you had to use MY way of doing it. My point was if he
> > wanted to rip all these diff algos he should have ported them to one
> > calling interface [of his choosing].
>
> There are very good reasons not to change other people's code unless
> this is unavoidable.
If you don't understand the code enough to change a calling interface
on a block cipher ... you got bigger issues at hand.
a) The code you are ripping from is crap because it's hard to maintain
b) You don't understand the code you are using.
> > And it doesn't impact performance in the slighest. So what does it
> > matter? If you can both write clean code and well structure code then
> > do it.
>
> The calling interface for a cryptographic algorithm can sometimes have a
> devastating impact on both speed and security. The right interface in
> one context can be quite wrong for another. And, of course, this is
> quite separate from any debate about well designed code - I don't see
> anyone here arguing for poorly designed code.
For block ciphers? key+pt+ct is about all you need for an interface.
Doesn't get any harder than that.
> > Dude, the days of standalone crypto packages with say AES only or
> > whatever are long gone. Get over it. If you can learn to use [both
> > calling and linking/building] one library which provides all of your
> > crypto primitives in one spot is that not better than shopping around
> > for code from different authors with different styles, coding
> > standards, etc... ?
>
> Sometimes it is, sometimes it isn't. I am not advocating one approach
> over the other irrespective of circumstances. That is what you are
> trying to do.
You're saying I'm wrong for objecting when clearly this application
calls for a library. Why waste development time worrying about how the
ciphers or chaining modes are implemented when someone else has already
done that work for you?
It isn't just a factor of being lazy but just careful. It's easier to
use someone elses well tested library then write your own for no good
purpose but "having homebrew crypto".
Tom
tomst...@gmail.com
clark wrote:
> 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.
Which practices are those? Re-inventing the wheel and abandonning any
sense of standardization when it becomes troublesome?
> Because it does what it is supposed to do, across Windows and Linux.
Ok I guess
> Because it does what it is supposed to do, for free.
Being free doesn't make something good. It makes it useful.
> Because it does what it is supposed to do, and they provide source.
Ok, but the code is not to be reviewed?
> Because it does what it is supposed to do, and it is stable.
Stable != secure. Furthermore have they provided use cases? Verified
any of it?
> That is why it is a good disk encryption product for most users.
Because you can use vague subjective words like "good" and "stable"?
> >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.
If it was comptently made why did they not use standard chaining modes?
Why do they provide multi-pass algorithms? Why do they implement [or
rip] the crypto algorithms instead of just calling a library?
> They have used best practice in the design.
Well I don't know. Either you're right and they're half-assed for not
including a kernel, GUI, C library and the kitchen sink with their code
or I'm right and they shouldn't bundle an assortment of crypto code
with their package when commonly available libraries can handle that
for them.
> They have achieved a stable, reliable product. Release after release.
Stable and reliable make not a secure product.
> They have used code from known-good authors as well as their own
> careful coding.
That's subjective. "careful coding" is why they have source files over
100KB in size? With no sense of code factoring, etc...
I don't know where you went to school or what software development
experience you have but that's just plain stupid. That's the sort of
shit I was doing when I was 17 and 18 writing my first crypto library
and learning painfully how not to write code.
> They have made the commitment to keep the product free for all users.
In no way does linking to libgcrypt inhibit that.
> This demonstrates that they are serious about the developement process
> and that they are serious about the outcome.
No it doesn't. You have just said qualities you assume they possess
without actually showing HOW they are qualified to have the qualities
associated with them.
It's like me saying "Clark is a good person". Really? Why? How is he
"a good person"?
If you want to show how their development process is a success why not
show how easy it is to take any random function and explain it to a
user ... better yet, just show the code for a random function to a
developer and have them understand it enough to say translate it to
another language.
You want my credentials? Check out this
http://www.riva.com.tr/volkan/libtommath.htm
This person ported LibTomMath [ONE of my bignum math libraries] to
Pascal WITHOUT my assistance. According to him, he had the majority of
the work done over a weekend.
Can you say the say the same about TrueCrypt?
To quote the author:
"LibTomMath (in C) has excellent documentation written by original
author, even better than most commercial libraries. He not only
explains usage of functions, but also describes the theory behind
algorithms. ..."
Tom
cryptonom
>
> You want my credentials? Check out this
>
> http://www.riva.com.tr/volkan/libtommath.htm
>
> This person ported LibTomMath [ONE of my bignum math libraries] to
> Pascal WITHOUT my assistance. According to him, he had the majority of
> the work done over a weekend.
>
> Can you say the say the same about TrueCrypt?
>
> To quote the author:
>
> "LibTomMath (in C) has excellent documentation written by original
> author, even better than most commercial libraries. He not only
> explains usage of functions, but also describes the theory behind
> algorithms. ..."
>
> Tom
>
Ding Ding, Tom rings his own bell again (no surprise).
Get over yourself, Tomfoolery, there are plenty of people in the
world who can write good code. Your inflated head is starting to
become one of this newsgroup's worst annoyances .
tomst...@gmail.com
> Ding Ding, Tom rings his own bell again (no surprise).
>
> Get over yourself, Tomfoolery, there are plenty of people in the
> world who can write good code. Your inflated head is starting to
> become one of this newsgroup's worst annoyances .
The purpose of that quote was to show I am qualified to make statements
like that.
Specifically because I have had successes like that.
How can you people challenge my authority to speak up then challenge my
ability to defend my authority? Either you are questioning my
authority [e.g. ability to speak out of knowledge and experience] and
thus demand a response or you're not and you're just trolling to get
responses like this.
Tom
Ari Silversteinn
> This would tend to indicate that size really doesn't matter after
> all.
Small penised men always say that.
--
Drop the alphabet for email
Ari Silversteinn
> No personal jab intended, but I'm left wondering if the OP
Which was me, Jeffie.
> isn't a victim
> of Winitis... that insidious disease which causes people to believe that
> since our standard software choices have grown over time, and tell you
> they've become more "worthy", it's somehow necessary for a behemoth to
> grow fatter to become more useful.
No Jeffie and however you got that from my posting a simple URL is in need
of psychological examination, yes?