Path: utzoo!utgpu!attcan!uunet!husc6!uwvax!speedy!engber
From: engber@speedy.cs.wisc.edu (Mike Engber)
Newsgroups: comp.sys.mac
Subject: Re: Encryption
Summary: a reply + some comments for people who have my code
Keywords: RSA, public key encryption
Message-ID: <6154@spool.cs.wisc.edu>
Date: 18 Aug 88 17:13:43 GMT
References: <7596@trwrb.UUCP> <870215@hpcilzb.HP.COM> <6149@spool.cs.wisc.edu> <786@osupyr.mast.ohio-state.edu>
Sender: news@spool.cs.wisc.edu
Reply-To: engber@speedy.cs.wisc.edu (Mike Engber)
Organization: U of Wisconsin CS Dept
Lines: 57

The response to my offer of free source has been pretty overwhelming. I
found the secret to making it big in software - the right price.

In article <786@osupyr.mast.ohio-state.edu> gae@osupyr.mast.ohio-state.edu.UUCP (Gerald Edgar) writes:
>Isn't it true that the RSA paper does not specify the exact sizes to use:
>(the examples in the paper are much too small to keep anyone from
>factoring them).  So as a consequence, every implementor has done it
>differently?
>
>How about it if all Mac people agree to use Mr. Engber's choices for this?
>(I haven't seen them yet.  Are they big enough to resist factorization for
>the next few years, at the rate the factoring technology is growing?)
>How about all of you publicizing your keys, so we can really try it out?

This question seems to arise from a misunderstanding of the algorithm. The
user can pick any key size he wants - the example in the article uses small
primes to keep it managable. The only reason I can see for an implementor
to fix the key size is if his integer arithmetic only works for integers
up to a certain size - any decent implementation will find that longint is
way too small (maybe good enough for a demo)

Now my implementation is totally versatile with respect to key size (through
the magic of Lisp) However large keys slow it down. I've never tested it with
p & q bigger that 100 digits. My prime tester (key finder) will also let you
search for primes of any size you want (again, large ones slow you down) This
should keep everyone happy and in principle if machines get faster so they
can factor faster then Lisp will run faster and you can use larger numbers.
Now if someones solves factoring problem itself, we're all sunk.

I think the article suggested p & q of 100 digits each, but someone
told me that today 200 digits it a safer bet if you think the NSA is
going to take a crack at you. In any case, it'll take a pretty awesome
computer to factor a 100 digit number. I don't know what you can do on
PC (does anyone?)

There are a couple of other point I'd like to make:
1) RSA is an unforgiving algorthm. If you mess up (like p or q isn't
   prime) it'll encrypt your message fine, but it won't decrypt it.
   This is nice for testing purposes.
2) If anyone dove into my code you'll realize there is one place where
   it is especially inefficient. I use the function ldb (and it's inverse)
   to change individual bytes in an integer. This is a non-destructive
   function meaning I end up making a lot of copies of a large integer
   in the process of constructing it. This probably adds a tremendous
   garbage collection overhead. If anyone knows a way around this,
   please let me know.
3) If anyone finds it useful, maybe we can find someone who owns the
   Allegro stand alone code generator and turn this into an application.

4) I'm mailing the people the file as text (200-300 lines) because I
   expect a lot of them will use it on another machine and not want to
   hassle with downloading it unstuffing it and uploading it.

Please, no flames about moving this the cryptology newsgroup. That group
is way over my head.

-ME