Thursday, December 21, 2017

How do you authenticate this blog? Why not use Tesla / DCKR?

If I used HTTPS, then you might decide to trust each and every one of the zillion CAs selected by your operating system and/or browser, to not vouch for this site unless someone paid them money for a certificate and if that person also had control of this domain, and then you might hope that person furthermore happens to be me. This seems to be a popular choice.

Or... you can view a summary of the site, current as of 12/21/2017, here:
https://drive.google.com/open?id=1Us2BfQL76H17Py6GYRnSD5I4KA-fOYCK

You could also download and record this signature for safe keeping (quickly - it expires Monday!)

You could then come back a week (or more) later to see if I have signed anything else. If I have, you could download that signature as well, then check the three inputs (signature, data, newer signature) with this python 3 script:

That program would use the more recent signature for the purpose of extracting the key used to sign the first signature, so it can then check that signature for validity. It would then go on to confirm that this key relates to my public key. Of course, encoded in that script is my public key, and maybe someone tampered with it or else with the algorithm itself? So as a one-time exercise, you would want to confirm that you truly have the correct script. This would have to be done out-of-band, for example you could call me and ask me to confirm the sha1sum checksum (which happens to be 28867e62adb0271779f75509cc91f76acdb9afca, not that you should trust this post on that last point.)

This script is of course a prototype, but why not give it a spin? Later, I might implement a crossword puzzle signature as well.

No comments:

Post a Comment

RFC 2119 harmful in acornics protocol design

I see RFC 2119 terms like MUST, SHOULD, and MAY used in acornics protocol specifications, such as the BOLTS defining the lightning network ...