Re: TrueCrypt 4.0 Out
tomstdenis_at_gmail.com
Date: 11/03/05
- Next message: clark: "Re: TrueCrypt 4.0 Out"
- Previous message: Jeffrey F. Bloss: "Re: TrueCrypt 4.0 Out"
- In reply to: BRG: "Re: TrueCrypt 4.0 Out"
- Next in thread: BRG: "Re: TrueCrypt 4.0 Out"
- Reply: BRG: "Re: TrueCrypt 4.0 Out"
- Reply: BRG: "REPOST: Re: TrueCrypt 4.0 Out"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 3 Nov 2005 10:18:50 -0800
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.
> > 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
- Next message: clark: "Re: TrueCrypt 4.0 Out"
- Previous message: Jeffrey F. Bloss: "Re: TrueCrypt 4.0 Out"
- In reply to: BRG: "Re: TrueCrypt 4.0 Out"
- Next in thread: BRG: "Re: TrueCrypt 4.0 Out"
- Reply: BRG: "Re: TrueCrypt 4.0 Out"
- Reply: BRG: "REPOST: Re: TrueCrypt 4.0 Out"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
