Re: TrueCrypt 4.0 Out

From: BRG (brg_at_nowhere.org)
Date: 11/04/05 

Date: Fri, 04 Nov 2005 00:51:54 +0000

tomstdenis@gmail.com wrote:
> [further contributing to the trainwreck that is sci.crypt...]
>
> 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.

Which, in a secure system, are closely related to the attainment of
information security objectives. If a routine in a C library is used in
a secure system in a way that has information security implications, you
can rest assured that it _will_ attract the interest of those with
responsibility for the security aspects of system design.

>>> 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 not a question that it makes sense to answer in the abstract.

But it is easy to come up with examples where a library is going to be
less appropriate than a stand alone cryptographic algorithm implementation.

And before you ask, I am not going to spend time educating you if you
cannot think of such examples.

> 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]

My code is used in several operating systems but you asked about
libraries and my answer was given in this context.

>>> 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 ...

Rubbish. Few, if any, TrueCrypt users will have even the slightest clue
that my code is being used. Very few will get as far as the
acknowledgements section of the manual and far, far fewer still will
take the trouble to download and inspect the code. And I don't kid
myself into thinking that even those few who go this far will have much
of a clue about who I am.

> 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?

Why do you think I would want to advocate their design?

What I am saying is that you have no sound basis for suggesting that
their decision not to use a library is necessarily wrong. Which, of
course, is completely different from saying that what they are doing is
right.

>> 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.

In situations where third party code is being used there are good
reasons for not making changes to this code unless this cannot be avoided.

> 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.

(c) you want to make use of ongoing support and further code development
by the original author without incurring the maintenance nightmare of
making changes to their code every time they issue a new release.

As well as other reasons.

>>> 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.

Of course it does. Should the interface support a cryptographic context
or direct keying? Should the interface support one or the other or both
pre-encryption key expansion and 'on the fly' keying? Should the
interface allow multiple blocks? Should it allow partial blocks? Should
the interface use only pointers or should it use pointers and a length
field?. If the latter should it be in bits or bytes or some other unit?
 Should the input and output areas be capable of being anywhere in
memory or should overlap of input or output memory areas be banned.
Should there only be one combined input/output area. What should happen
if an internal error occurs, .......

The semantics of even low level algorithm interfaces are already very
rich and this richness gets far worse at higher levels.

And the choice of these interface semantics can have a huge impact on
the utility of an algorithm implementation and on its performance in a
particular application context.

I can certainly now see why you mistkenly think that libraries are
always appropriate.

>>> 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".

It's not "homebrew crypto" since they _are_ making use of code provided
by others.

  Brian Gladman

Relevant Pages

  • Re: Variable uses a type not supported in Visual Basic (Error 458)
    ... > Microsoft Visual Basic for Applications Software Development Kit ... > interface in a Visual Basic class, ... > generate libraries that use a Visual Basic- or Visual Basic for ... > Rebuild your type library by pressing CTRL+F7 or selecting Compile ...
    (microsoft.public.vb.bugs)
  • Re: Recommendations for JavaScript drop-down menu code
    ... to not having a long enough history working with browsers to ... Obviously these individuals are not aware that there code has these issues following from their inexperience, but now your project manager cannot solve his problem by just using a library unless he has someone who knows the issues themselves and so can point out which libraries properly handle them and which doe not. ... interface and a base implementation of that interface. ... but it is still important that the interface design stage takes into account the need to accommodate the whole range of possible implementations of the interface. ...
    (comp.lang.javascript)
  • Re: Recommendations for JavaScript drop-down menu code
    ... rare browsers may not be considered a wise ... for all the standard Java libraries, ... interface and a base implementation of that interface. ... implementations that are employed in the context, ...
    (comp.lang.javascript)
  • Re: Recommendations for JavaScript drop-down menu code
    ... to not having a long enough history working with browsers to ... libraries are deferring to the comparatively greater experience of the ... interface and a base implementation of that interface. ... trying to avoid even writing. ...
    (comp.lang.javascript)
Quantcast