I think the thought process for ESAPI crypto needs to be language-indepenent, what would Mr. ESAPI call something, and under the hood it can be as simple or complex as needed. I think we should further explore what I&#39;ve proposed, and leave it to whatever&#39;s planned for the implementations. I would like to see a counter proposal how to associate keys with users, and our user plumbing, so e.g. perhaps a reference to a storage location would be stored in our user table, then that would meet guidelines according to your sheet for example and we&#39;d get all the extra logging and whatnot. <br>

<div><div><br clear="all">Mike<br>
<br><br><div class="gmail_quote">On Sat, Apr 17, 2010 at 3:49 PM, Jim Manico <span dir="ltr">&lt;<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I actually think that the ESAPI crypto storage mechanism is overly simplified. I will be pushing for a full key management lifecycle solution for ESAPI 3.0.<br>
<a href="http://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet" target="_blank">http://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet</a><br>
Jim<div><div></div><div class="h5"><br>
On Apr 17, 2010, at 4:50 AM, &quot;Kevin W. Wall&quot; &lt;<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>&gt; wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
Mike Boberski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;ve been putting some thought into ESAPI crypto lately, as I&#39;ve been<br>
working on the PHP port...<br>
I think we&#39;ve been not looking at crypto in as big-picture a way as the<br>
other controls have been looked at (I am certainly guilty of that, latching<br>
onto e.g. FIPS 140-related implementation details), and I think the<br>
below/something along those lines will further promote the use of ESAPI to<br>
wrap crypto.<br>
In other words, while the 2.0 crypto is technically excellent by anyone&#39;s<br>
measure, it is not ESAPI-ish (i.e., &quot;make it as easy as possible&quot;) enough.<br>
Well, I agree in part with what you are saying here. _Overall_ (speaking<br>
more broadly than just the symmetric encryption methods) I would agree<br>
that some things are not as &quot;easy&quot; as the rest of ESAPI, and probably<br>
this is true of the functionality related to Encryptor in general.<br>
(Neither is it as flexible as it should be, but that&#39;s a completely<br>
different topic, so I will not digress here.)<br>
To a large degree, this apparent complexity in the crypto related<br>
functionality of ESAPI has to do with the general development community<br>
not having a great deal of awareness about cryptographic primitives and<br>
what they are useful for. A good example is the use of the method name<br>
&#39;hash&#39; in Encryptor. Most developers are going to think of &quot;hash&quot; as<br>
something that happens inside a Hashtable or HashMap rather than creating a<br>
cryptographically-strong, secure, one way message digest. And yet, if<br>
these same developers would read any of the cryptographic literature--even<br>
that aimed at the generic development community such as you might<br>
find in _Communications of the ACM_--you will find that those authors<br>
use the same terminology. So with crypto, I think there&#39;s a larger than<br>
normal knowledge gap to cross compared to the concepts in the rest of<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*Discussion item #1. *I think the following function names would be more<br>
  - protectFromDisclosure<br>
  - protectFromDisclosureAndModification<br>
  - protectFromDisclosureWhileAtRest<br>
  - protectFromDisclosureAndModificationWhileAtRest<br>
  - protectFromDisclosureWhileInTransit<br>
  - protectFromDisclosureAndModificationWhileInTransit<br>
  - unprotectFromDisclosure<br>
  - unprotectFromDisclosureAndModification<br>
  - unprotectFromDisclosureWhileAtRest<br>
  - unprotectFromDisclosureAndModificationWhileAtRest<br>
  - unprotectFromDisclosureWhileInTransit<br>
  - unprotectFromDisclosureAndModificationWhileInTransit<br>
  - ... maybe then additional qualifier-ish names,<br>
  e.g. protectFromDisclosureInOracle (maybe output format is in some optimized<br>
  format for Oracle for example), protectFromDisclosureInPDF (maybe wrap<br>
  interesting things like this), etc. ...<br>
  - ... maybe then additional variations,<br>
  e.g. protectFromDisclosureUsingMaximumKeySize, etc. ...<br>
I am open to having a discussion on this, however, I think you need to be<br>
a bit more specific of what methods you are referring to.<br>
Kindly expound upon the above suggested names if you would, say something<br>
old_name --&gt; new_name.  For example, I might, for the the purposes of this<br>
discussion at least, presume that you are suggesting that the various<br>
Encyptor.encrypt() methods be renamed to Encryptor.protectFromDisclosure() ???<br>
If that&#39;s the case, I would think that the resulting signature like<br>
   CipherText Encryptor.protectFromDisclosure(SecretKey, PlainText)<br>
also would also need changed to rename the classes CipherText, SecretKey,<br>
and PlainText to something else as well.  And at that point, while you<br>
_might_ get something that hides the jargon from those with no prior<br>
exposure to cryptography, you also _might_ risk loosing those who have<br>
some reasonable fluency with the subject. (Certainly my first reaction<br>
if I ran across an API with names like this might be to think of the<br>
interfaces need to be simplified to this extent, then how do I know<br>
that the &quot;protecting from disclosure&quot; isn&#39;t simply something based<br>
on some home-grown obfuscation. I probably would be reluctant to use<br>
an API with names like this if I did not almost immediately run across<br>
some very clear documentation that ensured me that it was using proven<br>
encryption and not just obfuscation under the hood.)<br>
Back in 1999, I started developing what 2 years later became a proprietary<br>
Java class library of something that was very much ESAPI-like.  My team has<br>
been refining this class library and its documentation and supported examples<br>
ever since 2001 or so. (We also support a similar .NET implementation with<br>
corresponding class and method names.) For the first 5 years or so, this<br>
class library was about 80% cryptographic related and 20% data validation<br>
related. During that time, we had many discussions, not only amongst our<br>
many team members (who all started out as developers with no prior security<br>
or cryptography experience), but also with many dozens of developers from<br>
the IT department at Qwest. Those discussions resulted in the following<br>
key observations:<br>
   1) Most IT developers preferred that we use names that other APIs such as<br>
      the Microsoft Cryptography APIs, Suns Java Cryptography Extensions, etc.<br>
      used rather than coming up with something different.<br>
   2) Make the API defaults secure (e.g,. use AES by default), but allow<br>
      developers to use the API with other various, perhaps less secure,<br>
      cryptographic options (.e.g., DES) in case they need to inter-operate<br>
      with legacy applications or third-party software.<br>
   3) As much as possible, remove the inherent complexities of cryptography.<br>
      For example, don&#39;t make developers learn about cipher modes, IVs,<br>
      padding schemes, how to validate certificates, etc., unless this<br>
      understanding is essential in accomplishing the desired functionality<br>
      securely. (This is closely related to secure defaults.)<br>
   4) Do not assume that you know the context of why or where developers are<br>
      using your methods. For example, don&#39;t have one method to encrypt a<br>
      string and another method to encrypt a URL. Don&#39;t have one method to<br>
      encrypt something to store to a file and another to encrypt something<br>
      to store in a database. Instead, the dev teams wanted us to give them<br>
      the necessary primitives and they would wrap our APIs with appropriate<br>
      wrappers of their own making.<br>
   5) Provide dev teams with APIs that will allow them to do things portably.<br>
      For example, give them the ability to encrypt anything on a big-endian<br>
      SPARC V9 running Solaris and send that to a little-endian x86 running<br>
      Windows where they can decrypt it and don&#39;t make them have to handle<br>
      differences in endian-ness, or signed vs. unsigned. etc.<br>
Of all these observations, the one that initially surprised me the most was<br>
#1, followed by #4.<br>
I think that in some regards, that observations #1 and #4 are related. First of<br>
all, there is this tendency by the development community to think that they may<br>
need to provide some related functionality that your API does not provide or<br>
that at some point in the future, your API may no longer be supported. So there<br>
this tendency to wrap your API (#4) whether it initially makes a lot of sense<br>
or not. This application wrapping of your APIs not only allows them to<br>
provide some application context (e.g., an encryptAndSecurelyStoreCreditCard()<br>
method), but it also provides a layer of de-coupling between their code and<br>
your API. By doing so, they can easily swap out your API for another one<br>
at almost anytime. This only makes sense. It would not make much sense for<br>
us to provide a bunch of &quot;encryptAndSecurelyStoreX()&quot; methods because not<br>
only are there a lot of common &#39;X&#39; (SSN, CC#, PII, etc.), but also where/how<br>
these things are stored differs greatly from application to application.<br>
Perhaps when we observe that we have a certain level of applications all<br>
doing the exact same thing in this regard (perhaps because of some specific<br>
compliance or regulatory issue or because of some InfoSec policy or business<br>
requirement) we will offer to incorporate said functionality into our API,<br>
but in general we try not to cross that line and know specifically how the<br>
application will be using our building blocks. Usually we find it best to<br>
leave the higher level abstractions to the application development team.<br>
Secondly, I think that this at least in part explains observation #1. By<br>
using the same terminology of other similar APIs, especially in the<br>
case of cryptographic terminology, it makes it much easier for them<br>
to resort to using another API such as MS-CAPI or Sun JCE or Peter Gutmann&#39;s<br>
cryptlib, or openSSL, etc.<br>
Since most of these other cryptographic APIs also use the terminology of<br>
the cryptographic community, using these terms in our API serves to introduce<br>
developers to these concepts so then if they run across an article in<br>
something like _CACM_ or an IEEE CS proceedings on cryptography they will<br>
have already been exposed to some of the fundamental terminology and they<br>
will then find themselves on more familiar ground.  So, while using<br>
domain specific jargon may not seem like the right thing to do in the<br>
short run, it seems to generally pay off in the long haul.<br>
Soooo... I am not saying that we should discard what you are suggesting, but<br>
rather that we need to proceed cautiously.<br>
Perhaps we need both &quot;layers&quot;...one that is more by intent, from a functionality<br>
perspective, similar to what you suggest and the other using the more<br>
traditional nomenclature like presently have. That&#39;s why I asked you for more<br>
specific &#39;oldName --&gt; newName&#39; suggestions because it would help me to see that.<br>
There certainly are places in ESAPI (and not just related to crypto) that<br>
we need to think revising names. We&#39;ve already had a lot of discussion on both<br>
of these lists about this issue. I think that we need to encourage continued<br>
discussion in this area. However, we need to also keep in mind that at some<br>
point we need to come to closure and solidify what is in the official 2.0<br>
release and push out other plans to either a later point release (2.1) or<br>
later major release (3.0). That is needed because there are many companies<br>
who are nervous (mine being one of them) of deploying &quot;release candidate&quot;<br>
FOSS to a production environment. *BUT*, once we have something in an<br>
official release, such as the 2.0 GA release, then we need to make a commitment<br>
to any API changes and follow a standard deprecation policy so we aren&#39;t just<br>
yanking the rug out from underneath our user base.  I know that you (Mike)<br>
understand this, but am just mentioning it for those who have not been following<br>
our discussions on deprecation policies, etc. for the past 4 to 6 months or so.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*Discussion item #2. *I think we need to do better with key management;<br>
without going into gory detail or proposing something too hard to implement,<br>
I think crypto keys need to be associated with User objects as<br>
properties/attributes .<br>
  - Users (likely in many cases users representing server apps) will need<br>
  to be authenticated and logged in with all of the existing ESAPI plumbing<br>
  (logging, intrusion, etc.) before able to access keys<br>
  - This will make clear associations of keys, allow easily for multiple<br>
  keys (Encryptor would just use keys of whomever is logged in), and again<br>
  leverage all the existing plumbing.<br>
I&#39;m glad that you agree with this. I think that this is a good direction<br>
to head in. In particular, I would prefer that my PII and other sensitive<br>
information be encrypted with a key that is different than the one encrypting<br>
your key. I&#39;ve been arguing this point at Qwest since about 2001, but so far,<br>
it&#39;s fallen mostly on deaf ears and has to do mostly with legacy code and<br>
legacy reports.<br>
But there will also be the need to have &quot;per application&quot; keys as well. Both are<br>
needed. At my day job, we almost exclusively use the application keys and very<br>
seldom use per user keys. But I do think that it&#39;s a good idea and can take<br>
using cryptography to the next level.<br>
Fortunately, now that we have cryptographic primitives that can take a SecretKey<br>
object, we have the ability to build out these others. The original presumption<br>
back in ESAPI 1.4 and carried initially into the early 2.0 release candidates<br>
that there was only a single master key per application and everything to be<br>
encrypted or decrypted had use that specific key was way too simplistic to<br>
say the least.<br>
The down side to all these additional keys is that you need a way to securely<br>
manage them.<br>
Ideally we need to allow ESAPI to be used with some sort of secure key<br>
management system. I think this is doable, whether it is using something<br>
like KeyCzar (<a href="http://www.keyczar.org/" target="_blank">http://www.keyczar.org/</a>) or<br>
StrongKey (<a href="http://sourceforge.net/projects/strongkey/" target="_blank">http://sourceforge.net/projects/strongkey/</a>) or your favorite<br>
proprietary key management system or something yet to be determined, is,<br>
well something TBD. But let me assure you that I have been thinking<br>
about it. In fact, not only have I been thinking about it, but I have already<br>
done something like this (and beyond) at my day job.  So it&#39;s on the radar,<br>
but certainly will *NOT* be a part of 2.0.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*Discussion item #2. *I think we need to standardize on PKCS#7 (ideally CMS)<br>
Am assuming you meant to label this one &#39;item #3&#39; since the previous discussion<br>
was labeled &#39;#2&#39;.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  - Then, include a parameter in e.g. protectFromDisclosure to return<br>
  binary or base 64.<br>
  - Perhaps further optimize with functions where this parameter would then<br>
  be hardcoded as mentioned above for the<br>
  example protectFromDisclosureInOracle<br>
Yes, I would like to start using more standards such as CMS (RFC 3852) or<br>
What makes a lot of that difficult is the ambitions to support ESAPI across so<br>
many programming languages. Many of these support C or C++ interfaces where<br>
there&#39;s lots of support for these things, but some perhaps not so much.<br>
But if we had to implement things like CMS ourselves that can get into quite<br>
a bit of scaffold building. And I would like to at least ensure that we have<br>
some level of portability of supporting encryption / decryption across different<br>
programming language versions of ESAPI. It would be presumptuous to assume that<br>
any given IT department only uses on programming language to the exclusion of<br>
all others.<br>
As far as support for asymmetric cryptographic primitives goes (e.g.,<br>
signing / validating digital signatures, public key encryption, etc.),<br>
I&#39;d like to see that functionality extended to be able to use<br>
X.509 certificates from PKCS#12 key stores.  That is much more generic<br>
than what we presently have and provides a higher degree of assurance<br>
as well.<br>
Anyway, good beginnings of a discussion. Keep it going.<br>
-- <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></div></div>
Esapi-user mailing list<div class="im"><br>
<a href="mailto:Esapi-user@lists.owasp.org" target="_blank">Esapi-user@lists.owasp.org</a><br>
</div><a href="https://lists.owasp.org/mailman/listinfo/esapi-user" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-user</a><br>