Privacy Software

-----BEGIN PGP SIGNED MESSAGE-----

nobody@replay.com (Anonymous) wrote:
>After seeing the intents of PGP Inc. with the release of their new
>PGP that breaks the old free versions, I have all but written them
>off as anything but the Enemy, and am waiting for a public reply on
>the list by Tim May to make it official.

Personally, I don't think it is that useful to draw up enemy lists.
It is clear PGP, Inc. cannot be relied upon to achieve our goals for
us.  I think a lot of people half expected something like this out of
them, anyway.  All that left wing politics and weird anti-business
stuff from the PGP crowd did not augur well.

>But now what? Please someone answer my questions about PGP - it
>appears that the 5.x versions are not compatible with the 2.x
>versions which came previous.  Is this so? Also, the direction they
>seem to be heading is in providing more and more non-free GAKked
>product. But aren't the 2.x and 5.x versions freeware? If so, can't
>others - a group of individuals - take that source code and build off
>of that?

The PGP source code is not the worst I've ever seen, but it's kind of
odd.  We should consider a rewrite, which gives us the added benefit
that it will be completely unencumbered.

It also gives us the opportunity to write it in a language other than
C, one which truly supports encapsulation.  C code is hard to verify
with great confidence because it is possible to obfuscate it and
introduce security holes.  This means that C requires one to trust the
authors to a greater extent than is desirable.

It would also be neat if the code were written outside the United
States and were put into the public domain.  If a company snaps it up
and bases a product on it - great!  The more people using the code the
better.

The whole issue of compatibility is an interesting one.  Would it be a
good idea to have a cryptographic system which was completely
incompatible with PGP, given the Big Brother risk?

Something I've never liked about PGP is their approach to encrypting
to multiple keys.  For one thing, the PGP crowd seems overly
conservative with bit expenditure, which is silly because bits are
cheap.  This means that creating entirely separate messages is
completely economical.

It also introduces security risk.  Let's say one of the three public
keys used to encrypt a message has been compromised.  Let's say the
other two parties live in places where they aren't supposed to be
exposed to bad ideas.  Once one key is compromised, the other
recipients are compromised in receiving a forbidden message.

On the other hand, if they were separately encrypted, the link between
the three messages is not obvious.  And, even if the messages *are*
linked, it's still not obvious that the other recipients didn't get
something else.  It provides a lot of deniability.

So, perhaps a protocol which does not support anything more than one
encryption key per message would be a good idea.

Something else that bothers me about PGP is compression.  It strikes
me as bad design to build this into an encryption program.  Zimmermann
has suggested that this increases security.  I doubt this.  Modern
algorithms like IDEA (please correct me if I am wrong) have the
property that if you get one bit, you've got them all.

And, I wonder if compression doesn't actually weaken security?  Let's
say I forward a known message with some commentary.  Since the
compression tables will be known, it seems like the increased size of
the message could provide some interesting information about the
preceding commentary.  All by itself, this probably doesn't matter,
but combined with other information it might result in a breach.  In
any event, that which is ambiguous should be eliminated.

It would also be nice if the messages were padded to predetermined
sizes, say 10K, 20K, 40K, etc.  (Once compression is eliminated this
is less of an issue.)

Anyway, if Adam Back wanted to undertake it, a nice project would be
design a good cypherpunk communications protocol.  Simple, clean, and
secure.

It seems to me that issues like wiping the stack as every function
returns, the formats of key rings, and security measures on the users
computer should not be in a communications standard.

Some other features: maybe a hashcash field which makes it possible to
quickly weed out junk.  The challenge string could be related to the
key.  Also, it would be neat if the system were designed with
steganography in mind.

How about a one time pad mode?  One time pads are more practical than
widely believed.  Many things we talk about we *do* want to keep quiet
for the rest of our natural lives.  Our present tool set and practices
do not do this reliably.  (But, I could be persuaded that one time pad
mode is actually something which should tunnel inside the cypherpunks
communication protocol.  Might as well keep everything clean and
orthogonal.)

>Piss on these assholes and their licensing fees.

There's nothing wrong with paying people for their work!  It's even
desirable if you want tools to be available.

>It was inevitable, anyway. They are a corporation after all, and the
>corporations are not on "our" sides.
>
>I can see a scenario where government is impotent and destroyed
>within 10 years. What will remain and will be harder to eradicate are
>the corporations.  I don't think we should rely on corporate software
>whenever possible, because it always comes with an ulterior motive.

I am of two minds on this question.  Free software is pretty darned
neat.  It's extremely easy to deal with and it's nifty that you can
write and release something and tens of thousands of people end up
using it.  If the code is simply placed in the public domain, then
anybody can use it for any purpose they like.  This has appeal.

On the other hand, corporations can be a good way to get things done,
too.  It is possible that the PGP approach of giving away software was
ultimately a mistake because now people don't expect to have to pay for
their code.  Elimination of a crypto market might be a bad thing.

It's clear that going the corporate route has to be handled with some
care.  Given the political implications, investors have certain risks.

Also, many people seem to switch into a different mode as soon as they
have a company.  Anything which they perceive as increasing their
profits becomes good.  PGP, Inc. has gone this way, we've seen First
Virtual do some unsavory things, and even good old C2 has made a few
people uncomfortable.

It doesn't have to be this way, of course.  Look at Comsec Partners.
We don't see any "conversation recovery", lying press releases, or any
other nonsense from them, just a beautiful product.

The key probably has to do with understanding clearly what it is you
want to do.  If you know you want to promote privacy and free speech
and are willing to volunteer a substantial amount of your time to do
so, then foregoing some blood money or maintaining your integrity is a
lot easier to do.

What I like about selling software is that you could actually make
good living by doing the right thing.  And, after all, if you've spent
six months writing something, why shouldn't the users kick in a little
money instead of freeloading?  I would like to see more crypto users
in the habit of paying for tools and in the habit starting security
companies.

Monty Cantsin
Editor in Chief
Smile Magazine
http://www.neoism.org/squares/smile_index.html
http://www.neoism.org/squares/cantsin_10.htm

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNFwdNpaWtjSmRH/5AQEBZAf+IKyhaAdUWVAYWidPAOu/qw/qiGAYB6go
hxix3lOpj3RHDj87OlzzPIpY7aSbvvPOq6PkOCIecpjsO/e2F4vkXlWMtwONJ7gV
azGEC//voYyvC55diSHfqUg0zOY/8Ddsy460uIDX4jWJUkJzPMRSRIfvsmo/Lpf+
HFJcIcze/w8bD2k9gelBthbIgZOpCjplY68MyPNurCcVbpKlIw/RmyX6WI4hAkYk
UoRlFh4SeAmNWla4t0l3NGkpdxfVJ8tIAl6uNvV3enjjfctgm/5KRr8n7lcjLvOT
jKUJn0DDFD2pdZ66Unp3xeKpOMxLZ4Bqf704piaCSmj4Erul7x1Gmg==
=USz8
-----END PGP SIGNATURE-----

Monty Cantsin writes:
> nobody@replay.com (Anonymous) wrote:
> >But now what? Please someone answer my questions about PGP - it
> >appears that the 5.x versions are not compatible with the 2.x
> >versions which came previous.  Is this so? Also, the direction they
> >seem to be heading is in providing more and more non-free GAKked
> >product. But aren't the 2.x and 5.x versions freeware? If so, can't
> >others - a group of individuals - take that source code and build off
> >of that?
> 
> The PGP source code is not the worst I've ever seen, but it's kind of
> odd.  

I had a go at doing something with it (I'll let you know when I get it
to work) -- I had the damnest job figuring out what was going on.  The
problem I found with understanding it were all of the nested functions
called through vectors of functions and handler functions.  Makes it
hard to inspect what will happen without running the code under a
debugger -- lots control flow is decided at run time.

> We should consider a rewrite, which gives us the added benefit that
> it will be completely unencumbered.

Sounds maybe worth doing.

> It also gives us the opportunity to write it in a language other than
> C, one which truly supports encapsulation.  C code is hard to verify
> with great confidence because it is possible to obfuscate it and
> introduce security holes.  This means that C requires one to trust the
> authors to a greater extent than is desirable.

Some C programmers do have fun writing obfuscated chicken scratchings,
but you _can_ write C code optimised for readability.

What language did you have in mind?  modula-3?  iso-pascal/borland
pascal?

> The whole issue of compatibility is an interesting one.  Would it be a
> good idea to have a cryptographic system which was completely
> incompatible with PGP, given the Big Brother risk?

Theoretically perhaps, however I'm not sure a system will get very far
unless it can automatically interoperate with pgp2.x and 5.x.  You
could build something which did the right thing automatically based on
public key types:

hypothetical cpunks mail system (HCMS)

HCMS -> pgp2.x   use RSA/MD5/IDEA and pgp2.x message formats
HCMS -> pgp5.x   use DSA/EG/3DES/SHA1 and pgp5.x message formats
HCMS -> HCMS     use whatever goodies you want, stego, mixmaster, etc.

decision of compatibility mode to use would be based on public key
type you're sending to.

> Something I've never liked about PGP is their approach to encrypting
> to multiple keys.  For one thing, the PGP crowd seems overly
> conservative with bit expenditure, which is silly because bits are
> cheap.  This means that creating entirely separate messages is
> completely economical.

This is more secure I agree.  The real kicker with this problem is
people who turn on encrypt to self -- I don't want messages with
encrypt to self (an extra door into the message) on them in my
mailbox, nor coming over the wire headed to me.

You can see the reason for multiple recipient though -- it's too ease
integration into mailers -- you can process the message and give it
back to the mailer, and then it can still send the message To: x, y;
Cc: z.

Doing away with multiple crypto recipient risk is more an issue of MUA
integration than rabid conservation of bits.

(Btw., if you've looked at pgp formats you will observe a tendency to
hand huffman encode everything -- yuck, makes decoding and encoding
fiddly, makes code bloat, is extra complexity which makes
implementation mistakes more likely).

> It also introduces security risk.  Let's say one of the three public
> keys used to encrypt a message has been compromised.  Let's say the
> other two parties live in places where they aren't supposed to be
> exposed to bad ideas.  Once one key is compromised, the other
> recipients are compromised in receiving a forbidden message.
> 
> On the other hand, if they were separately encrypted, the link between
> the three messages is not obvious.  And, even if the messages *are*
> linked, it's still not obvious that the other recipients didn't get
> something else.  It provides a lot of deniability.

Yes.  I was thinking this also.  Really paranoid cypherpunk mail
delivery should be via mixmaster, and should be forward secret.

> So, perhaps a protocol which does not support anything more than one
> encryption key per message would be a good idea.

You don't have to use it.  I tend not to.  I never use encrypt to
self, and I get annoyed with people who send me messages encrypt to
themselves, and very rarely do I use Cc on encrypted messages.

> Something else that bothers me about PGP is compression.  It strikes
> me as bad design to build this into an encryption program.  Zimmermann
> has suggested that this increases security.  I doubt this.  Modern
> algorithms like IDEA (please correct me if I am wrong) have the
> property that if you get one bit, you've got them all.

Well unless there's something wrong with IDEA it's fairly moot anyway.
Brute force of 128 bit key space is out of the question.

If IDEA did turn out to be weaker than thought -- say effective key
space turned out to be 64 bits -- then there would be some small value
to obscuring known plaintext.  But this doesn't argue for or against
compression -- firstly compression has I think a fixed known header
anyway, and secondly -- the weird IDEA CFB method includes a 16 bit
checksum anyway, which will mean that you have an instantly verifiable
way of reducing the need for more complicated checks to be only once
every 65536 keys tested.  Then you have the CTB on the contained data
-- a prefix ascii(1)||ascii(1) -- that's another 16 bits of known
plaintext.  And so it goes on :-)

> And, I wonder if compression doesn't actually weaken security?  Let's
> say I forward a known message with some commentary.  Since the
> compression tables will be known, it seems like the increased size of
> the message could provide some interesting information about the
> preceding commentary.  All by itself, this probably doesn't matter,
> but combined with other information it might result in a breach.  In
> any event, that which is ambiguous should be eliminated.

I don't understand this comment.

One thing that some people don't realise is that the plaintext gets
mixed into the random pool as an additional source of entropy.  In
automated environments (lots of MUAs which set +batchmode), this is
all the entropy you'll get -- except for the original key presses to
generate the key, and a small bit of entropy from the system clock.

It's fairly good normally because the way entropy is mixed in is a one
way function of the randseed.bin based on IDEA.  To make use of this
an attacker would need a copy of your randseed.bin before you sent the
target message, and to have suspicions of what the message is.  Even
after a few known messages it would still likely be possible to
attack, because the entropy added by the clock is partly predictable
from the message headers Date: field, and because it isn't that much
entropy each time.

> It would also be nice if the messages were padded to predetermined
> sizes, say 10K, 20K, 40K, etc.  (Once compression is eliminated this
> is less of an issue.)

It would be nice to have a system where you send 100k and receive 100k
per day regardless.  Say in 10 10k packets which get poured into a
mixmaster node.

> How about a one time pad mode?  One time pads are more practical than
> widely believed.  Many things we talk about we *do* want to keep quiet
> for the rest of our natural lives.  

Right.

The problem with this is that you need random numbers.  How do you
generate them?  If you use PGP's random pool, one suspects that if
IDEA becomes attackable at some point in the future the random pool
will start to look more like a predictable PRNG to the attacker.

I wonder how good linux's /dev/urandom would be if MD5 becomes even
more suspect.

> It's clear that going the corporate route has to be handled with some
> care.  Given the political implications, investors have certain risks.
> 
> Also, many people seem to switch into a different mode as soon as they
> have a company.  Anything which they perceive as increasing their
> profits becomes good.  PGP, Inc. has gone this way, we've seen First
> Virtual do some unsavory things, 

What did FV do?  I know they don't use encryption, and Nathaniel
Borenstein wrote a few hype-hype articles about the _gasp_ newly
discovered security danger of "key board sniffers".

> and even good old C2 has made a few people uncomfortable.

Only thing slightly negative C2 did was to make a dubious decision in
handling of Mr Nemesis's fabricated claims about stronghold flaws.
C2 still rocks, though right?

> It doesn't have to be this way, of course.  Look at Comsec Partners.
> We don't see any "conversation recovery", lying press releases, or any
> other nonsense from them, just a beautiful product.

Quite so.  C2 hasn't got "web traffic recovery" either :-)

> What I like about selling software is that you could actually make
> good living by doing the right thing.  And, after all, if you've spent
> six months writing something, why shouldn't the users kick in a little
> money instead of freeloading?  I would like to see more crypto users
> in the habit of paying for tools and in the habit starting security
> companies.

New payment models will need to come in.  How can you extract money
from a cryptoanarchist?  Copyright?  Patent?  Hah, hah.

If we get a real eternity service going (not the poor imitation perl
script up now where all traffic goes through a server unless you
install it locally) software copyright could become a thing of the
past :-)

Trust might be one way to go, rely on good will.  Or paying for
technical support.  Or mixmaster, or DC net packet delivery postage
charges.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`