A couple of weeks ago I attended a meeting at the NATO SHAPE Technical Center in the Hague to discuss international cryptographic APIs. Several high-ranking NSA types were there, as well as their counterparts from various NATO countries plus a handful of industry crypto people (like me). The idea of the meeting was to find a way to separate cryptographic function from cryptographic interfaces, in a way that allows the applications that call the cryptographic functions to be more freely exported. That is, I can write and export an application that calls the crypto API but that doesn't actually implement the cryptography, and then, when it reaches its destination, the locally-preferred cryptosystem can be plugged right in. Crypto might be implemented in hardware (e.g., Fortezza) or software (e.g., with a shared library or pseudo-device driver). Obviously, this idea is somewhat (completely?) at odds with the criteria presented at last month's NIST workshops for exportable software key escrow systems. One of the requirements given for such systems is that it be difficult to replace the crypto with something that doesn't implement key escrow. But who ever said the government was consistent? Interestingly, it was clear that many people in NSA believe that applications that call an API are controlled under ITAR, but there is some recognition that this may be wishful thinking or may change soon. So while some (maybe most) of NSA wants to prevent development of standard APIs and prevent the export of applications that use them, others recognize that these will evolve by themselves anyway and will be very hard to control once they do. Anyway, the situation is far from clear. It seems best to encourage the realistic side of NSA as much as possible... I learned a few interesting things at the meeting. First of all, overwhelmingly, there is recognition, especially on the part of the non-US government security agencies, that there is enormous value in being able to buy off-the-shelf applications like Microsoft Word or Netscape Navigator and just plugging in the local military cryptosystem and using it for classified traffic. Everyone seemed to agree that there is a growing need for this and that it's too expensive to rely on custom software. There is also movement away from the traditional military ``link encryption'' approach that involves centrally- controlled secure networks in favor of a ``risk management'' approach that favors end-to-end security with off-the-shelf products. In other words, the parts of the military that are concerned with actually securing communications want exactly what we want, and are just starting to realize it. While lots of us have always known this, I had never heard it articulated as quite clearly (or as loudly) by actual comsec/infosec people before. Second, the senior NSA guy mentioned a few things I hadn't heard before. Fortezza is now approved for classified traffic through the SECRET level. Also, the ``type 1'' (classified) through ``type 4'' (unevaluated) cryptography standard is being scrapped in favor of a three ``tier'' system, as follows (these are approximate quotes, from my rough notes): Tier 1 traffic is stuff related to ``national command authority''. (Seems to be secret and top secret and up). It will require NSA cryptosystems, hardware implementation, and will NOT employ key escrow (because of the ``obvious risks''!). Tier 2 traffic is information that, if disclosed, would have ``national implications'' if revealed. Examples given include things like the national power grid, the banking system, etc. It was unclear whether any classified traffic would be included in tier 2. Clearly, some of what is now called ``sensitive but unclassified'' (SBU) will be in tier 2. Anyway, tier 2 systems will be approved by NIST (not NSA, although there will obviously be NSA input into the standards) and will require hardware implementation. Tier 2 traffic will be escrowed, and the government will escrow its own keys. Fortezza is an example tier 2 device (but read on...) Tier 3 traffic will be that which would have ``private implications'' if disclosed. Examples given included personal financial and medical records, etc. Current SBU traffic not in tier 2. Tier 3 would also be handled by NIST, employ commercial or government key escrow (like tier 2) and would be permitted to be implemented in software. Here's the surprise: Tiers 2 and 3 will be interoperable. So there will be published algorithms for tier 3. It is possible that tiers 2 and 3 will have the same algorithms, and that the government will suggest them. It was unclear with interoperability will require that all tier 2 algorithms will be published and implementable in tier 3 software or whether this means that tier 2 devices will also have to implement the tier 3 algorithms. There is an obvious choice of a tier 2/3 algorithm: Skipjack (although there were concerns that this is ``too slow''). So we may eventually find out whether ``S1'' was really Skipjack after all.... -matt