[Cryptography] quantum computers & crypto
frantz at pwpconsult.com
Sun Oct 31 22:58:20 EDT 2021
On 10/31/21 at 12:50 PM, leichter at lrw.com (Jerry Leichter) wrote:
>2. Just what would constitute a sufficient proof of
>decertification? Is is a signed note from a bunch of
>pre-accepted authorities attesting to a problem? Signed with
>what algorithm: The current one, so that you get a message
>using a particular algorithm asserting that the algorithm is no
>good? Oddly, that kind of works ... but it seems very
>peculiar. If not that ... then what? Signed using the *next*
>algorithm? Or one of the other "future" algorithms? That
>falls right into the ambush of the previous item! Signed using
>some other algorithm? Does it have to be stronger than any of
>the seven? If so, why aren't you just using it?
Since signing a decertification certificate or checking the
signature is not performance sensitive given the rarity of
having to do it, I would sign using all the signature algorithms
and check all the resulting signatures.
>I agree that there's something very tempting about this approach. Actually, I've proposed a broader application of a simpler version for trustable hardware/software: You build a secure kernel that's so simple that you can really prove it secure *and never allow any patching.* A patch mechanism is a potential attack vector, and one that immensely opens the potential attack surface. Leave it out. If it turns out you got it wrong, replace the whole thing with a new one designed along similar principles.
I like this approach, but having worked on a secure OS kernel, I
think there may be some practical problems. The details of how
various devices work can be critical, and the devices may not
exist when the kernel is finalized.
An example we ran into with KeyKOS was how IBM disk controllers
handle writing to the disk when the I/O channel can't provide
the data in a timely fashion. It is actually specified, although
I think the specification is buggy in and of itself. The spec is
to write the last received byte for the rest of the disk block
and generate a good error checking syndrom. We had to program
around this "feature" and would have been much happier if it had
written a bad error checking syndrom so we just got an I/O error
reading the block.
Cheers - Bill
Bill Frantz | If you want total security, go to prison.
408-348-7900 | fed, clothed, given medical care and so on.
www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower
More information about the cryptography