Ok, I made it to the end of the email. _:-)<div><br></div><div>I&#39;ve anecdotally seen huge funky PKCS#7 and CMS data structures. And, when I ran USPS Electronic Postmark when it was a server app, before it was a hosted service, we actually created a custom EPM format for EXACTLY that reason, to keep the size down and the speed up, to support batch processing for banks, that kind of thing. So you&#39;re working me down :-)<br>

<div><br></div><div>But, a question or two, before I go off and think deep thoughts:</div><div><br></div><div>Did you consider integration with, or design considerations made by, PKIF or NSS?</div><div><br></div><div>Do you have specific technical requirements at Qwest for symmetric key encryption, or could you have used public key encryption, to satisfy requirements?</div>

<div><br></div><div>What business requirements were you trying to satisfy with performing encryption? PCI? Other? Sorry for the ignorance in terms of what regulations/whatever Qwest may be subject to. Maybe you could provide sanitized versions of requirements if internal requirements, towards the end of writing down use cases we&#39;re trying to make sure are covered? I will add them to our new centralized wiki/documentation.</div>

<div><br></div><div>Best,</div><div><br></div><div>Mike<br>
<br><br><div class="gmail_quote">On Fri, Apr 30, 2010 at 5:03 PM, Kevin W. Wall <span dir="ltr">&lt;<a href="mailto:kevin.w.wall@gmail.com">kevin.w.wall@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
As promised... (Or should that be, &quot;as threatened?&quot; ;-)<br>
<br>
In another thread (Call for review of crypto code), Mike Boberski<br>
asked why I chose a custom serialization scheme rather than something<br>
like CMS or PKCS#7.<br>
<br>
Great question. (WARNING: If you fall asleep easily at boring technical<br>
details, you may want to grab a cup of coffee.  OTOH, if you are<br>
suffering from insomnia, read on. :)<br>
<br>
First, let me say, I never really seriously considered using PKCS#7.<br>
CMS (Cryptographic Message Syntax, RFC 5652) is derived from the<br>
latest version of PKCS#7 (v1.5), and since that time there have been<br>
3 or 4 revisions of CMS.  So for the most part PKCS#7 has been superceded<br>
by CMS.<br>
<br>
Secondly, let me state my reason and the design goals for some<br>
serialization scheme, whether that be CMS or JSON or XML Encrypt<br>
or some other custom serialization scheme.<br>
<br>
  Reason:<br>
    We needed a _portable_ way to transport ciphertext over an<br>
    insecure communications channel that was independent of OS<br>
    or hardware architecture but that would not only allow the<br>
    recipient to decrypt it, but also allow the recipient to<br>
    detect whether or not an adversary had tampered with the<br>
    data stream. (Recall the assumption was that this might<br>
    not be transported over a secure channel.)<br>
<br>
  Design Goals:<br>
    1)  Portable across different hardware architectures (e.g.,<br>
        big-endian vs. little-endian issues)<br>
    2)  Portable across programming languages. Should be independent<br>
        of size of &#39;int&#39; types, whether integers are signed or unsigned,<br>
        etc.<br>
    3)  Should have libraries available (preferably native to the<br>
        programming language) or should be easy to build in all that<br>
        is required to support it for all programming languages that<br>
        ESAPI supports. Where such libraries already exist, they should<br>
        be fairly easy to use.<br>
    4)  Should be able to be &quot;self-contained&quot; in that it should store<br>
        everything that is needed to decrypt it except for the encryption<br>
        key itself. This would include the cipher algorithm, the cipher<br>
        mode, the padding scheme, the IV, and a MAC to ensure authenticity.<br>
    5)  Representation of the encrypted serialized data should be compact<br>
        as possible. (At Qwest, there was a *lot* of pushback from<br>
        development teams when they discovered that SSN or CC#s took<br>
        more space to store when encrypted than as plaintext. Most of this<br>
        is because of the padding scheme and IV, but that didn&#39;t matter.)<br>
    6)  There should be minimal additional processing overhead in<br>
        interacting with this encrypted serialized data. Keep in mind there<br>
        are applications where they may encrypt / decrypt several million<br>
        data items in a tight loop during some batch processing so<br>
    7)  Should be extensible and the extensibility should be able to support<br>
        backward compatibility with earlier versions.<br>
<br>
As I started looking into seeing if I could use CMS for this I realized<br>
a couple of things.<br>
    a) CMS / PKCS#7 are much more complicated than what we needed. It does<br>
       much more than to encrypt arbitrary message content.. It can also<br>
       be used to support digital signatures, digests, authenticate., etc.<br>
       There have been 3 or 4 revisions of the RFC for this, depending on how<br>
       you count. That complexity makes it hard to implement correctly and<br>
       it would likely result in incompatibility across different versions<br>
       of CMS.<br>
    b) I did not find it widely implemented. In Java, the SunJCE has support<br>
       for portions of CMS, but they do not have any explicity java.* or<br>
       javax.* CMS related classes. (There may be some com.sun.* classes<br>
       to support it, but using those directly is probably best avoided<br>
       anyway.) I believe that Bouncy Castle has more generic support for<br>
       CMS, but we felt that we did not want to rely on any particular JCE<br>
       provider as most folks will just wish to stick with SunJCE.<br>
    c) After thinking about all the programming languages that ESAPI is<br>
       in the works to support (Java, .NET, PHP, classic ASP, ColdFusion/CFML,<br>
       Python, Haskell, and whatever language is used on SalesForce.com;<br>
       note: JavaScript not included because in general, it would be absurd<br>
       to encrypt on the client side in almost all cases), I realized that<br>
       something as complex as CMS would never be implemented on all these<br>
       languages. But because CMS is so complex (compared to the custom<br>
       serialization scheme that I chose), it would be much harder to<br>
       implement ESAPI encryption so we could build it in such a manner that<br>
       was interoperable across all the ESAPI versions. In fact, implementing<br>
       CMS in a language where you do not have an ASN.1 parser available<br>
       would make it very difficult to implement straight from the RFC.<br>
       BER and DER encoding is used throughout CMS. There quite likely is<br>
       some FOSS version of CMS for Java and I think that .NET has at least<br>
       partial support for CMS, but implementing this for PHP, Python,<br>
       Haskell, etc. would take quite a major effort.<br>
    d) In addition to CMS, I also (very briefly) considered XML Encrypt for<br>
       serialization. It is a much simpler standard and likely has broader<br>
       implementation support than does CMS, but it&#39;s big problem is that<br>
       its resulting size is huge by comparison to other possible<br>
       serialization schemes.<br>
<br>
So instead, last October, I sought out advice of cryptographers on the<br>
cryptography mailing list on Metzdowd.com. And one cryptographer,<br>
Ian Griggs, responded by point me at some similar work that he had done.<br>
That became the inspiration for the current custom serialization scheme<br>
we are using today.  While that serialization scheme is not implemented<br>
on any other programming language of ESAPI today, I do believe that it<br>
is simple enough to implement practically anywhere.<br>
<br>
Finally, the use of this current custom serialization scheme does not<br>
preclude the use of CMS or XML Encrypt or anything else.<br>
<br>
If anyone has any other specific questions about this, I&#39;ll try to<br>
answer them as best I can.<br>
<br>
OK, time to wake up now!!!<br>
-kevin<br>
<font color="#888888">--<br>
Kevin W. Wall<br>
&quot;The most likely way for the world to be destroyed, most experts agree,<br>
is by accident. That&#39;s where we come in; we&#39;re computer professionals.<br>
We cause accidents.&quot;        -- Nathaniel Borenstein, co-creator of MIME<br>
</font></blockquote></div><br></div></div>