<a href="http://answers.google.com/answers/main?cmd=threadview&id=252337">some very scientific tootsie roll pop-related research</a><br><br>Ohh the things you google when you can't sleep...<br><br><div class="gmail_quote">
On Thu, May 15, 2008 at 3:44 AM, Daniel Gimpelevich <<a href="mailto:daniel@gimpelevich.san-francisco.ca.us">daniel@gimpelevich.san-francisco.ca.us</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu, 15 May 2008 00:06:40 -0700, Rick Moen wrote:<br>
<br>
> Quoting Daniel Gimpelevich (<a href="mailto:daniel@gimpelevich.san-francisco.ca.us">daniel@gimpelevich.san-francisco.ca.us</a>):<br>
><br>
>> I am not in any way disputing that to be the current state of affairs.<br>
>> PhilZ said: "An argument could be made that as a matter of solidarity with<br>
>> the rest of the population you should encrypt your email."[1] If this is<br>
>> to be accomplished with PGP/GPG, the entire "rest of the population" must<br>
>> be participants in the web of trust. I investigated this possibility a<br>
>> couple of years ago, and found the OpenPGP functionality in the GPG<br>
>> software thoroughly incapable of such an endeavor.<br>
><br>
</div><div class="Ih2E3d">> Having personally wrestled GnuPG into submission for my own use a number<br>
> of years ago, I was astonished at how utterly user-hostile it was and<br>
> remains, even by the standards of Unix command-line crypto utilities.<br>
> (That's one of the reasons I wrote my lecture notes, to compensate in<br>
> part.)   To this day, I can't reliably remember most of its basic<br>
> command functions, and keep having to pore through its manpage.<br>
<br>
</div>That is way too obvious to mention. I was instead asserting that the PGP<br>
model is wholly inadequate for the above-stated purpose with regard to GPG<br>
_even assuming every e-mail user on Earth could magically be able to use<br>
it properly_.<br>
<div class="Ih2E3d"><br>
> By contrast, the verified PGP "strong set" (<a href="http://pgp.cs.uu.nl/plot/" target="_blank">http://pgp.cs.uu.nl/plot/</a>)<br>
> is currently a bit smaller than the total number of "verified users"<br>
> (whatever that means) CAcert says it services, but there is no<br>
> bottleneck for scaling at any single point (only a rather excessively<br>
> geeky technological burden on each individual participant.[4]  And I'm<br>
> guessing that PGP/GnuPG keys are, on average, a good bit more useful,<br>
> but that's just my guess.<br>
<br>
</div>Ah, now we've come to the quux of the matter: The above assertion is<br>
absolutely false. There _is_ a scaling bottleneck at _every_ point when<br>
using GPG. The investigation I mentioned above consisted of an attempt to<br>
traverse the keys then in my pubring.gpg file as a tree, adding to the<br>
file every key which was used to sign any key already in the file.<br>
Evidently, upon every invocation, the gpg command parses the entire file,<br>
because I found that as the file grew, the wait after invoking gpg before<br>
gpg would respond in any way also grew. Some time after I got to the point<br>
where every invocation of the gpg command was taking more than two full<br>
days to complete, I gave up. I still don't know how many licks it takes to<br>
get to the center of that Tootsie Roll Pop.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
conspire mailing list<br>
<a href="mailto:conspire@linuxmafia.com">conspire@linuxmafia.com</a><br>
<a href="http://linuxmafia.com/mailman/listinfo/conspire" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br>
</div></div></blockquote></div><br>