Picture of Peter

Peter Gutmann

Professional Paranoid

Department of Computer Science
University of Auckland
Private Bag 92019
Auckland, New Zealand

email: pgut001@cs.auckland.ac.nz (PGP key). I get an enormous amount of email, depending on my workload it can take up to a week for me to reply. Please be patient.

fnord fnord fnord fnord fnord
The present need for security products far exceeds the number of individuals capable of designing secure systems. Consequently, industry has resorted to employing folks and purchasing "solutions" from vendors that shouldn't be let near a project involving securing a system.
         — Lucky Green
My research interests cover the design and analysis of security systems and security usability, including the application of concepts from cognitive psychology to understanding how users interact with security systems, and whatever else happens to catch my interest. This is my new home page. My old home page is a lot more fun, but doesn't leave much room to present information on things I'm working on, so I've replaced it with this one.

One of my most popular resources is the godzilla crypto tutorial, totalling 973 slides in 12 parts which cover security threats and requirements, services and mechanisms, and security data format templates, historical ciphers, cipher machines, stream ciphers, RC4, block ciphers, DES, breaking DES, brute-force attacks, other block ciphers (AES, Blowfish, CAST-128, GOST, IDEA, RC2, Skipjack, triple DES), block cipher encryption modes (ECB, CBC, CFB, encrypt+MAC modes, LRW), public-key encryption (RSA, DH, Elgamal, DSA), using PKCs, Public-Key Cryptography Standards (PKCS), elliptic curve algorithms, hash and MAC algorithms (MD2, MD4, MD5, SHA-1, SHA-2, RIPEMD-160, the HMAC's), pseudorandom functions, key management, key lifetimes, key distribution, key use controls, key backup/archival, key continuity, certificates and CAs, certificate history, X.500 and X.500 naming, X.500 directories and LDAP, HKP, problems with X.500 and naming, non-X.500 approaches, qualified certificates, PGP certificates, SPKI, CAs, RAs, certificate chains, cross-certification, bridge CAs, PGP web- of-trust, certificate checking, offline revocation checking, CRL problems, online revocation checking, OCSP, other revocation protocols, bypassing PKI, running a CA, timestamping, PKI design guidelines, certificate structure, extensions, usage extensions, constraint extensions, certificate profiles, CA policies, problems with X.509, why do we need digital signature legislation, what is a signature, real-world vs.electronic signatures, non-repudiation, trust, and liability, existing approaches, examples of legislation of various types including advantages and drawbacks, the Digital Signature Law litmus test, user authentication, Unix password encryption, Hellman's time/memory tradeoff, Rainbow tables, generalising Rainbow tables, LANMAN and NT domain authentication and how to break it, GSM security, S/Key, OPIE, TANs, PPP PAP/CHAP, PAP variants (SPAP, ARAP, MSCHAP), RADIUS, DIAMETER, TACACS/XTACACS/TACACS+, EAP and variants (EAP-TTLS, EAP-TLS, LEAP, PEAP) Kerberos 4 and 5, Kerberos-like systems (KryptoKnight, SESAME, DCE), authentication tokens, SecurID, X9.26, FIPS 196, Netware 3.x and 4.x authentication, biometrics, PAM, session security overview, SSL, TLS, TLS-PSK, SGC, SSH, TLS vs.SSH, IPsec, IETF politics, AH, ESP, IPsec key management (Photuris, SKIP, ISAKMP, Oakley, SKEME), IKE, IPsec problems, OpenVPN, WEP, WEP problems, WPA, TKIP, AES-CCM, DNSSEC, DNSSEC problems, S-HTTP, SNMP, email security mechanisms, PEM, the PEM CA model, PGP, PGP keys and the PGP trust model, MOSS, PGP/MIME, S/MIME and CMS, MSP, opportunistic email encryption (STARTTLS/STLS/AUTH TLS), electronic payment mechanisms, Internet transactions, payment systems, Netcash, First Virtual, Cybercash, book entry systems, Paypal, Digicash, e-cheques, SET, the SET CA model, SET problems, 3D- Secure, prEN 1546, TeleQuick, Geldkarte, EMV, micropayments, smart cards, smart card file structures, card commands, PKCS #11, PC/SC, JavaCard/OCF, multiapplication cards, TCPA/TCG, TPMs, iButtons, contactless cards, vicinity cards, attacks on smart cards, traffic analysis, anonymity, mixes, onion routing, mixmaster, crowds, LPWA, Tor, steganography, watermarking, misc. crypto applications (hashcash, PGP Moose), TEMPEST, snake oil crypto, selling security, and the TCSEC/Orange Book.

In my copious spare time, I also act as the moderator for the comp.compression.research newsgroup, and the co-moderator of the sci.crypt.research newsgroup.

Design and Analysis of Security Systems

[PKI designs are based on] digital ancestor-worship of closed-door-generated standards going back to at least the mid 80's. [...] The result seems to be protocols so convoluted and obtuse that vendor implementation is difficult/impossible and costly.
         — William Flanigan Jr. and Deborah Mitchell
Every now and then I'll look at a security issue in some detail and try to design a reasonably good solution to a particular problem such as random number generation or secure deletion of data. The work includes:

Analysis of Security Weaknesses

PKIX seems to live in a virtual world where all software that uses PKI has correctly implemented the PKIX standards without any bugs, that all the software can interoperate with other software without misinterpretation, and that of course, none of the PKIX standards have any room for interpretation.
         — Aram Perez.
Over the years I've examined (and broken) a number of encryption and security systems, including:

These attacks and analyses were performed purely out of academic interest and/or because it was a fun intellectual exercise. I will ignore any requests to recover lost passwords, break encryption, teach you how to hack, etc etc.

Security Standards

I think a lot of purists would rather have PKI be useless to anyone in any practical terms than to have it made simple enough to use, but potentially "flawed".
         — Chris Zimman
While working with a variety of security standards, I've accumulated some information and comments on them that others may find useful. These include:

During occasional debates on the value (or lack thereof) of FIPS 140 certification one topic that seems to come up again and again is the cost of the evaluation. The generally-accepted overall cost for a FIPS 140 level 1 evaluation is about US$100,000. Some people have disputed this, claiming that it can be done for only $30,000. I'm willing to put my money where my mouth is and will pay US$30,000 cash to anyone who can take my source code and accompanying detailed design documentation and hand me in return the FIPS 140 certificate for it (it's already been through numerous private-label FIPS 140 certifications so it shouldn't be that much of a job). I've made this offer before on the mailing list where the discussion took place in early 2008, but wanted to create a more permanent public record here.

So far no-one (including those who had claimed it could be done for $30K) has taken me up on the offer.

Encryption Software

To paraphrase Laotse, you cannot create trust with cryptography, no matter how much cryptography you use.
         — Jon Callas.
Crypto lets someone say "Hi! I absolutely definitely have a name somewhat like the name of a large familiar organization, and I'd like to steal your data!" and lots of users will say "OK, fine, whatever".
         — John Levine
In my copious free time I work on encryption software. In the early '90s I helped write
PGP 2.0 and wrote HPACK, an archiver with support for strong encryption using both public-key (PGP) and symmetric-key encryption, and the first archiver to provide what is now generally known as "solid" compression, in which all files in the archive are compressed as a single meta-file, yielding greatly improved compression when there are a number of similar files. In 1994 I wrote the transparent disk encryption program SFS (Secure FileSystem) for DOS/Windows. Development for this has more or less finished at version 1.17 (if you're still using 1.10 you should upgrade to 1.17), this version is virtually indentical to the final 1.20 release. I haven't released 1.20 because I'd rather stay with the very stable 1.17 than move to 1.20.

More recently I've worked on the cryptlib Security Toolkit, an OS-independant security and encryption toolkit that provides implementations of complete security services such as S/MIME and PGP secure enveloping, SSL/TLS and SSH secure sessions, CA services such as CMP, RTCS, SCEP, and OCSP, and other security operations such as secure timestamping. Since cryptlib uses industry-standard X.509, S/MIME, and ssh/SSL/TLS data formats, the resulting encrypted or signed data can be easily transported to other systems and processed there, and cryptlib itself runs on any commonly-user operating system — cryptlib doesn't tie you to a single system.

cryptlib is available under the GPL-compatible Sleepycat dual license, which means you can use it under the GPL terms or under standard commercial terms, depending on your preference. More information on use under the commercial terms is given in the cryptlib brochure which explains the features of cryptlib and details the licensing terms (it's free for non-commercial and some types of commercial use, shareware, academic research, and so on).

cryptlib also functions as a PKCS #11 test suite of sorts, my presentation from the PKCS Conformance Workshop in April 2000 provides an overview of typical problems with PKCS #11 drivers and the tests that cryptlib performs to exercise their functionality.

Crypto Social Issues

Cryptography does not fit human life styles easily. As an example, truly secure systems would stop secretaries from forging their boss's signatures, and this would bring all large bureaucratic organizations to a standstill.
         — Andrew Odlyzko.
Cryptographer Adi Shamir, the 'S' in RSA, once said that "cryptography is bypassed, not penetrated". In the light of the Snowden revelations about the NSA, various people have proposed the use of crypto in order to evade NSA surveillance. From games consoles to smart phones, this talk looks at ten years of trying to secure things with crypto that ultimately failed, not through anyone bothering to break it but because it was much easier to just bypass it. The lesson from all of this, covered in
Crypto Won't Save You Either, originally presented at Kiwicon 7 and in updated form at AusCERT 2014 is that you need to secure every part of the system and not just throw crypto at one bit and assume that you'll be safe.

Windows Vista includes an extensive reworking of core OS elements in order to provide content protection for so-called "premium content". This incurs costs in terms of system performance, technical problems and associated support overhead, and hardware and software cost. These issues affect not only users of Vista, but the entire PC industry. Windows Vista Content Protection looks at the problems involved in trying to retrofit content protection/DRM to the historically open PC architecture. The much older Cost Analysis of Windows Vista Content Protection originally looked at this issue some time ago, but this writeup is now quite out of date and is only kept online for historical purposes because numerous sites still link to it.

In late 1995 I co-authored the paper Government, Cryptography, and the Right to Privacy, which documents the long history of government (specifically, intelligence agency) interference into open research on cryptography, and covers various issues such as the right to privacy and the erosion of that right by governments. The paper includes a fairly exhaustive (15 pages) list of references as of late 1995. The paper was published in the Journal of Universal Computer Science, Vol.2, No.3 (March 1996). Note that it's now extremely dated, and serves mostly as a historic reference on the state of affairs in the 1970s and 1980s.

Traditionally, New Zealand and Australia have waited until a new policy has failed in the US before adopting it here (no really, this is a standard joke made in NZ/Australia). In two instances however, we managed to get it wrong long before the US did, first with the (aborted) Technology and Crimes Reform Bill (our version of the CDA) and at roughly the same time with the anti-circumvention provisions of the 1994 Copyright Act, which beat the DMCA by several years. In 2001 the Copyright Act was up for revision, and I made a submission which argues that not only does the Act not need to be further tightened, but it's already too restrictive as it stands. This contains an in-depth analysis of the problems inherent in the Act (and similar legislation like the DMCA), and covers some of the ways in which similar legislation has been misused in the US by companies to deprive users of fundamental rights in a manner that would be unheard-of with traditional media such as books.

In 2007 the government had another go at the Copyright Act. Unfortunately some of the proposed changes appeared to be heavily influenced by content providers, with the resulting legislation being very disadvantageous to New Zealanders. The Copyright Amendment Bill: Problems and Solutions looks at two technology-related changes to the act which cover format-shifting and DRM, the impact that this will have on consumers, and potential fixes for the problems created by the proposed changes.

In addition to this I have been active in the crypto debate on various mailing lists, in newsgroups, and occasionally in the media.


Arguing with an engineer is like wrestling with a pig in mud. After a while, you realise the pig is enjoying it.
         — Jamie Lawrence.
One of my hobbies is photography. You can see some examples
here. Some of my favourites are One Tree Hill, Auckland, the Whangarei heads, Whangaroa harbour in the far north, Cathedral Cove on the east coast, Paeroa in the Coromandel, Tiritiri Matangi Island near Auckland, some Agathis Australis, NZ native bush, Te Waihou near Hamilton, Bethell's Beach on the west coast, Piha on the west coast, the Naturhistorisches museum in Vienna, St.Stephen's cathedral in Vienna looking suitably spooky, an HDR shot of Vor Frue Kirke, Copenhagen, another HDR shot shot of the church, Karlskrona, Sweden, a house in Parnu, Estonia, St.Andreas church in Bavaria, another shot of the church, Cambridge, UK, an HDR shot of the Bodleian library (in need of white-balance correction, sigh), Smolny cathedral in Russia, a jugendstil house in Riga, a tree-rat... uhh, squirrel in Hyde Park, London and another tree-rat, waxeyes in foliage on Rangitoto island, an Avondale spider, unknown bugs in Arizona, a ponga fern frond, native bush near Rotorua, and finally moss on Rangitoto island.

Unlike most other power-hungry embedded devices which are powered through sensible barrel jack power cables, the Raspberry Pis continue to use USB power long after it became obvious that this was a really dumb idea. The problem with this is that the vast majority of micro USB cables used for everything but the latest Pi models are incapable of passing the level of current required to run a Pi, which means you either need to go and buy a custom Pi-specific power supply, thereby defeating the point of using a cellphone charger in the first place, or spend forever trying to find a cable that can feed enough power to it that it won't glitch or fail. After dealing with endless glitching problems I ran tests on a range of micro USB cables to see which ones can reliably power a Pi. Result: Almost none can, and certainly no cable over 1m in length can. If all you care about is which cable to get to run a Pi, get an Anker.

From February through April 1998, the city of Auckland experienced what has been described as the worst peacetime power outage ever. While the central city had no power, I maintained a continuously-updated writeup of the situation on a site outside the affected area, I've now moved this back here where you can read about Auckland, your Y2K beta test site.

Every year I serve on the program committees of a number of computer conferences, which means that I get given a pile of papers to review for publication. Every year I see the same problems with submitted papers. And every year I decide that I should write down some guidelines on things to look out for when writing a computer conference/journal paper. This year I've finally got around to it.

Open-source software development can be handled in a variety of ways. Ever since the bottomless wells of dot-com funding dried up, it's been somewhat difficult to sustain development on projects that don't have either the visibility to attract corporate sponsors (Linux kernel, Apache, MS Office clones) or the mass appeal to attract individual contributors (KDE/ Gnome, Mozilla, assorted audio/video codecs and players. At the opposite end of the scale are the vast amounts of abandonware that never made it out of the design stage, or are stuck in pre-alpha, or fragmented into several further pieces of abandonware. How then do you sustain an open source development project that falls between these two extremes? The dual-license strategy used by efforts such as Sleepycat DB and MySQL are one very effective way to do this. Sustainable open source software development covers some of the possible open source software development models, and then looks at the dual-license model in some detail, covering the benefits as well as various pitfalls and gotchas you may run into when you follow this path.

The NSA maintains various regional SIGINT operations centers (RSOC's) around the world, including one at Bad Aibling in Germany. There are very few photos of the Bad Aibling RSOC around, only one or two rather old, grainy illustrations that presumably came from newspaper articles. When I was in the area in the summer of 2000 I took the opportunity to wander round and take a few photos.

At a gathering of security people that included an Enigma machine, I was asked to give a short overview of the Enigma. The Enigma Cipher Machine is a short history of its developent, weaknesses, and attacks.

Over the years I've also put assorted other things online, most of which I've lost track of. One of the things I still have is my writeup on wetas (currently missing the illustrations), a little-known New Zealand lifeform that looks like a cricket designed by H.R.Giger. Other bits and pieces include a study of gnodes, the specification for gnxt, the world's most amazing text editor, what happens when you cross the Goon Show and Computer Science Department, and a comment on the decline of civilisation as we know it through the agency of noodles. Finally, there's my interpretation of the IETF PKIX meeting minutes from the 56th IETF, and the machine that issues certificates.

For a while I worked in an environment where people were expected to use Lotus Notes for email (I didn't, sticking as ever with /bin/mail). Listening to discussions about the wonders of Notes inspired the creation of Notespotting, which was in turn inspired by Trainspotting via Adminspotting. You'll need a PDF viewer (the text uses Trainspotting-poster-style formatting) and an appreciation of the strong language used in Trainspotting for this one (the latter seems to come built-in in most Notes users).


Occasionally I get requests for a CV or bio or something, as if that were important in some way. Well, here's my bio:

Peter Gutmann arrived on earth some eons ago when his physical essence filtered down from the stars, and he took human(?) form. Lingering for awhile on the plateau of Leng while waiting for the apes to evolve, he eventually mingled among human society, generally without being detected, although the century he spent staked out in a peat bog in Denmark was rather unpleasant and not something he'd care to repeat. Once computers were invented he became involved in security research in the hope that enough insider knowledge would, at the right time, allow him to bypass electronic security measures on the first translight spacecraft and allow him to return to the stars. This is probably still some time away. Until then he spends his time as a researcher at the University of Auckland, poking holes in security systems and mechanisms (purely for practice), and throwing rocks at PKIs.
Now you know.

If you want to whisper sweet nothings in my ear, here's my PGP key. You can verify this with my older PGP key (don't use this for anything else, since the private key was destroyed long ago). If you're using GPG, use the --pgp2 or --pgp6 options to make it somewhat more compatible with non-GPG implementations of PGP. Also, please be aware that I read encrypted email on a non-network-connected machine, so this will add a certain amount of latency to any replies to encrypted mail.

Version: PGP 2.3


Any opinions expressed on this page are not in fact mine but were forced on me at gunpoint by the University of Auckland.