Peter Gutmann

If you like this, you will probably be interested in this:

Everything you Never Wanted to Know about PKI but were Forced to Find Out, by Peter Gutmann: https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

Also, this, by the same person: X.509 Style Guide (which talks about the two date formats):

“In coming up with the worlds least efficient machine-readable time encoding format, the ISO nevertheless decided to forgo the encoding of centuries, a problem which has been kludged around by redefining the time as UTCTime if the date is 2049 or ealier, and GeneralizedTime if the date is 2050 or later (the original plan was to cut over in 2015, but it was felt that moving it back to 2050 would ensure that the designers were either retired or dead by the time the issue became a serious problem, leaving someone else to take the blame).

To decode a date, if it's UTCTime and the year is less than or equal to 49 it's 20xx, if it's UTCTime and the year is equal to or greater than 50 it's 19xx, and if it's GeneralizedTime it's encoded properly (but shouldn't really be used for dates before 2050 because you could run into interoperability problems with existing software). Yuck.

To make this even more fun, another spec at one time gave the cutover date as 2050/2051 rather than 2049/2050, and allowed GeneralizedTime to be used before 2050 if you felt you could get away with it. It's likely that a lot of
conforming systems will briefly become nonconforming systems in about half a…

You probably don't want to believe anything in this: The author is a well known scammer/con-artist (Craig Wright) who has a long running advanced fee fraud scheme predicated on convincing suckers that he created bitcoin and has some secret stash of billions that he could get to only if his victims help him with some cash flow problems.

He has a long history of using forgeries, faked documents, plagiarism, and impersonation in order to pass himself off as some kind of credible.

This article is debunked in the "Further Epilogue" of https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

Moreover, the images of their supposed MFM imaging was just copied off a manufacturer's page ( https://web.archive.org/web/20090418043851/https://www.engr.sjsu.edu/WofMatE/Mat'sChar2.htm shows another copy on a similarly old page, citing the source) -- so it seems unlikely that they ever performed any measurements at all. A big chunk was plagiarized from an uncited source ("A Practical Guide to Scanning Probe Microscopy (1993)")... another hallmark of Wright's lame forgeries.

There was a phenomenal twitter thread that went over all this and more, but Wright used spurious legal threats to drive the author off twitter. The biggest loss was where it pointed out that one of the citations in this paper is where they tried to cite Nikola Tesla in [20], but used the title of the 1989 album The Great Radio Controversy by the rock band Tesla (…

It is just like signing certificates for servers of any type but the subject is you.

I recommend using P12 as most browsers will 'just get it'. With Nginx for example, you can build in SSL support and then configure a directive to request a client cert at which point the web browser will load a relevant certificate to choose to pass along. More so, Nginx can be configured to extract information from the client certificate and use it as variables.

http://wiki.nginx.org/HttpSslModule#ssl_client_certificate
http://wiki.nginx.org/HttpSslModule#Built-in_variables

So one can have ssl.awesome.io and extract info to only allow 'Joe231' to see ssl.awesome.io/Joe231. Even better is by serial or what have you.

Now my 2 cents on the problem; it confuses people, revocation and issuance. I'm guessing here DoD had certificates built into our ID cards and that was extracted with the reader at a need. Not sure, just a guess. Personally I think the cryptic nature that is command line Openssl is what slows down the mob from pushing new tech unto everyone. Think about it. Some comments present are disappointing for hacker news; you should be playing with cryptic technologies and making them work.

Want a startup idea? Plop certs into AXE body spray cans and done.

oh looky what Wikipedia cited: http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

"In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, 'A good scrubbing with random data will do about as well as can be expected'. This was true in 1996, and is still true now."

From the article: "Both Quick Erase and DoD Short should be more than enough to prevent people from snooping on your data — but if you want to be really certain that no one, including the feds, can read your data, use 8-pass PRNG Stream."

On a modern drive, quick erase (a single pass writing random data) is good enough to keep anyone from reading your data. As Peter Gutmann says in the Further Epilogue to his famous paper [0]:

"Any modern drive will most likely be a hopeless task, what with ultra-high densities and use of perpendicular recording I don't see how MFM would even get a usable image, and then the use of EPRML will mean that even if you could magically transfer some sort of image into a file, the ability to decode that to recover the original data would be quite challenging."

[0] http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

The use of SHA-2-224 is kinda weird.

Based on a quick skim:

* no kdf on the password, just SHA-2-224(password)

* uses the same key and iv (which always starts as 0) in both directions

* uses CFB mode without a MAC, which has malleability issues (IIRC you can flip bits in a ciphertext block, and the same bits will be flipped in the plaintext, but the rest of the stream will be garbage).

* the authentication used is pretty sketchy (the key is fixed at 16 bytes and PW_LEN 15, so ljust shouldn't be doing anything):

if tmp_data[:len(self.key)].ljust(PW_LEN,'0') != self.key.ljust(PW_LEN, '0'):
log.msg("Remote unauthorized", logLevel=logging.INFO)

Reminds me of this: https://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt