Any comments on BlueGem's LocalSSL?

[Peter Gutmann]

http://www.bluegemsecurity.com/ claims that they can encrypt data from the
keyboard to the web browser, bypassing trojans and sniffers, however the web
pages are completely lacking in any detail on what they're actually doing.
>From reports published by West Coast Labs, it's a purely software-only
solution that consists of some sort of (Win9x/Win2K/XP only) low-level
keyboard driver interface that bypasses the standard Windows user-level
interface and sends keystrokes directly to the application, in the same way
that a number of OTFE packages directly access the keyboard driver to try and
evade sniffers.

The West Coast Labs tests report that they successfully evade all known
sniffers, which doesn't actually mean much since all it proves is that
LocalSSL is sufficiently 0-day that none of the sniffers target it yet.  The
use of SSL to get the keystrokes from the driver to the target app seems
somewhat silly, if sniffers don't know about LocalSSL then there's no need to
encrypt the data, and once they do know about it then the encryption won't
help, they'll just dive in before the encryption happens.

Anyone else have any additional information/comments about this?

Peter.

Re: Any comments on BlueGem's LocalSSL?

[R.A. Hettinga]

At 9:11 PM +1300 10/28/05, Peter Gutmann wrote:
>The West Coast Labs tests report that they successfully evade all known
>sniffers, which doesn't actually mean much since all it proves is that
>LocalSSL is sufficiently 0-day that none of the sniffers target it yet.  The
>use of SSL to get the keystrokes from the driver to the target app seems
>somewhat silly, if sniffers don't know about LocalSSL then there's no need to
>encrypt the data, and once they do know about it then the encryption won't
>help, they'll just dive in before the encryption happens.

Absent any real data, crypto-dogma :-) says that you need
hardware-encryption, physical sources of randomness, and all sorts of other
stuff to really solve this problem.

On the other hand, such hardware solutions usually come hand-in-hand with
the whole hierarchical is-a-person "PKI" book-entry-to-the-display
I-gotcher-"digital-rights"-right-here-buddy mess, ala Palladium, etc.

Like SSL, then -- and barring the usual genius out there who flips the
whole tortoise over to kill it, which is what you're really asking here --
this thing might work good enough to keep Microsoft/Verisign/et al. in
business a few more years.

To the rubes and newbs, it's like Microsoft adopting TLS, or Intel doing
their current crypto/DRM stuff, which, given the amount iPod/iTunes writes
to their bottom line now, is apparently why Apple really switched from PPC
to Intel now instead of later. You know they're going to do evil, but at
least the *other* malware goes away.

So, sure. SSL to the keys. That way Lotus *still* won't run, and business
gets  done in Redmond a little while longer.

Cheers,
RAH
Somewhere, Dr. Franklin is laughing, of course...
-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: [EMAIL PROTECTED]: Re: [p2p-hackers] P2P Authentication]

[R.A. Hettinga]

At 9:27 PM -0700 10/27/05, cyphrpunk wrote:
>Every key has passed
>through dozens of hands before you get to see it. What are the odds
>that nobody's fucked with it in all that time? You're going to put
>that thing in your mouth? I don't think so.

So, as Carl Ellison says, get it from the source. Self-signing is fine, in
that case. "Certificates", CRLs, etc., become more and more meaningless as
the network becomes more geodesic.

>Using certificates in a P2P network is like using a condom. It's just
>common sense. Practice safe cex!

Feh. You sound like one of those newbs who used to leave the plastic wrap
on his 3.5" floppy so he wouldn't get viruses...

Cheers,
RAH
What part of "non-hierarchical" and "P2P" do you not understand?

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: [PracticalSecurity] Anonymity - great technology but hardly used

[R.A. Hettinga]

At 8:41 PM -0700 10/27/05, cyphrpunk wrote:
>Where else are you going to talk about
>this shit?

Talk about it here, of course.

Just don't expect anyone to listen to you when you play list-mommie.

Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

[EMAIL PROTECTED]: RE: [p2p-hackers] P2P Authentication]

[Eugen Leitl]

- Forwarded message from Matthew Kaufman <[EMAIL PROTECTED]> -

From: Matthew Kaufman <[EMAIL PROTECTED]>
Date: Thu, 27 Oct 2005 19:28:53 -0700
To: "'Peer-to-peer development.'" <[EMAIL PROTECTED]>
Subject: RE: [p2p-hackers] P2P Authentication
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Reply-To: "Peer-to-peer development." <[EMAIL PROTECTED]>

 
Alen Peacock:
>   Personally, I'm put off by the centralization.  I'm not 
> really concerned about the library size or complexity of 
> PKI,.  In fact, my experience indicates that implementing 
> centralized CAs is a good deal less complex than trying to 
> distribute identity verification throughout the system with 
> no centralization.

Agreed... Hierarchical PKI with a single root is distinctly easier than
multiple roots, random chains of trust, or reputation models, which is why
we've started with the simplest design for the default PKI that ships with
the amicima MFP and MFPNet libraries.
 
>   Completely decentralized p2p applications have the 
> advantage of being especially resilient to DoS and other 
> attacks on centrality. 
> Introducing centralized components negates this advantage.  

It negates some advantages, not all.

> In the case of using CAs in a p2p app, the entire network can 
> be disabled by attacking the CAs.

As has already been pointed out, the network still runs, but new clients
can't be authenticated. However, it is possible to make that unlikely... For
instance, if enough trusted entities already have the ability to sign keys,
you can reduce the odds that an attacker can successfully disable ALL of the
CAs. Adding additional roots to the PKI, especially if they are public roots
that are unlikely to be disabled, also helps... It doesn't seem likely that
the world will shut down the existing secure web PKI in order to take your
P2P app off the air.
 
>   p2p networks pose an interesting challenge because you have 
> to design for the fact that malicious or misbehaving clients 
> *will* be present. 

This is actually true of the entire Internet and isn't unique to p2p
networks at all. All protocol implementations and higher level applications
that run on them must be designed to deal with malicious or misbehaving
clients will be present... See buffer overflows of mail servers and http
servers, for instance.

> Since there is no single entity or known 
> group of entities controlling the nodes (as in typical 
> distributed applications), there is no way to enforce 
> adherence to protocols other than with the protocols 
> themselves.  

This isn't about p2p networks at all, but about open-source distribution, it
seems. Lots of totally proprietary p2p and client-server applications have
been shipped where "a single entity" controls the implementation... Skype
comes to mind as an example in the P2P space. These have the temporary
advantage of unpublished protocols and implementations, but this won't stop
a dedicated attacker for long, which brings us back to the original point,
that everything attached to the Internet needs to assume that malicious and
misbehaving things will try to mess things up.

Whether or not that really matters is another point... There's numerous ways
one could build a highly incorrect Gnutella peer, for instance, and yet it
doesn't seem to have become commonplace.

> This may sound idealistic and naive, perhaps 
> justly so, but the further away from protocols that require 
> centralized architectures we get, the better (IMHO, of course).

Well, that's why we're all here on the "P2P" hackers list, I suppose,
because we believe that decentralization is good, but it doesn't really
change the most basic of the design parameters at all.

Matthew Kaufman
[EMAIL PROTECTED]
www.amicima.com

___
p2p-hackers mailing list
[EMAIL PROTECTED]
http://zgp.org/mailman/listinfo/p2p-hackers
___
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

Re: [PracticalSecurity] Anonymity - great technology but hardly used

[Eugen Leitl]

On Thu, Oct 27, 2005 at 11:28:42PM -0400, R.A. Hettinga wrote:

> The cypherpunks list is about anything we want it to be. At this stage in
> the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more
> about the crazy bastards who are still here than it is about just about
> anything else.

While I don't exactly know why the list died, I suspect it
was the fact that most list nodes offered a feed full of spam,
dropped dead quite frequently, and also overusing that "needs 
killing" thing (okay, it was funny for a while).

The list needs not to stay dead, with some finite effort on our
part (all of us) we can well resurrect it. If there's a real content
there's even no need from all those forwards, to just fake
a heartbeat.

-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

Re: [PracticalSecurity] Anonymity - great technology but hardly used

[John Kelsey]

>From: Eugen Leitl <[EMAIL PROTECTED]>
>Sent: Oct 27, 2005 3:22 AM
>To: "Shawn K. Quinn" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: [PracticalSecurity] Anonymity - great technology but hardly used

...
>It's never about merit, and not even money, but about predeployed
>base and interoperability. In today's world, you minimize the
>surprise on the opposite party's end if you stick with
>Redmondware. (Businessfolk hate surprises, especially complicated,
>technical, boring surprises).
 
Not only that, but this is often sensible.  Have you noticed the
bizarre misfit between our allegedly phonetic alphabet and how things
are spelled?  Why don't we get everyone to change that?  Or the silly
insistence of sticking with a base 60 time standard?  Or the whole
atrocity of English measurements that the US still is stuck with?  Oh
yeah, because there's an enormous installed base, and people are able
to do their jobs with them, bad though these tools are.  

...
>OpenOffice & Co usually supports a subset of Word and Excel formats.
>If you want to randomly annoy your coworkers, use OpenOffice to
>process the documents in MS Office formats before passing them on,
>without telling what you're doing. Much hilarity will ensue.

I'll note that you can do the same thing by simply using slightly
different versions of Word.  MS takes a bad rap for a lot of their
software (Excel and Powerpoint are pretty nice, for example), but Word
is a disaster.

>Eugen* Leitl http://leitl.org";>leitl

--John Kelsey

Re: Any comments on BlueGem's LocalSSL?

[James A. Donald]

--
R.A. Hettinga" <[EMAIL PROTECTED]>
> Intel doing their current crypto/DRM stuff, [...] You
> know they're going to do evil, but at least the
> *other* malware goes away.

I am a reluctant convert to DRM.  At least with DRM, we
face a smaller number of threats.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 ctySJF5hgF1q9fil61pohBVLfj/aT4jWZ/KUf29x
 4GuXiNXRF+nY3+3LFo8YpvV4w1S5dwf+LcuAsZWWe

Return of the death of cypherpunks.

[James A. Donald]

--
From:   Eugen Leitl <[EMAIL PROTECTED]>
> While I don't exactly know why the list died, I 
> suspect it was the fact that most list nodes offered a 
> feed full of spam, dropped dead quite frequently, and 
> also overusing that "needs killing" thing (okay, it 
> was funny for a while).
>
> The list needs not to stay dead, with some finite 
> effort on our part (all of us) we can well resurrect 
> it. If there's a real content there's even no need 
> from all those forwards, to just fake a heartbeat.

Since cryptography these days is routine and 
uncontroversial, there is no longer any strong reason 
for the cypherpunks list to continue to exist.

I recently read up on the Kerberos protocol, and 
thought, "how primitive".  Back in the bad old days, we 
did everything wrong, because we did not know any 
better.  And of course, https sucks mightily because the 
threat model is both inappropriate to the real threats, 
and fails to correspond to the users mental model, or to 
routine practices on a wide variety of sites, hence 
users glibly click through all warning dialogs, most of 
which are mere noise anyway.

These problems, however, are no explicitly political, 
and tend to be addressed on lists that are not 
explicitly political, leaving cypherpunks with little of 
substance. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP
 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb

0wn3d

[cyphrpunk]

Hello,

I have hacked the account [EMAIL PROTECTED]. If cyphrpunk want to
know the new password of his account, he can check the box
"[EMAIL PROTECTED]"

V0ld3m0rt

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[cyphrpunk]

One other point with regard to Daniel Nagy's paper at
http://www.epointsystem.org/~nagydani/ICETE2005.pdf

A good way to organize papers like this is to first present the
desired properties of systems like yours (and optionally show that
other systems fail to meet one or more of these properties); then to
present your system; and finally to go back through and show how your
system meets each of the properties, perhaps better than any others.
This paper is lacking that last step. It would be helpful to see the
epoint system evaluated with regard to each of the listed properties.

In particular I have concerns about the finality and irreversibility
of payments, given that the issuer keeps track of each token as it
progresses through the system. Whenever one token is exchanged for a
new one, the issuer records and publishes the linkage between the new
token and the old one. This public record is what lets people know
that the issuer is not forging tokens at will, but it does let the
issuer, and possibly others, track payments as they flow through the
system. This could be grounds for reversibility in some cases,
although the details depend on how the system is implemented. It would
be good to see a critical analysis of how epoints would maintain
irreversibility, as part of the paper.

CP

Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems

[Daniel A. Nagy]

On Fri, Oct 28, 2005 at 02:18:43PM -0700, cyphrpunk wrote:

> In particular I have concerns about the finality and irreversibility
> of payments, given that the issuer keeps track of each token as it
> progresses through the system. Whenever one token is exchanged for a
> new one, the issuer records and publishes the linkage between the new
> token and the old one. This public record is what lets people know
> that the issuer is not forging tokens at will, but it does let the
> issuer, and possibly others, track payments as they flow through the
> system. This could be grounds for reversibility in some cases,
> although the details depend on how the system is implemented. It would
> be good to see a critical analysis of how epoints would maintain
> irreversibility, as part of the paper.

I agree, this discussion is missing, indeed. I will definitely include it,
should I write another paper on the subject.

Irreversibility of transactions hinges on two features of the proposed
systetm: the fundamentally irreversible nature of publishing information in
the public records and the fact that in order to invalidate a secret, one
needs to know it; the issuer does not learn the secret at all in some
implementnations and only learns it when it is spent in others.

In both cases, reversal is impossible, albeit for different reasons. Let's
say, Alice made a payment to Bob, and Ivan wishes to reverse it with the
possible cooperation of Alice, but definitely without Bob's help. Alice's
secret is Da, Bob's secret is Db, the corresponding challenges are,
respectively, Ca and Cb, and the S message containing the exchange request
Da->Cb has already been published.

In the first case, when the secret is not revealed, there is simply no way to
express reverslas. There is no S message with suitable semantics semantics,
making it impossible to invalidate Db if Bob refuses to reveal it.

In the second case, Db is revealed when Bob tries to spend it, so Ivan can,
in principle, steal (confiscate) it, instead of processing, but at that
point Da has already been revealed to the public and Alice has no means to
prove that she was in excusive possession of Da before it became public
information.

Now, one can extend the list of possible S messages to allow for reversals
in the first scenario, but even in that case Ivan cannot hide the fact of
reversal from the public after it happened and the fact that he is prepared
to reverse payments even before he actually does so, because the users and
auditors need to know the syntax and the semantics of the additional S
messages in order to be able to use Ivan's services.

-- 
Daniel

Re: Any comments on BlueGem's LocalSSL?

[R.A. Hettinga]

At 11:10 AM -0700 10/28/05, James A. Donald wrote:
>I am a reluctant convert to DRM.  At least with DRM, we
>face a smaller number of threats.

I have had it explained to me, many times more than I want to remember,
:-), that strong crypto is strong crypto.

It's not that I'm unconvinceable, but I'm still unconvinced, on the balance.

OTOH, if markets overtake the DRM issue, as most cypherpunks I've talked to
think, then we still have lots of leftover installed crypto to play around
with.

Cheers,
RAH
Who still thinks that digital proctology is not the same thing as financial
cryptography.
-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Re: Any comments on BlueGem's LocalSSL?

[R.A. Hettinga]

At 7:51 PM -0400 10/28/05, R.A. Hettinga wrote:
>OTOH, if markets overtake the DRM issue,
^" moot", was what I meant to say...

Anyway, you get the idea.

Cheers,
RAH

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Do away with everything you are indebted for not even paying an other cent

[arlen ray]

Get rid of all you owe not even sending another dollar.  
Eliminate the embarrassing collection contacts. Stop the mailing of checks!
Wild as it may seem the majority lendor's not following the banking laws
here in the US. Mind-boggling but accurate! 
Go to our web site for in depth facts in relation to our approach at no
fees or commitment. You have zero to loose and ample to secure.

http://geocities.yahoo.com.br/jepy_christner/?k=l.Eliminate all that you
are indebted for not even mailing  an other dollar
Complete knowledge or to bring to a hault obtaining or to observe our
location

Multiply cash flow and your customer base within 24 hours using
knowledgeable and high volume mail marketing blitz
Join with the largest and finest [EMAIL PROTECTED]

But I haven't time to stop, so I'm not likely to get mixed up in any rumpus
with them. However, the armed caravan was scarcely out of sight before Rob
discovered he was approaching a rich, wooded oasis of the desert, in the
midst of which was built the walled city of Yarkand
Not that he had ever heard of the place, or knew its name; for few
Europeans and only one American traveler had ever visited it

Re: packet traffic analysis

[Travis H.]

Good catch on the encryption.  I feel silly for not thinking of it.

> If your plaintext consists primarily of small packets, you should set the MTU
> of the transporter to be small.   This will cause fragmentation of the
> large packets, which is the price you have to pay.  Conversely, if your
> plaintext consists primarily of large packets, you should make the MTU large.
> This means that a lot of bandwidth will be wasted on padding if/when there
> are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's
> the price you have to pay to thwart traffic analysis.

I'm not so sure.  If we're talking about thwarting traffic on the link
level (real circuit) or on the virtual-circuit level, then you're
adding, on average, a half-packet latency whenever you want to send a
real packet.  And then there's the bandwidth tradeoff you mention,
which is probably of a larger concern (although bandwidth will
increase over time, whereas the speed of light will not).

I don't see any reason why it's necessary to pay these costs if you
abandon the idea of generating only equal-length packets and creating
all your chaff as packets.  Let's assume the link is encrypted as
before.  Then you merely introduce your legitimate packets with a
certain escape sequence, and pad between these packets with either
zeroes, or if you're more paranoid, some kind of PRNG.  In this way,
if the link is idle, you can stop generating chaff and start
generating packets at any time.  I assume that the length is
explicitly encoded in the legitimate packet.  Then the peer for the
link ignores everything until the next "escape sequence" introducing a
legitimate packet.

This is not a tiny hack, but avoids much of the overhead in your
technique.  It could easily be applied to something like openvpn,
which can operate over a TCP virtual circuit, or ppp.  It'd be a nice
optimization if you could avoid retransmits of segments that contained
only chaff, but that may or may not be possible to do without giving
up some TA resistance (esp. in the presence of an attacker who may
prevent transmission of segments).
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

Re: packet traffic analysis

[Travis H.]

> I assume that the length is
> explicitly encoded in the legitimate packet.  Then the peer for the
> link ignores everything until the next "escape sequence" introducing a
> legitimate packet.

I should point out that encrypting PRNG output may be pointless, and
perhaps one optimization is to stop encrypting when switching on the
chaff.  The peer can then encrypt the escape sequence as it would
appear in the encrypted stream, and do a simple string match on that. 
In this manner the peer does not have to do any decryption until the
[encrypted] escape sequence re-appears.  Another benefit of this is to
limit the amount of material encrypted under the key to legitimate
traffic and the escape sequences prefixing them.  Some minor details
involving resynchronizing when the PRNG happens to produce the same
output as the expected encrypted escape sequence is left as an
exercise for the reader.
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

RE: Return of the death of cypherpunks.

[Tyler Durden]

I don't agree.

One thing we do know is that, although Crypto is available and, in special 
contexts, used, it's use in other contexts is almost counterproduct, sending 
up a red flag so that those that "Protect Our Freedoms" will come sniffing 
around and bring to bear their full arsenal of technologies and, possibly, 
dirty tricks. Merely knowing that you are using stego/crypto in such 
contexts can cause a lot of attention come your way, possibly in actual 
meatspace, which in many cases is almost worse than not using crypto at all


In addition, although strong and "unbreakable" Crypto exists, one thing a 
stint on Cypherpunks teaches you is that it is only rarely implemented in 
such a way as to actually be unbreakable to a determined attacker, 
particularly if there are not many such cases to examine in such contexts.


The clear moral of this story is that, to increase the odds of truly secure 
communication, etc, Crypto in such contexts must become much more 
ubiquitous, and I still think Cypherpunks has a role to play there and 
indeed has played that role. Such a role is, of course, far more than a mere 
cheerleading role,a fact that merits a continued existence for Cypherpunks 
in some form or another.


-TD






Only when Crypto is used ubiquitousl


From: "James A. Donald" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Return of the death of cypherpunks.
Date: Fri, 28 Oct 2005 12:09:36 -0700

--
From:   Eugen Leitl <[EMAIL PROTECTED]>
> While I don't exactly know why the list died, I
> suspect it was the fact that most list nodes offered a
> feed full of spam, dropped dead quite frequently, and
> also overusing that "needs killing" thing (okay, it
> was funny for a while).
>
> The list needs not to stay dead, with some finite
> effort on our part (all of us) we can well resurrect
> it. If there's a real content there's even no need
> from all those forwards, to just fake a heartbeat.

Since cryptography these days is routine and
uncontroversial, there is no longer any strong reason
for the cypherpunks list to continue to exist.

I recently read up on the Kerberos protocol, and
thought, "how primitive".  Back in the bad old days, we
did everything wrong, because we did not know any
better.  And of course, https sucks mightily because the
threat model is both inappropriate to the real threats,
and fails to correspond to the users mental model, or to
routine practices on a wide variety of sites, hence
users glibly click through all warning dialogs, most of
which are mere noise anyway.

These problems, however, are no explicitly political,
and tend to be addressed on lists that are not
explicitly political, leaving cypherpunks with little of
substance.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP
 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb