Peter Gutmann

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.

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

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

• A paper on the Secure Deletion of Data from Magnetic and Solid-State Memory, which exposes a number of myths about the deletion of data, shows how data can be recovered long after it should have been erased, and indicates a method of erasure that should make it a considerable challenge to recover any deleted data. This paper was presented at the 1996 Usenix Security Symposium, but you had to attend the conference to see the cool colour slides of supposedly overwritten disk data which wasn't really overwritten (they were too big to fit in the paper itself).

  In August 2001 I finally published the followup to this paper which looks at Data Remanence in Semiconductor Devices, specifically remanence issues in static and dynamic RAM, CMOS circuitry, and EEPROMs and flash memory. This paper was presented at the 2001 Usenix Security Symposium, the slides for the talk provide a quick overview of the issues, although for real understanding you should read the full paper.

• There have been a wide number of cryptographic random number generators fielded, ranging in quality from awful (Kerberos 4, SESAME, and the original Netscape generator) through to very good. Although there are a number of papers that give very broad recommendations on random number generation, none seem to give very specific details or real-life analyses of a particular method. The paper Software Generation of Practically Strong Random Numbers, presented at the 1998 Usenix Security Symposium, provides a design for a reasonably OS-independant random data accumulator and generator and an analysis of its performance.

  In June 2000 I updated this paper to include a lot more information than there was room for in the original, more than doubling the original size. The new version of the paper is more than twice as long as the original and looks at the requirements for a software-based generator, examines some existing ones (Applied Cryptography, ANSI X9.17, PGP 2.x, PGP 5.x, /dev/random, Skip, ssh, SSLeay/OpenSSL, Capstone/Fortezza, and the Intel Pentium III) and points out problem areas, and then presents an updated and extended design for what I hope is a reasonably secure and appropriately paranoid generator.

  Related to this work is a talk I gave at the NIST Random Number Generation Workshop that looks at Testing Issues with OS-based Entropy Sources. This provides considerably more technical detail on both entropy sources in a typical PC and the entropy evaluation methodology that can be used to analyse them, as well as some design and usability issues affecting real-world PRNGs.

• Although there are several crypto API's around, most of them are just collections of crypto-related functions with no real internal architecture design, and many are rather language-specific or nonportable. In addition none of them appear to provide any coherent security model, and some lack real security features altogether (for example it's possible for an application to read out encryption keys which should be protected inside the architecture). The paper The Design of a Cryptographic Security Architecture, presented at the 1999 Usenix Security Symposium, provides a design for a general-purpose crypto architecture with a high-security kernel to enforce security policies. The slides for the talk provide an easier-to-read overview of the architecture and its security features. This architecture has been implemented in the cryptlib security toolkit, which provides a comprehensive range of encryption, digital signature, key and certificate management, and message security services (for example the creation of S/MIME signed and encrypted messages), with support for a wide variety of crypto hardware and a flexible key database interface that allows keys to be stored in flat files, relational databases, smart cards and Fortezza cards, LDAP directories, and web pages.

• Current crypto implementations rely on software running under general-purpose operating systems alongside a horde of untrusted applications, ActiveX controls, web browser plugins, mailers handling messages with embedded active content, and numerous other threats to security, with only the OS's (often almost nonexistant) security to keep the two apart. The paper An Open-source Cryptographic Coprocessor, presented at the 2000 Usenix Security Symposium, presents a general-purpose open-source crypto coprocessor capable of securely performing crypto operations such as key management, certificate creation and handling, and email encryption, decryption, and signing, at a cost one to two orders of magnitude below that of commercial equivalents while providing generally equivalent performance and a higher level of functionality. The slides for the talk provide more detail on this. An extended form of the paper contains more detail on the design as well as illustrations of coprocessors that couldn't fit in the Usenix version.

• Although the basic building blocks for working with strong encryption have become fairly widespread, experience has shown that implementers frequently misuse them in a manner which voids their security properties. At least some of the blame lies with the tools themselves, which often make it unnecessarily easy to get things wrong. Just as no chainsaw manufacturer would think of producing a model without a finger-guard and cutoff mechanism, so security software designers need to consider safety features that will keep users from injuring themselves or others. Lessons Learned in Implementing and Deploying Crypto Software looks at some of the major problem areas and provides a series of design guidelines that can help minimise damage due to (mis-)use by inexperienced users. This paper was presented at the 2002 Usenix Security Symposium, the slides for the talk sumarise the main points and add additional commentary and information whcih it wasn't possible to include in the main paper.

• Standards for secure email and network communications have been around for years, every Windows (and many non-Windows) desktop has S/MIME, SSL, and IPsec built in, US export controls on crypto are (effectively) gone, and yet we still see daily reports of security problems and all manner of crime and fraud being committed using Internet-connected systems. Why isn't the Internet Secure Yet, Dammit!, presented at the 2004 AusCERT Conference, looks at some of the lesser-publicised aspects of Internet security, and the security measures being applied there. Topics covered include measures to prevent automated address harvesting and use, spam-prevention techniques and problems therein, credit card fraud and online banking security issues like phishing attacks, and the use of opportunistic encryption mechanisms to provide a measure of easy-to-use and easy-to-manage security for people who wouldn't otherwise employ it.

• A lot of fuss has been made about PKI in the last few years, tempered more recently by a combination of its lack of ability to deliver and the drying up of bottomless wells of dot-com funding. The godzilla crypto tutorial provides in-depth coverage of certificate issues and technology, but was written for a technical audience. To complement this, another tutorial covering everything you never wanted to know about PKI but have been forced to find out provides a less technical overview aimed at people charged with implementing and deploying the technology. If you need to know what you're in for when you work with PKI, this is definitely the one to read.

  Complementing this is a look at some future avenues for PKI work, which examines ways in which a PKI may be adapted to tackle a particular problem, rather than the usual approach of designing/building a PKI and then trying to identify a problem that it solves. PKI: It's Not Dead, Just Resting, published in the August 2002 edition of IEEE Computer magazine examines a variety of ways of applying PKI technology to real-world problems, and of adapting the technology to meet real-world requirements.

  An extended-length paper with the same name covers the same material, but with considerably more technical detail. If you just want a readable, general overview, read the IEEE Computer article. If you want all the gory technical details and analysis, read the extended version.

• Most of today's security protocols, and a lot of today's crypto, is built around the assumpting that memory is infinite, CPU is free, and any other resources you need are magically available in the hardware. Unfortunately IoT and SCADA doesn't work like that: Memory may be 64kB, CPU may be 20MHz, and there's no hardware resources needed for crypto present. IoT / SCADA Crypto Considerations looks at some of the issues you'll need to take into account when working with crypto on embedded devices.

• In order for e-commerce to work, we apparently need some sort of digital signature law, although we're currently moving in the low trillions of dollars each day electronically without the help of such a law. The digital signature legislation tutorial (another part of the godzilla crypto tutorial) looks at why this may or may not be the case, why it's extremely hard to create a digital signature law, the approaches being used (or at least tried) by various countries, and how people are currently doing e-commerce without this type of legislation.

• There has been a great deal of difficulty experienced in getting research performed by cryptographers in the last decade or so (beyond basic algorithms such as SHA and AES) applied in practice. The reason for this is that cryptographers don't work on things that implementors need because it's not cool, and implementors don't use what cryptographers design because it's not useful or sufficiently aligned with real-world considerations to be practical. The Crypto Gardening Guide and Planting Tips covers some of these real-world constraints for cryptographers, pointing out problems that their designs will run into when attempts are made to deploy them in practice.

• In the real world, risk is never binary but always comes in shades of grey. When security systems treat risk as a purely boolean process, they're prone to failure because the quantisation that's required in order to produce a boolean result has to over- or under-estimate the actual risk. What's worse, if an all-or-nothing system like this fails, it fails completely, with no fallback position available to catch errors. Drawing on four decades of experience with security design for the built environment (buildings and houses) known as crime prevention through environmental design (CPTED), PKI as Part of an Integrated Risk Management Strategy for Web Security, presented at EuroPKI 2011, looks at how CPTED is applied in practice and, using browser PKI as the best- known example of large-scale certificate use, examines certificates as part of a CPTED-style risk-mitigation system that isn't prone to all-or-nothing failures and that neatly integrates concepts like EV vs. DV vs. OV and OCSP vs. non-checked certificates into the risk- assessment process, as well as dealing with the too-big-to-fail problem of trusted browser CAs.

• Security people often respond to security problems by throwing crypto at them. After all, if crypto is good then more of it has to be even gooder. However, there are some problems that simply can't be solved by crypto, no matter how much of it you use. Conversely, some problems can be addressed using far simpler mechanisms than the ones that cryptographers come up with, often by moving the goalposts slightly to make the problem solvable, if less cryptographically interesting. Hard and Not-necessarily-hard Problems in Cryptography looks at some problems that can't be solved through cryptography even if at first glance they may appear solvable, as well as ones that can be solved if you're prepared to turn them into slightly different problems.

• In 1995, Netscape rolled out SSL, a protocol that's crucially dependent for its security on certificates created by third-party CAs, but for the first 1 1/2 decades of its existence no-one had ever tried to measure how effectively these were being handled. When a volunteer-run project by the EFF did finally examine the situation, they found a chaotic mess that still hasn't been fully untangled. Telcos faced the same problem in the 1990s when they found that, to their considerable surprise, their billing systems were incapable of properly managing mobile phone billing. The result was the field of revenue assurance, a systematic effort to measure and evaluate the performance of mobile phone systems, at least as it applied to billing users. From Revenue Assurance to Assurance: The Importance of Measurement in Computer Security, the keynote for Metrisec 2012, looks at various failures of measurement both in and outside the field of computer security, and applies lessons from the area of revenue assurance to computer security mechanisms.

• One aspect of the security process that's often overlooked is threat modelling (or if you're from the US, "threat modeling", which sounds like something involving a runway, a slinky dress, and a sawn-off shotgun). For KiwiCon 2009 I had a look at the topic of threat modelling, not so much in terms of, well, threat modelling, but how it can help shape the assumptions that we make about the types of threats that we're facing. Starting with some notable examples of (fatally) incorrect assumptions made during historical threat modelling exercises, I went on to look at some more recent failures and failure patterns that DFD-based threat modelling can help identify. While none of the threats discussed are particularly novel, the formal threat-modelling process provides a more rigorous approach than the usual "try this one and see if it works".

• By now it's become obvious to most people that an X.509-style PKI doesn't work very well. The quote at the top of this page sums up the origins of some of the technical problems: There's a dysfunctional identification system (X.500 DNs), a dysfunctional distribution system (X.500 directories), and a dysfunctional validity-checking mechanism (CRLs). So what technology would work? The PKI Technology Survey and Blueprint, presented at the 2006 New Security Paradigms Workshop looks at the question If you asked experienced programmers, sysadmins, and technical project managers how they would implement certificate management, what would the technology framework for your PKI look like?, and creates a PKI technology blueprint based on the recommendations made by respondents. The resulting design is noteworthy in that it is almost completely unlike the one proposed in X.509 and related standards, which would indicate that at least some of the deployment difficulties being encountered with X.509-style PKIs are due to their sub- optimal choice of technology.

• A common complaint about PKI is that it's simply too hard to use at the end-user level. Somewhat surprisingly, there exists no PKI equivalent of DHCP or BOOTP for automated, transparent PKI setup, leaving the certificate user experience similar to the process of bringing up an X.25 link. After swearing I'd get out of the PKI rut, I had one last look at trying to make it a bit more workable with Plug-and-Play PKI: A PKI Your Mother Can Use presented at the 2003 Usenix Security Symposium, a PKI equivalent of the basic TCP/IP bootstrap services that provides automatic, transparent configuration and setup of certificate information, with the user needing to supply no more than their user name and password (slides for the talk are also available). The overall purpose of the work was to design and implement a plug-and-play certificate setup mechanism usable by even the most inexperienced user, a "PKI your mother can use".

• Availability/dependability considerations assert that "in case of any issues, keep going at any cost" while security mandates "in case of any issues, raise the alarm and shut things down". In other words once you've found the single bit that's out of place, you've won and there's no need to think about continuing. Needless to say, these two concepts are more than a little incompatible. Availability and Security: Choose any One, presented at Financial Cryptography 2020 looks at the thorny issue of availability/ dependability vs. security, complete with hair-raising examples, as instances of wicked problems, a concept taken from the field of social planning. To the annoyance of geeks everywhere, the talk concludes without presenting any obvious solutions.

• It's been known for some years now that encryption can be highly susceptible to fault attacks in which a memory or CPU glitch leads to a catastrophic failure of security. These types of faults occur mostly in conference papers, but there's one situation in which they're expected as part of normal operations: When the crypto is operated in a high-radiation environment like a nuclear reactor. Radiation-induced cryptographic failures and how to defend against them, presented at Kiwicon 2016, looks at the effects of radiation on computer security mechanisms (and computers in general), and outlines means of protecting crypto in environments where you need to expect data and computation results to modify themselves at random.

• Software security is usually concerned with issues like buffer overflows, SQLI, integer overflows, format string vulnerabilities, and the usual OWASP top ten catalogue. What's rarely considered is its behaviour in the presence of faults which, combined with security-related code and in particular cryptography that's horribly sensitive to faults, leads to problems when the software is deployed into environments where faults are not only expected but a normal part of operations. Software Security in the Presence of Faults, originally presented at the 2019 AISA Conference and then in considerably updated form at SecTalks Sydney 2020, looks at situations where faults arise, and the range of software measures that can be used to defend against them affecting security-critical code.

• The last few years have seen an increasing number of stories of security researchers doing scary things to automotive control systems. The solution proposed for this problem is to throw cryptography at it, because as everyone knows if crypto isn't solving your problem then it's only because you're not using enough of it. Automotive Control Systems Security: How we got here and How to get out again, presented at Kawaiicon 2019, looks at the issues involved in working with automotive control systems, focusing on the automotive industry's AUTOSAR approach, and examines more practical alternatives that address real- world concerns in automotive environments.

• Despite two decades of work, X.509 PKI isn't doing very well. Deployment is minimal, and even when it's used it's frequently just security theatre: Keys are generated for users by the CA and mailed out to them, and users go through the motions of checking keys without really caring, because it's just too painful to get it right. Much of the blame for this lies in a design that looks like it was created by the e-commerce division of the Ministry of Silly Walks. The result is security technology that, as one developer at a large US security vendor put it, "I wouldn't trust to control access to a beer fridge".

  It doesn't have to be that bad though. By sidestepping some of the most dysfunctional aspects of the original OSI design (X.500 directories, Distinguished Names, CRLs), it's possible to build a highly functional, easy-to-use PKI based on the original X.509 blueprint. How to build a PKI that works, presented at the 2004 PKI Workshop, shows how to do this.

• Some years ago I proposed a simple extension to X.509 to allow users to issue their own encryption certificates which they could renew and roll over as required. This means that it's no longer necessary to ask a CA for permission to encrypt data, keys can be rolled over regularly at no cost, and if a key is compromised it can be quickly replaced. This proposal was rejected by the PKIX working group with the comment that "we don't want to turn X.509 into PGP". Since I still get asked about this sort of capability occasionally, I've put the X.509 Profile for Autonomous Certificates online.

• The Internet has spawned a large number of security technologies, of which some of the better-known are SSL/TLS, SSH, PGP, S/MIME, and IPsec. Alongside their better-known cousins, a variety of lesser-known but still very effective and highly useful technologies are helping to secure the Internet, although sometimes not as effectively as they could since their lack of visibility leads to a lack of use. Underappreciated Security Mechanisms covers techniques such as user identification/human identification, opportunistic encryption (potentially the saviour of secure email), and key continuity management (which does the same for PKI).

• Fuzzers have been around for quite some time, but for most of that time period they've been pretty difficult to use. American Fuzzy Lop (AFL) has changed all that, making instrumentation-guided fuzzing readily accessible to developers. Fuzzing with AFL provides and overview of what AFL does and a quick rundown on how to use it to check your software.

• The secure storage of passwords on servers has been a long-standing problem that rears its head again and again. In 2013 a group of security people lead by cryptographer Jean-Philippe Aumasson initiated the Password Hashing Competition (PHC), an attempt to design a new, state-of-the-art password- processing algorithm using the competitive process that gave us AES and SHA-3. The Password Hashing Competition looks at the recently-completed PHC process, both from the technical side (it inspired enormous advances in the state of the art in password-processing design) as well as the ins and outs of running a competitive process to select an algorithm that has to withstand attack by CPUs, GPUs, FPGAs, and ASICs (think Bitcoin miners), not to mention a peanut gallery of geeks all over the world. The focus of the talk is more on the mechanisms of the selection process and the decisions and tradeoffs that were made than on the low-level technical details.

• Comparisons of the most popular application-level security protocols, PGP and S/MIME for independent message protection and SSH and SSL/TLS for communications session protection, are usually made at the political rather than the technical level. Performance Characteristics of Application-level Security Protocols (currently still in draft form, but posted because various people have asked for it) provides a detailed breakdown and analysis of the performance characteristics of the different protocols, identifying potential performance problem areas and providing guidance for protocol designers and implementers.

• In August 2000 I finally submitted my PhD thesis "The Design and Verification of a Cryptographic Security Architecture", wrapping up my long career as a tenured graduate student. I've put a few chapters online for those who are interested, with the University ResearchSpace archives containing the more complete form. The thesis has also been published in book form. I'd recommend getting the book form, since it's a considerably revised and updated version of what's in the thesis.

• One section of my thesis, which covered certificate stores, had to be dropped due to size constraints. As with the work in the other chapters, it begins by analysing the requirements for a reliable, scalable, general-purpose certificate store, and then examines various potential candidates that might meet these requirements. The single chapter ended up broken down into two papers because of its size, the first paper (published at ACSAC 2000) mostly stands by itself but the second one, not yet published, is rather lopsided and needs the first paper to lean against. Both have had some minor revisions made based on feedback that postdates the online versions, in addition the second one (which was put together in a bit of a hurry at the same time my thesis was due and definitely isn't my best work) covers a slightly older design than what's currently being used and needs some changes to bring it up to date. I also need to add pointers to work which has appeared after it was written such as the CCS 2000 papers on undeniable attestations and fault-tolerant revocations, which is similar to the scheme that I examine in the second half of the paper. Don't treat this as a finished work.

  The first paper, A Reliable, Scalable, General-purpose Certificate Store has a pretty self-explanatory title. The second one, Certificate Management as Transaction Processing looks at certificate and certificate status/revocation management from a TP perspective.

• Over the last few years quantum cryptanalysis and post-quantum cryptography (PQC) has been receiving a lot of attention. Unfortunately the technical details can be quite confusing to laypeople. This short paper explains it in terms that should be understandable by anyone.

  There's also a longer talk, Why Quantum Cryptanalysis is Bollocks, that goes into more detail about, well, the title really says it all. When you hear the next "the quantocalypse is coming, we're all going to die" news report or story, take a few deep breaths and re-read the talk slides.

• Sometimes people ask me to do security talks for them without bothering to specify which aspect of security they want me to talk about. This leads to talks like Network Security: A Feminist Perspective which may not be what they had in mind.

• Microsoft's AuthentiCode code signing isn't really a standard (and certainly not a published standard), but it is used very widely in the Windows world. In 1997 I reverse-engineered the format while, uhh, investigating its security. There's nothing terribly tricky about it, it's just a PKCS #7 detached signature inserted as a COFF record. Now you can create your own signed files and users can run them secure in the knowledge that it's perfectly safe to do so (it's signed, so it has to be OK).

• Many years ago I wrote a general survey paper on Secure Internet-Based Electronic Commerce: The View from Outside the US which covers a wide variety of security, encryption, and legal issues such as the strength of encryption algorithms, legal liability problems, validity of digital signatures, problems with "snake oil" encryption, and so on. The paper is targeted mostly at a non-expert audience, and is recommended reading for anyone considering deploying a system over an insecure medium such as the Internet, although much of it is now rather dated.

Analysis of Security Weaknesses

• Norton's Diskreet disk encryption, both the proprietary encryption algorithm (which is very easy to break) and the DES encryption, which messes up the user key processing and greatly reduces the total key space.

• The Windows 3.1 and Windows 95 password file (.PWL) encryption. Microsoft also messed up the key processing, providing a maximum of 32 bits of keyspace. A dictionary attack could recover most password in a few seconds.

  Frank Stevenson extended this attack by taking advantage of the fact that the RC4 cipher that Microsoft used was a pure keystream generator, allowing all information protected with it to be recovered in a fraction of a second. Microsoft made a big fuss about fixing this by extending the keyspace to 128 bits, ignoring the fact that the keystream recovery attack would still recover all encrypted data in a fraction of a second.

• A few days after I showed how to break the .PWL encryption, I recovered the hardcoded password for the default WFWSYS.CFG file, which is "23skidoo". This file contains system-wide security settings.

• As it turns out, you don't even need to bother with breaking the encryption, since Windows will hand you the passwords if you ask for them. To demonstrate this problem, I wrote a simple trojan horse program which will mail your passwords to an arbitrary machine over the Internet. This was also mentioned in Infoworld.

• In late 1996 I broke Netscape's web server private key encryption, which also used RC4. Most keys can be recovered using a dictionary attack in a few seconds. Netscape switched to a new format at about about the same time as I published code to demonstrate how to break the old format (the switch was unrelated to my attack).

• In late 1997 I extended the previous attack on Netscape private keys to work with the exported key files produced by pre-MSIE 4.0 Microsoft software, which still used the same broken format that Netscape had used. I also showed how to break the security for the newer PKCS #12 format used by Microsoft Internet Explorer, Internet Information Server, Outlook Express, and many others. In addition, a design flaw in Microsoft's CryptoAPI allows users private keys to be obtained without even having to break the encryption of the key file. These three attacks allowed the keys used with most Microsoft security products to be recovered, often in a matter of seconds (for the exported key files) or a fraction of a second (for CryptoAPI). One neat application of this attack would be to steal someone's ActiveX code signing key and create an ActiveX control that would steal other peoples keys. Even if the control was detected (which is extremely unlikely), the person the key was stolen from (rather than the real attacker) would end up taking the blame.

  By a serendipitous coincidence, on the day I published details of the attack a l0pht security advisory revealed a buffer overflow bug in MSIE (one of a seemingly endless succession of these) that would allow the execution of arbitrary code on a Windows'95 or NT machine. Combining this bug with the key recovery attack would allow an attacker to obtain the private keys of anyone who viewed a web page containing the code.

  Microsoft responded to the above attack by advising people not to store exported keys anywhere (without actually fixing the problem), and claiming the CryptoAPI security hole (which hands over your private key to anyone who asks for it) wasn't really a problem. My response to Microsoft's claims about security problems in CryptoAPI and MSIE et al clarifies a few points made in my original article, and tries to put Microsoft's claims into perspective.

• In October 1997 I demonstrated problems with the security of the smart cards used by the Yellow Bus Company, Auckland's largest public transport organisation. These are 10-ride rechargeable cards that come in various forms (adult, child, different numbers of fare stages, and so on). As it turns out the cards have very little security, so that it's possible to recharge them or copy them without too much effort (to test this I created a $50 test card for a demonstration to the YBC that was accepted by the reader as a normal bus pass). I informed the Yellow Bus Company of the problem, and the story was covered in Computerworld New Zealand, 26 January 1998.

• Designing a system to handle electronic tax filing has some tricky requirements because the threat model is very different from the one encountered in online payment systems, which is what most out-of-the-box security software is designed for. Because of this, governments implementing online tax filing schemes seem to have a hard time getting the security side of things right. My comments on the NZ tax department's ir-File project (which also applies to a number of other countries' schemes, several of which are much worse than this) contain some comments on the security features required for something like online tax filing. As usual, my crypto tutorial contains a lot more on this.

• Before 9/11, biometrics were mostly a curiosity, employed for additional security in a few special-case access control situations alongside other, more traditional mechanisms. The biometrics market was small, and unlikely to grow much due to the rather limited niche in which biometrics were appropriate. Then came 9/11, and every biometrics vendor packed their fingerprint readers and face-recognition scanners into the nearest carpet-bag and headed for Washington. Why Biometrics and RFID are not a Panacea: A Comedy of Errors in three Acts provides some technical background about the effectiveness of the technology that you'll never find in any vendor sales literature, and documents its less-than-stellar track record in the field. The RFID technology that it's frequently paired with (originally intended mostly for inventory tracking) also has numerous problems, and in particular its use in passports greatly decreases their security compared to the original non-RFID forms. These technologies have their uses, but probably not in the way that they're being pushed at the moment.

• Within the last year or two, banks, credit card companies, and phone vendors have been quietly, or occasionally loudly, pushing out contactless payment systems for credit cards and phones. The banks and credit card companies are doing it because it makes it easier than even to spend money, and the phone vendors are doing it because they want in on the action that the banks and credit card vendors are currently getting. Unfortunately in the rush to make spending money as effortless as possible, security seems to have fallen by the wayside. Contactless Payment Systems: Credit Cards and NFC Phones, presented at AusCERT 2012, looks at some of the issues surrounding currently-deployed contactless payment systems, as well as the perverse incentives created by the business models that are making things that way.

• Analysis of some problems in Linux VPN implementations. This lead to a (much better than the previous link) article in Linux Magazine on VPN security problems and general design issues, originally in the German edition, later in the English/international edition. Where the original writeup was just some thoughts on security issues in a few VPN apps that were written for a crypto audience, the Linux Magazine articles are written for a general audience and provide a much more accessible explanation of VPN security issues and potential solutions, as well as explaining why designing a sound VPN protocol isn't quite as easy as it appears.

• When the XML folks wanted to add security to XML, they designed the whole thing themselves from scratch instead of just treating the XML as a blob to be wrapped up in an existing, well-established format such as PGP or S/MIME. This lead to a number of problems that make XML security extremely difficult to work with, so much so that some XML-using groups have independently taken the wrap-it-in-SMIME/PGP path that the XML designers refused to take. Why XML Security is Broken looks at the problems that arose from the approach taken by the designers of the XML security mechanisms, and suggests a simple solution to these problems.

• Just as the Internet has subsumed all earlier networking technology (ARPAnet, ATM, BITnet, DECnet, Ethernet, ISDN, JANET, NSFNET, and many more), so an omnibus Internet security threat is gradually subsuming all earlier discrete threats (ID theft, phishing, script kiddies, spam, spyware, trojan horses, viruses). Instead of being small-scale (if prolific) nuisances perpetrated mostly by script kiddies, these blended threats are increasingly being created by professional programmers and managed by international criminal organisations. The Convergence of Internet Security Threats looks at the methods and technology behind this blended virus/trojan/spam/phishing/ID theft/credit card fraud threat, various less-than-effective attempts to address it via legislation, technology, and press releases, and some suggestions for potentially effective legislation and other protective measures.

• Malware has come a long way since it consisted mostly of small-scale (if prolific) nuisances perpetrated by script kiddies. Today, it's increasingly being created by professional programmers and managed by international criminal organisations. The Commercial Malware Industry, presented at Defcon 15 looks at the methods and technology employed by the professional malware idustry, which is turning out "product" that matches (and in some cases even exceeds) the sophistication of standard commercial software, but with far more sinister applications.

• Despite the crypto wars having mostly ended some years ago, we don't seem to be any better off now that good crypto is widely available. The reason for this is that attackers are exploiting the weakest link in the interface and doing an end-run around the crypto. Phishing Tips and Techniques: Tackle, Rigging, and How and When to Phish looks at the technical and psychological backgrounds behind why phishing works, and how this can be exploited to make phishing attacks more effective. To date, apart from the occasional use of psychology grads by 419 scammers, no-one has really looked at the wetware mechanisms that make phishing successful. Security technology doesn't help here, with poorly-designed user interfaces playing right into the phishers hands.

  After covering the psychological nuts and bolts of how users think and make decisions, the talk goes into specific examples of user behaviour clashing with security user interface design, and how this could be exploited by attackers to bypass security speedbumps that might be triggered by phishing attacks. Depending on your point of view, this is either a somewhat hair-raising cookbook for more effective phishing techniques, or a warning about how these types of attacks work and what needs to be defended against.

• Donald Norman's book "Things That Make Us Smart" (a follow-on to his classic "The Design of Everyday Things") looks at how appropriately-designed technology can help humans accomplish tasks and achieve goals. Unfortunately technology isn't always appropriately designed, and can have quite the opposite effect to the one intended. One area where this has proven particularly problematic is security user interfaces, where the design is purely by geeks for geeks. My Auscert 2008 talk Things that make us stupid: Why security user interfaces lead to insecure user actions examines the how and why of the destructive interaction between the way normal humans do things and the user interfaces that are typically used to present computer security information to users.

• The computer security industry has sometimes been compared unfavourably to the fashion industry, putting up flambouyant defences where it doesn't make any difference while paying no attention to the open barn door behind the curtain. Why do we allow three retries for passwords instead of two, or four, or thirty-eight? How effective are SSH fingerprints? And how's the ol' PKI doing? My Auscert 2009 talk Oops — Defending where the Enemy Isn't looks at some widespread examples of defending where the enemy isn't, including the underlying threat models (or lack thereof), the effectiveness of the defences, and the real-world pressures and externalities that affect them, along with various modest proposals for alternative approaches. If you want to hear the original talk, risky.biz has a podcast of the talk available.

• The biometrics talk contains among other things references to the specific problem of e-passport security, and in particular the ability to create your own functional copy of an e-passport that passes muster by the reference passport reader implementation. This demonstration was carried by Jeroen van Beek in collaboration with Adam Laurie and myself. When I originally did the signing portion of the demo in early 2008 I put together a brief FAQ to explain its significance, which you can find here.

• The field of computer security contains many tough problems. Some of them though go beyond simply being hard to being completely unsolvable. This doesn't mean that they're merely currently unsolved, but that they have no general solution, or at least no technology-based one. Using the concept of wicked problems from the field of social planning, this talk looks at some of the more notable — and troublesome — Unsolvable Problems in Computer Security. While pointing out that certain problems are in general unsolvable presents a bit of a conundrum, identifying this fact may allow them to be addressed at the business-model or political rather than the technological level.

• While the Allies went to war with mechanical and chemical bomb fuses whose origins dated back to the 19th century, Germany put a large amount of effort in the 1920s and 1930s into designing and fielding high-tech electronic fuses, which were far more reliable and versatile than standard chemical and mechanical ones. This led to an ongoing arms race that lasted throughout most of the war, with Allied bomb disposers coming up with increasingly ingenious ways of hacking the fuses and German armourers countering with ever-more- fiendish fuse designs. Cyberwar before there was Cyber: Hacking WWII Electronic Bomb Fuses, presented at Kiwicon 8, covers the details of the contest between the attackers and defenders.

• While much attention has been given to PKI and PKI technology, very little is usually said about its actual, rather than claimed, effectiveness as an overall security measure. PKI, Lemon Markets and Lemonade, from the 2011 RSA conference, examines PKI's shortcomings, copiously illustrated with examples ranging from the trivial, to the scary, to the comical, as well as what works in the real world.

Security Standards

• The X.509 Style Guide, which describes various X.509 certificate implementation details and pitfalls, provides recommendations on what to do and what not to do, and finishes with a list of known bugs and problems to look out for in existing implementations. Note that this hasn't been updated for many years (the number of bugs in certificates and implementations just got too much to track), for a better overview of the state of play see other publications on X.509 on this page.

• Associated with the style guide is dumpasn1.c, an ASN.1 object dump program that will dump data encoded using any of the ASN.1 encoding rules in a variety of user-specified formats. Sample output from this program (using the default format) is:

   256  159: SEQUENCE {
   259   13:   SEQUENCE {
   261    9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
   272    0:     NULL
           :     }
   274  141:   BIT STRING, encapsulates {
   278  137:     SEQUENCE {
   281  129:       INTEGER
           :         00 E5 19 BF 6D A3 56 61 2D 99 48 71 F6 67 DE B9
  [...]    :         8F
   413    3:       INTEGER 65537
           :       }
           :     }
           :   }
  

  dumpasn1 employs a user-editable configuration file dumpasn1.cfg which provides information on ASN.1 object identifiers. Currently it covers all known security-related OIDs. Peter Hesse of Gemini Security Solutions has adapted the command-line version to create a Windows GUI version that displays the ASN.1 and hex data side by side and automatically highlights the data for the ASN.1 node when you hover over it. Lapo Luchini has created an online version in Javascript that allows interactive browing of ASN.1 objects. For PGP users there's an equivalent utility available called pgpdump.

  If you use dumpasn1, make sure you get them via the links here, since there are all sorts of strange ancient versions floating around out there.

• SSH is an incredibly complicated protocol, with huge numbers of options and internal states that make implementation very different and lead to a very large attack surface. Some years ago I wrote out a profile for SSH that removes maybe three quarters of the unnecessary complexity with no real loss in functionality and a large increase in security. I never did much with it, but if you're interested, here's the SimpleSSH profile for SSH.

• Inspired by numerous PKI RFCs, I decided to unify them all into a Grand Unified PKI Protocol. This document consists almost entirely of features taken from other PKI RFCs, including in some cases text lifted verbatim. Which is kind of disturbing, given that it's 100% satirical.

• After doing the X.509 style guide I thought I'd also do one for PFX/PKCS #12, but the more I looked at it the more I loathed it. The result was PFX/PKCS #12 — How Not to Design a Security Standard, a list of all the things you should do if you want to design a truly awful security standard.

• Sometimes, there just aren't any security standards around that cover what you need. Never fear, you can always roll your own. My writeup on ISO security standards generation shows you how. This also appeared in ;login Vol.22, No.1 (February 1997), the Usenix Association journal.

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

Encryption Software

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

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.

Miscellaneous

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.

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).

Bio

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.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 2.3

mQENAjHxdQsAAAEH/2ETXebjJvRaECzSGzhIrCoILn517GUPJws9Qw6BhBll3mG9
ocqYJppBdrS+hX6KG1HIZxob20uCNYes8Ayo9rISsda6caHP9OQ91sq8Gwm2ZwAi
clneyytpbGpgONzQWZ2UXyeLvwMiRv6N1/XRyq9lEgDpY/DDm1ggaMNdd/XO3sqc
XdakAR5KobD5nEyJ7MwnJkDcTm7HAqnR7U/PKhsA9mPyijeje1f4WsPR/pyDDCIp
rezMDzTIVO70i5886b7xoWk5nlz+gfFS8TUmZzCFZcjrG+mqePjgM2c2J31fX0QW
TmCJrfEN0kVTzx9dKiix1YmPBfGFKyYDc49w/4EABRO0KVBldGVyIEd1dG1hbm4g
PHBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+iQEVAwUQPh0crSsmA3OPcP+BAQFi
0Qf/VaSq9JkG0zZykE4Uz3Rh7giZhczfu3N9HBNQsKlp7IjuAJNdzTGgOmax9pJa
INQtSGocj86NVCewEVCxOvJt8hkr/ezczaK7f0+eRZvuJGRxCP0TokHAXaAIi69H
7OjNwoZP4+85zZzJOa6QNxhSisJSytgvmIapVyLORiUcZ2fbq3IbjPPihNERaMxu
AUO8wIbyw5YQXO/q/TjyJZQFnIRgn5/SIfF8ovIPbrbJ9fAEnsR539knIEBVSJMA
n8vt9AJXTgKxzkzYpNH8SO7pSgr4rwh2DdCTQrQRTz8JWrb62N0c8w0f4Q4PD7x3
nGJTAzCnp5IOdNRBw1+x1/035YkAlQIFEDHxdT36EarpnZl9RwEBB/oD/j8651Qv
vGJg6RDK/kyKpLZ+ow6XT6JxJDxSIuC4sMgwOmsNegNz1M54kq+3TecVzaEx8Ons
+Pu1ZjbYdhO/uQu8GP887qgc6ksBAWRkMqu56khU9TvxAG6yJbpCzTaGeu/BeL3X
aUuLSzvLcyPL3Zr7+SM/oTcbrkUodI0siH5r
=1Fs/
-----END PGP PUBLIC KEY BLOCK-----