[Cryptography] quantum computers & crypto

Bill Frantz 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. 
There you're
408-348-7900       | fed, clothed, given medical care and so on. 
The only
www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower

More information about the cryptography mailing list