Privacy Software

[Adam Back]

Monty Cantsin writes:
> nobody at 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`