Comments inline<br><div class="gmail_quote">On 14 October 2010 11:09, Rory McCune <span dir="ltr">&lt;<a href="mailto:rorym@nmrconsult.net">rorym@nmrconsult.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Thu, Oct 14, 2010 at 10:38 AM, dinis cruz &lt;<a href="mailto:dinis.cruz@owasp.org">dinis.cruz@owasp.org</a>&gt; wrote:<br>
</div>If you&#39;re essentially relying on the security of the passphrase to<br>
provide the confidentiality check, wouldn&#39;t it just be easiest to use<br>
a symmetric crypto algorithm (eg, AES)?.  IIRC from Prof Pipers talk<br>
in Dublin the problem that public/private key crypto was designed to<br>
solve was the secure distribution of the keys, so as you&#39;re not using<br>
that side of things (by relying on out of band passphrase ), there&#39;s<br>
no real need to use PGP :)<br></blockquote><div><br>So here is where things start to get interresting. For example I quite like the idea that with the proposed model there is a case where anybody (or any tool) can encrypt the data, but only one player (the one with the password) can decrypt it.<br>
<br>When you compare it with Symmetric encryption (where all players can encrypt and decrypt (players = &#39;access to the key(s)&#39; ) I think there are some interresing use cases (see below)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
Also thinking about it the PGP solution could be somewhat less<br>
flexible than the symmetric crypto solution.  If you want to change<br>
the encryption key with PGP you&#39;re going to need to redistribute new<br>
keys and presumably change/distribute the passphrase in use, </blockquote><div><br>Actualy no, I could redistrubute the Keys and keep the same PassPhrase (since that is something that only me and the receipient knows). For example, with O2, I&#39;m going down the route of creating custom O2 versions per client (or subscriber), so I could have a model when I share a PassPhrase with the Custom O2 user(s) and then (if required) freely change the keys on new versions (with the idea that I would use PGP to encrypt some of that Custom O2 module (for example the client-specific scripts/APIs)).<br>
<br>One of the usability items that I think is very relevant is that it is easier to exchange PassPhrases with users, than it is to exchange a Private Key (again assuming non-normal PKI interactions and one-to-many distribution models (i.e. there are multiple users that need to be exposed to the Keys))<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">whereas<br>
with a symmetric solution, you just change the passphrase in use and<br>
distribute it.<br></blockquote><div><br>Yes and as with Symmetric encryption, I like the concept that there is only one secret between me and the user/client (i.e. a PassPhrase (or maybe call it password)). I also like the fact that I&#39;m not making the life harder for my users by creating an asset (Private Key) that they need to manage.<br>
<br>Going back to the idea I mentioned above. I&#39;m really starting to like the model of <b>&quot;having the ability to easy encrypt data (using the Public Key) and the limited ability to decrypt it (using the PrivateKey + PassPhrase)&quot;</b><br>
<br>Here are a couple examples:<br><ul><li>Tool XYZ encrypts all data it creates (namely all findings) but can&#39;t read it back (good way to help the distrution of that data)<br></li><li>Developer uses the Public Key to encrypt some of its artifacts (like source code) for distribution to security consultants</li>
<li>Security consultants encrypt its report(s) using the exposed Keys (this would be useful during the engagement and for the final report)<br></li></ul>NOW I know that if one can do proper PKI (public key exchanges) it would be a more robust workflow, BUT I like the simplicity and the usabiliy of it.<br>
<br>Remember that today, encryption is barely used, so in my book if this concept increases the amount of encrypted data, then surely that is an improvement.<br><br>Finally, the idea of &#39;sharing&#39; secrets is very common is Desktop/Client-Side apps, and is something that is already happining on security features like OAuth (see how I had to include the OAUTH_CONSUMER_KEY and OAUTH_CONSUMER_SECRET in O2&#39;s source code in order to the the Twitter API to work : <a href="http://code.google.com/p/o2platform/source/browse/trunk/O2_Scripts/APIs/Twitter/O2TwitterAPI.cs">http://code.google.com/p/o2platform/source/browse/trunk/O2_Scripts/APIs/Twitter/O2TwitterAPI.cs</a>)<br>
<br>Dinis Cruz<br></div></div>