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