Re: what should "k-bit security" mean?
From: John E. Hadstate (nospam_at_null.nil)
Date: 08/30/03
- Next message: John E. Hadstate: "Re: what should "k-bit security" mean?"
- Previous message: Cristiano: "Re: Factoring program"
- In reply to: David Wagner: "Re: what should "k-bit security" mean?"
- Next in thread: David Wagner: "Re: what should "k-bit security" mean?"
- Reply: David Wagner: "Re: what should "k-bit security" mean?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 30 Aug 2003 12:12:55 -0400
"David Wagner" <daw@mozart.cs.berkeley.edu> wrote in message
news:bio6nh$9k4$3@agate.berkeley.edu...
> John E. Hadstate wrote:
> >Based on my recent and ongoing experiences, the NSA and DoD disagree with
> >you. They do, in fact, evaluate and certify cryptosystems and other
> >security devices based on the application in which they will be used.
>
> Do you mean to suggest they re-evaluate Skipjack *from scratch* every
> time someone discovers a new place it can be used? That seems surprising.
>
I doubt that they would re-evaluate Skipjack "from scratch" but I am certain
that they would play close attention to the implementation of Skipjack. I
am reasonably certain that they would question the choice of Skipjack unless
they were evaluating some new add-on for DMS that required Fortezza
compatibility. After all, any new application in which Skipjack might be an
acceptable design choice is now (as of 2002) required to be protected by
AES.
> Imagine if every time I wanted to use a sorting routine, I had to re-do
> the performance analysis and proof of correctness for Quicksort and
> re-test the implementation. What a waste of time and money! Far better
> to just call qsort().
Nevertheless, that's one effect of the certification process. They look at
design choices (so I don't design a crypto system to protect T/S info using
AES), they look at usage of those components (so I don't build in the
potential for leaking information through abuse of an otherwise legitimate
design) and they look at implementation details (to insure that I haven't
sold them a bill of goods or implemented software that leaks information
through timing attacks).
So far as the time and money requirements are concerned, I suspect that is
one factor that has driven NSA, in conjunction with NIST, to farm-out most
of their SBU or commercial-grade evaluations to certified commercial
laboratories. NSA still retains the sole certification authority when it
comes to certain legacy DoD systems and they don't even blush when they tell
you how long it will be before they can assign someone to look at your
project.
>
> Re-useability is good. Sure, some aspects of the security analysis must
> be done afresh for each new application, but many parts can be reused,
> and that's a good thing.
So long as those parts are combined and re-used in appropriate ways, with
safeguards to insure that they haven't been tampered with.
It is this last point that calls in to question the concept of a blanket
"K-bit Security". As you know, you can combine off-the-shelf AES and SHA-1
and any number of other highly secure crypto components in ways that leak
information. How do you find such problems except by a detailed examination
of the design and implementation? Are you willing to say that a design and
implementation that minimizes leaks in one application, minimizes them in
all applications?
- Next message: John E. Hadstate: "Re: what should "k-bit security" mean?"
- Previous message: Cristiano: "Re: Factoring program"
- In reply to: David Wagner: "Re: what should "k-bit security" mean?"
- Next in thread: David Wagner: "Re: what should "k-bit security" mean?"
- Reply: David Wagner: "Re: what should "k-bit security" mean?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|