🚀 go-pugleaf

Thus said eoliver@ralph.cs.haverford.edu (Erik Oliver):
>Well, first of all, RIPEM's command line reminds me like something from
>the C compile from hell... Just trying to figure out which set of
>commands fit most appropriately where was annoying.  pgp was easy to
>figure out and in less than an hour I was up and running with it.  It's
>key combinations were easy -k_ letter to do anything involving keys, pgp
>by itself with a file name automatically decrypts, rather intelligently
>I might add, and so on.

Thanks for being a bit more concrete (though I'm still not sure exactly
what things you want to do but are having difficulty with.)

RIPEM should take well under an hour if you read the users guide
included with the distribution.  I'm guessing that you read the man page
and tried to understand everything at once; imagine if you were trying
to figure out the "ls" command (with its countless options) for the
first time this way.  If this isn't what happened, sorry to assume.

BTW, you may find "ripemd" a handy way to decrypt if "ripem -d" is too
tricky to remember.  It could be argued that "ripem file" would be easier,
although RIPEM is designed with using it in a pipe in mind, since most
mailers allow a quick and easy way to send a message down a pipe.

Some of the command options are needed because RIPEM has some features
which PGP doesn't.  For example, RIPEM can parse mail headers to extract
recipients automatically, preventing you from having to type the
recipient names on the command line (handy, particularly with multiple
recipients.)  If those features confuse you, just ignore them.

>Now, I am no UNIX whimp, but, I found RIPEM's plethora of command line
>options to be just too much and too poorly implemented, perhaps it is
>time for some separation of the command.

I don't really know what you're talking about specifically, so I can't
respond.  However, RIPEM is still in version 1.  If you can make
specific suggestions, they might be implemented.

>                                          Lastly, I dislike the
>centralization of key verification by server, and genuinely prefer PGP's
>distributed method since it allows me to build a ring of trust based
>around other people I trust, not around an easily comprimised INTERNET
>accessible UNIX box.

The key server is a feature which you may either use or not use,
depending whether you trust it.  I find that the finger method
of key distribution works most of the time for my needs, and it's a lot
more convenient than having to maintain a constantly growing keyring
(though you can have a keyring with RIPEM, it makes you do more of the
work yourself than PGP does.)  Finger is not perfectly secure, and not
everybody is on the network with the ability to use it, of course.

>Lastly, as to the distinction between PEM and RIPEM, at least in the
>original stuff concerning TIS's implementation of PEM, I remember using
>the word RIPEM, perhaps that is my memory failing me.  :)
>
>I am genuinely lookin forward to the TIS implementation because it
>sounds like they've gone about fully integrating it into a mailer.  That
>is definitely one of my requirements. Also, pgp is more usable in other
>settings where you are not sending mail, but instead are leaving files
>around.

It sounds like it is indeed the case that TIS/PEM will be integrated
into MH 6.7.2.  (Are you an MH user?  MH is probably the mail software
with what I consider the best RIPEM interface thus far, which will be
improved further still in a couple weeks, at risk of tooting my own horn
since I wrote it.) Of course, MH is a modular mailer, so integrating
things into it is easier than integrating things into, say, elm.

>I am certain that RIPEM has most (if not all) of the features in PGP,
>but accessibility is an issue.

Well, RIPEM doesn't have all the features of PGP.  And PGP doesn't have
all the features of RIPEM.  It's possible to do most of the same things
with both of them, though; just a function of how much of the work you
have to do yourself.  RIPEM makes you do key management yourself, while
PGP makes you specify recipients yourself, for example.

I'd take an "accessibility" complaint as a challenge to write a users
guide/tutorial, except that the one included with the distribution is
already pretty decent.  (If you have specific criticisms of it, I'd be
interested in them.)

>                                Lastly, I with the exception of David
>Sternlight, I have yet to meet too many other people who are not using
>PGP because of fear of patent laws.  So, I guess David won't be able to
>read my mail, but the rest of the INTERNET will. :)

Well, I'm another one.  Not all people who prefer avoiding such
potential entanglement are quite so vocal about that choice.

>Also, I return to the issue of compatibility across PEM implimentations,
>RIPEM does not yet correctly impliment PEM it impliments the author's
>inerpretation of PEM?  (correct me if I am wrong on this point.)  

Um, sort of.  PEM standards are still evolving; for example, RIPEM
implements MIC-CLEAR, which is only described in an Internet draft (i.e.
a work in progress) and not a stable RFC yet.  However, the author
decided the feature was important enough to include rather than
conservatively waiting for the document to become "finalized" (or at
least as final as anything ever gets.)

>Lastly, there is absolutely no question at this point that DES is
>crackable, there are just too many people saying it, along with the
>fact that the US Govt doesn't trust DES for its secret documents.
>Although IDEA is not as heavily tested, at least it remains a big
>question mark.  So, given the choice between encrypting my sensitive
>data with a system that is known to be crackable, and a system that is a
>big question mark, I will choose the latter.

I'm not convinced of that.  However, adding IDEA and/or multiple DES is
on the wish list for future RIPEMs.

>Additionally, there is a civil disobedience component to using PGP which
>I enjoy and think is important.

Matter of opinion and personal choice, I guess.  Some of the people you
wish to correspond with may disagree.
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted

Emacs is a fine windowing system, but I still prefer glass.
		- Tom Christiansen