PGP vs. RIPEM

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

( >>>>>>'s inserted for the benefit of George Gleason ;-)

From: Michael Edward Marotta <mercury@well.sf.ca.us>

>>>>>>  (This is for an article in the 1994 Loompanics catalog.)

That's great that Loompanics is covering encryption.
 
>>>>>>  I don't know about you guys, but I find PGP much easier to use.  
>>>>>>  RIPEM has all the hallmarks of unix wizardry.  It is poorly 
>>>>>>  documented.  The interface is difficult.  It grew in ways the 
>>>>>>  designer never contemplated.  And I haven't even RUN anything 
>>>>>>  yet...  Mark told me that it was primarily a MAILER.  OK, I can 
>>>>>>  accept that.  But I just don't see it catching on.  PGP, on the 
>>>>>>  other hand, shows all the evidences of shareware.  It's hard to 
>>>>>>  comment on the obvious.  

I think the existance of two programs is good, helping to promote some
rivalry and a certain amount of borrowing of good ideas from each other.
PGP now has a contrib directory with information and scripts to help
integrate it into mailers, an area which RIPEM has focussed on from the
beginning.

>>>>>>  So, I assume that I am in the normal range for a netrunner.  I 
>>>>>>  typically log in to fidonet bbses from home.  I have a PC clone.  
>>>>>>  I have had accounts on CompuServe, Prodigy and Delphi.  I have a 
>>>>>>  couple of email addresses.  I can't see myself using RIPEM.  I 
>>>>>>  can indeed see myself using PGP.

PGP was originally developed on a PC and then ported to Unix, while for
RIPEM it was the other way around, I believe.  The workings of RIPEM are
more Unix-ish while PGP is more DOS-ish.  Which program seems more natural
may depend on your background.

The user community is more diverse than most people realize.  You sound
like you have somewhat more of a PC orientation than many people on the
net.  Most of the people I run into have the opposite problem - they think
everything is Unix and that the PC is just some little corner of the world
which isn't really relevant.  They think that Usenet and Unix workstations
are the de facto target environment for any communications utility.

Actually, I think your experience is more relevant - PC's at home, hooking
up to BBS's, Fidonet, and the commercial services for communications;
also, people using PC's at home and dialing into Unix boxes at school or
work.  Another big area is people using networked PC's at work, although
since we are mostly talking about freeware packages here we haven't paid
much attention to that.

Especially with encryption, which generally can't run securely on multi-
user workstations, it makes more sense to think of PC's as the target platform.
Some people are starting to have single-user systems which can run Unix,
and this may increase with time, but for now DOS is where the emphasis
should be.  Many of the PC magazines predict that Unix is dead in that
market and that Windows is the platform of choice in the future, so that
is where we should be aiming, IMO.  As Phil Zimmermann says, "skate to
where the puck will be."

I didn't really mean to open up the standard OS wars here, but it's
important to realize that encryption has unique requirements for secrecy
and security which may affect the DOS vs Unix debate.  (And yes, I know
I'm leaving out Macs, Amigas, Ataris, and who knows what else.)

>>>>>>  Here are my questions:
>>>>>>  How do you relate to the above?  
>>>>>>  Do you see "everyone" on the Net happy as clams with privacy-
>>>>>>     enhanced mailers?  
>>>>>>  Do you expect more people to find out about and rely on PGP?  
>>>>>>  Do you see something else working here that I haven't perceived?

The big problem, as Eric Hughes has frequently mentioned here, is the need
to integrate encryption with mailing.  I think what is really needed is
some way of dealing with people who read mail on their PC while using
some kind of terminal program or similar package to connect to a BBS,
commercial service, or Unix box.  The problem is that there are so many
different programs in use and people probably won't be willing to switch
just to get encryption.  A lot of programs have fancy features including
scripting, macro keys, etc., and switching requires learning new ways of
doing all your old stuff.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.2

iQCVAgUBLAi+1agTA69YIUw3AQGPLgQAlyIQOjmSo/Aq+aAUcTClfSVKXKMJiWk1
rYJ5qWiUYhkyyxRzTcLLUcGHg7kMlBwX1Xm8ptdq+/9FRUPXC8zGQjfD+Fn5AoHU
FjItmAk6t4JEDRiaYTQAhVlJZnt3LHmnvMADxwCm36He6svjQTWDDXyob0giWw9s
2bQbGLGZG9Y=
=yYIN
-----END PGP SIGNATURE-----

>I think what is really needed is
>some way of dealing with people who read mail on their PC while using
>some kind of terminal program or similar package to connect to a BBS,
>commercial service, or Unix box.  

I think Hal is largely accurate here.  Certainly the "DOS box as
terminal" problem needs to be solved.  With the advent of 386BSD,
however, home Unix is going to be increasingly common.  

As an aside, I want to harp again on what I call the software
infrastructure problem.  If email and telecomm systems were well
structured, instead of exhibiting so much history in themselves, most
encryption freatures would be extremely easy to implement--just grab
the right hook.  Unfortunately this is not the situation.  Hence my
conclusion:

	The most important software development for wide scale
	deployment of cryptography has nothing _per se_ to do with
	cryptography.

Let's go back to the DOS-as-terminal issue.  The politics and
economics of DOS shareware is such that source code is almost never
made available.  Gnu public license software is rare in the DOS world.

I propose that interested cypherpunks write a DOS terminal program
which _is_ free software.  In order to overcome the inertia which Hal
properly observes is endemic to any software change, I submit that to
have source code available to fix or add features deemed desirable
will be a key factor in acceptance of this software.  I have my own
ideas about multiplexing the channel to support background POP and
file transfer, but I'll leave that for later.  Such software, of
course, would be properly layered to be able to add encryption at the
key junctures.

It would be entirely appropriate to discuss such architecture here on
the cypherpunks list.  When the developers's effort starts, I promise
to find a way for them to have their own mailing list.

Eric

Let's generalize a bit: Since PC based unix is more available, this
package should run on either PC or UNIX platforms. Tip doesn't cut it
as a terminal program for UNIX and I don't know of another... SLIP
has it's disadvantages.  

So, what I'm proposing is that the OS interface stuff be crammed into
an interface layer.
One intriguing application: Write an interface layer that uses
SOCKETS for connectivity.
We want to avoid the kitchen sink mentality, BUT if we're going to
spend lots of time on this package, then why have it all go to waste
when time comes to port the sucker?

	Stig



/* Jonathan Stigelman, Stig@netcom.com, PGP public key by finger  */
/* fingerprint = 32 DF B9 19 AE 28 D1 7A  A3 9D 0B 1A 33 13 4D 7F */

> Let's generalize a bit:  Since PC based unix is more available, this
> package should run on either PC or UNIX platforms.  Tip doesn't cut it
> as a terminal program for UNIX 

No kidding.

> and I don't know of another...  

Kermit?

> SLIP has it's disadvantages.  

Like, try making it work reasonably on a DOS platform.

> We want to avoid the kitchen sink mentality, BUT if we're going to
> spend lots of time on this package, then why have it all go to waste
> when time comes to port the sucker?

Why not just distribute a package of patches for the Kermit sources?



Mike McNally