December 2003 - cypherpunks-legacy

Re: Pre-allocating key segments
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Piete Brooks <Piete.Brooks(a)cl.cam.ac.uk> writes: >I wrote: >> Not only that, but the client ought to allocate some keyspace before it >> needs it, as I think one other cpunk suggested. > >I'd prefer to keep the number of segments "lost" if a brloop ceases. Keep down, I guess you meant. Regarding the local farm software: >... if any keys were allocated to machines which failed to ask for another >segment -- you should assume that that segment was not searched. I agree that is the best policy -- it fails safe -- but I still think the prefetching of some more segments would be useful. The goal is to suck up as many idle cycles as is practical. >> For instance, if it has >> four segments allocated and it's done three of them, it should fork a >> process to begin requesting four more segments *while* it is scanning >> the last segment, rather than waiting until after it is done and leaving >> the machine idle until it can alloc more keys. > >That means that if it crashes, 8 segments are left unACKed :-( And if it had grabbed 8 segments to begin with and crashed, it still would have been 8 segments left unACKed. Plus, it's only 8 segments unACKed if it crashes before it finished that last segment, since it will start trying to ACK the first four segments when it finishes the fourth -- at the same time starting on the next four segments. Would you see it any differently if I had said, "For instance, if it has two segments allocated and it is halfway through the second segment, it should request two more segments *while* it is scanning the last segment"? Keeping in mind that it will still ACK the first bunch of segments when it finishes them. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMEIOnBEcrOJethBVAQHUfQP+OUA+iC7sTp2CVCZ5YqtM7ouNykhyx7Nm agcTHN6FFZUOxDmAogiY/Op/SLBZbgtmACC3RSG0cEHwzCQJZ6jeUrTe9g3qU/Vm jHRn8PurOUYE188QnZSGEj0qcZbeoYJoLE4qOcrd7SbizIcZoWk/WVA4STZwEHuH wHHusza6Un4= =UOqi -----END PGP SIGNATURE----- -- David R. Conrad, ab411(a)detroit.freenet.org, http://www.grfn.org/~conrad Finger conrad(a)grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 Jerry Garcia, August 1, 1942 - August 9, 1995. Requiescat in pace.

2 1

Re: SSL trouble
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> From: Piete Brooks <Piete.Brooks(a)cl.cam.ac.uk> > > One of the things that the latest brloop does is make a call to the master > server asking for a list of servers to contact :-)) > > Note that it is a list, and it tries them in order (all A RRs). Wouldn't this result in the slaves higher in the list being hammered? Perhaps you want to do something simular to what the later releases of bind do with machines with multiple names, and round robin the list. If you had a list with hosts A, B, and C, the first request would get ABC, the next BCA, the next CAB, and the next back to ABC. That would distrubute the work between the slaves a bit better. > > > Then all of the transactions from that point would take place between the > > brute and the slave:) > > Currently just all the "allocate" transactions -- I haven't written my > ACK reflector yet, so all ACKs go direct th the ACK master. > > > The slaves would each be delegated large chunks of the keyspace, > > No -- the slaves will not "be delegated" (as in pre-assigned address space), > they will just ask the master for it as they need it. > Sure, the'll do it in reasonable sized chunks, but not (2**16)/16 .... Actually this is what I meant, that they would ask for it. My idea would be that when a slave is asked for keyspace, if they don't have enough they'd ask for the next large chunk. That way the central server doesn't ever have to deal with small requests. > > > but not keyspace/numslaves. Maybe 1/16th or something like that, and could > > ask for more when their space was depleted. Periodically, perhaps when > > requesting more key space, and/or when a timer pops, the slaves could report > > results. > > Nah - results still go direct pro tem. You might consider it:) > > > What I mean is that every so often they'd report even if they didn't need > > more keyspace yet, iff they had any new stats to report. > > Sure. > > > The nice thing here is that the work of the master and of the slaves is > > almost the same.i > > You got it ! > > > The slaves don't have to do the initial assignment of slave, > (slave -> slaves I assume) > > > and the master doesn't have to report results, but everything else > > is the same. > > Yup -- code sharing ! > > > With careful design you could use the same daemon for both > > with a command line argument to tell it if it was the master (-m) or the > > slave (-s). > > Well, not even that ! > > The slaves don't have the config file with the key info in it ... > > > Of course I'm sure you see that this allows you to add as > > many levels as you want to the hierarchy. > > Indeed. > > BUT .... > > These cache servers are asking for non trivial amounts of keyspace. > As such there should not be *too* many, and then need to be "managed" ... > If one crashes, the logs need to be scanned to see how to restart it (so that > it starts by doling out the segments that it had no sub-doled to its clients). Quite right. I'd assume that the first level list of slaves would be controlled by you. If you're careful enough a slave should be able to go down and come back up without losing any state at all. All brutes/slaves talking to it should be able to continue on with no loss of information. I would put an exponential backoff on the time between retries for the brutes talking to the slaves as well as the slaves talking to the master. (With a limit for the amount of backoff of course.) If you can't talk to someone you might sleep for 8 seconds and retry, if you still couldn't back off to 16, the 32, then 64, then 128, etc...the maximum might be somewhere around ten or fifteen minutes, so that within ten or fifteen minutes of crashing and being restarted everything would be humming along with no manual intervention required on any of the lower levels. > > > A slave doesn't care whether a slave or a brute talks to it. > > Indeed -- that's how it was designed ... > > However, note that with big cache servers (as opposed to Local CPU Farm servers > where all clients are the same "ID") reports of sub-allocation have to be > passed back to the root :-( That's a good point. If you want to keep track of who has what, it all has to get back to the root eventually. If you use my idea of having the slaves cache the information until the next time they'd be contacting the root anyway, (or whenever the timer elapses,) then you greatly cut down on the number of small packets seen by the root, (and each level of slaves when their's a hierarchy). > > > You could make the slave software available as well, and a site with many > > machines could have only the slave contact the master to get assigned a > > slave to talk to, and could configure all of their brutes to talk to > > their own slave. > > Indeed -- the Local CPU Farm cache server is just about ready for ALPHA testers > > > Software like this is easy to write, (and fun), and we should go for it:) > > Done ... > > > Of course I do everything like this in C++, but I suppose perl would be the > > most portable. It's a shame it's so aethestically displeasing to the eye. > > Yeah -- but being based on C, C++ didn't stand much chance ... > > > perl's never a pleasant read. > > ... but better than C++ -- sure. <snicker;> Sound like we could have a religious war if we wanted, but this isn't the right list for it:) (sigh;) Maybe we should move this portion of the discussion to alt.my.favorite.language.rules.and.yours.of.course.sucks. I'm not really a snob about it...I still think cobol's great for some purposes, I just prefer coding in C++. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

2 1

Re: Using Hotmail as an exit remailer
by last deliverer 17 Dec '03

17 Dec '03

Congratulations to Ian Goldberg on his great script for sending via Hotmail! This is sent using the script, with the following info. The proxy comes from the web page Ian supplied: $login is "ldeliverer"; $passwd is "xxxx"; $proxyhost is 'secure.escape.ca'; $proxyport is 80; (Warning: sometimes hotmail eats equals signs.) The only problem is you need to install several extra modules into Perl. I had to add these packages: Data-Dumper-2.07 IO-1.15 MD5-1.7 MIME-Base64-2.03 libnet-1.0505 libwww-perl-5.10 Now let's modify it to work with rocketmail, usa.net, etc. Be nice to see an account-creation script, too. Good job, Ian. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

GOST ??
by Jim Prickett 17 Dec '03

17 Dec '03

Does anyone know what the legal status of the Russian cypher "GOST" is ? Is it public domain, patented, proprietary or what ? It looks like it would be more efficient than DES when implemented on a microprocessor or microcontroller. Also the DDJ article mentioned that like DES, there are good and bad S-boxes for GOST. Does anyone know how to choose a strong S-box for GOST ? Jim Prickett

1 0

Re: SSL trouble
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

David Conrad wrote, quite well: > > Patrick Horgan <patrick(a)Verity.COM> writes: > >I did a distributed scheme for something else that had two levels, a master > >and a group of slaves. Only the slaves talked to the master. For this > >effort I think a variation of the idea would be better. Have all of the > >brutes contact the master, who will, in the first transaction assign them > >to the next slave in a round-robin fashion. > > Why not just have the brutes pick a slave at random? Of course, you need > to give them a complete list of slaves to choose from. But then the only > difference between the master and the slaves will be that the master > doesn't get any keyspace (it's got it all to begin with) and doesn't > report any results upward. > I think that this is a quite good idea with one caveat. That we use a good random algorithm. As people on this list are quite aware, many algorithms that ship in libraries of commercial OSs are flawed in one way or another. Perhaps a combination of the two: give the whole list rotated in a round-robin fashion, and let the client do with it as they will. There are enough coders on this list that we'll soon see independently developed versions of the client software, (although a published protocol for talking with the slaves would be nice), and some might like to draw the first from the list, another randomly choose one, etc... Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: SSL trouble
by Will French 17 Dec '03

17 Dec '03

>> Please don't do anything like this. This will prevent >> people like me who prefer the "random" method from >> participating. > You can't use the random method if the CRACK is using a > sequential search. It just doesn't fit! Hehe... I've always been a bit of a misfit. > You can't ACK something which has not been allocated to you. But I could announce it on the list. > However, if a CRACK were to be using random, the above would > be useful as a "progress report" as the rate of reports > indicates how well the search is going. I don't want to make progress reports. > It would also allow more equal sharing out of the prize money, > as on average 2**15 "possible" keys would be found, and the > first finder of each would receive a fraction of the prize. Well, if someone starts talking real money, I might change my tune. Will French <wfrench(a)interport.net>

3 2

Re: bulk postage fine (was Re: non-censorous spam control)
by sar 17 Dec '03

17 Dec '03

At 02:28 PM 8/3/97 +0100, you wrote: > >sar <sar(a)cynicism.com> writes: >> At 06:32 AM 8/3/97 +1000, ? the Platypus {aka David Formosa} wrote: >> >> >-----BEGIN PGP SIGNED MESSAGE----- >> > >> >On Sat, 2 Aug 1997, Adam Back wrote: >> > >> >> Next we choose a threshold say 1000 posts per day. Seems hard to >> >> imagine anyone generating manually over 1000 emails per day. That's >> >> more than 1 per minute for a 10 hour day. >> >> Take bugtraq which has over 12,000 subscribers. Each post to bugtraq would >> send out 12,000 emails so it would cost aleph one 1200$ per post to his >> list. I dont think anyone would want to run a mailing list under these >> sorts of conditions. > >The way such pay for email systems as I see them would interface with >your existing email system is that you would have a list of addresses >which you would be happy to receive email from for free. > How about spam via trusted addresses, 1 out of 10 posts to this list seem to be ads for something or other. Also what if I decide to subscribe to a high volume list with a few email accounts and talk my friends into doing the same. We also decide no to recieve mail from them for free. If we got over 1000 mails in one day would they have to pay up 100$? and if so who would they pay it to. People running mailing lists whould have to get subscribers to verify that they added the list to their trusted address list.

1 0

Re: SSL trouble
by Bill Stewart 17 Dec '03

17 Dec '03

Several people have suggested random keyspace selection instead of servers. The problem is that there's a high probability that the search will fail to find the correct key. If you split the keyspace into n segments, and randomly select k of them, the probability of failure p = ((n-1)/n)**k ; for k=n, p approaches 1/e (.367) as n becomes large, and 10 is close enough to large that you don't gain much by having independent groups that agree not to overlap in their own 10% of the keyspace. For k=2n (random-searching the space about twice), the probability of failure is still e**-2, about 13%. You need a coordinated search. >Why not just have the brutes pick a slave at random? >Of course, you need to give them a complete list of slaves to choose from. That more or less works, assuming you can distribute the list of slaves along with the code; you still hit the slaves' DNS servers unless you also distribute IP addresses for the slaves to use (which is probably fine as long as people get the addresses beforehand.) You could get fancy and have a DNS server hand out slave addresses round-robin for a dummy address slave.cracker.org. The main failure mode seems to have been misconfigured clients grabbing the single-threaded server for a long time; it may be worth using a multi-threaded server, or alternatively a single-threaded server that has a fast timeout for how long it will talk to a client. I gather there was some protection in the code against dishonest clients, but a malicious attack would be to falsely ACK large portions of the search space (especially the portion containing the real answer, if the attacker knows it). #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: improving the distributed computation
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:43 AM 8/25/95 -0400, you wrote: >1) Abandon the central command way of doing things. Little if any >communication is required for this computation, it should be >self-distributing to and between volenteer sites. That makes it ideal >for implementation as a safe virus. Doling out keyspace _does_ require central coordination, though the job can be delegated to _trusted_ volunteers, or delegated with redundancy to semi-trusted ones. As far as safe viruses go, I've had more free lunches than safe viruses, though I've been offered both out of "charity". Some of the lunches were good, and charitable; the viruses have been, at best, mostly harmless. Perhaps under Safe-Tele-Java-Script it will be possible to send self-modifying self-reproducing scripts around a network to unsuspecting machines, but I doubt it. >2) Give these computations a defined and limited lifetime. The problem >you have with old versions is because they don't die automatically or >even check to see if they are up-to-date and update themselves. Yeah. In this case, the lifetime of the versions was less than the expected lifetime of some of the searches. Automated version-checking would help, but the version changes made it difficult to communicate even simple requests like "Give me a number". Perhaps it would make sense for version upgrading to include changing the server's TCP port so the old versions don't hose the servers for the new versions. >3) Use randomness to break up the search space and redundantly perform >the computation. This should eliminate the problems with malicious >key-space requests, etc. Randomness doesn't help much, since it's hard to be sure you sweep the whole keyspace. Redundancy does help, but it's still tough to protect against sufficiently malicious attackers. >4) Use feedback in the form of selective survival/replication to >optimize the search and allocate search space. If a processor goes >quickly, give it more to do - if it goes slowly, give it less. This >will produce an overall system that adapts with time to the cahges in >network and system usage so as to optimize overall performance as a >function of time. You could do that. But simply asking for more numbers after you've finished the previous batch accomplishes much the same thing; special tuning may be more useful for folks with MasPars than 486s, where redundantly giving out unacked search space can do more. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

North American Crypto Archive status
by Michael Paul Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- WHAT HAPPENED TO THE NORTH AMERICAN CRYPTO ARCHIVE? The North American Crypto Archive at http://www.sni.net/~mpj/crypto.htm is rather limited right now. I have deleted everything except the few files that I contributed to the site. This was to save money, since I suddenly lost some sponsors (who wish to remain anonymous, but I appreciate them greatly) who were paying for the costs associated with the site. I am still planning to resurrect the North American Crypto Archive, but this will likely take a while. I think that almost all of the files were successfully rescued before the site went down by at least one person. Note that much of what was there can be found by following the links at http://www.sni.net/~mpj/freecrypt.htm or by using appropriate search utilities. WHY RESURRECT THE NORTH AMERICAN CRYPTO ARCHIVE? 1. To provide a place for U. S. and Canadian citizens to freely and openly exchange cryptographic information, papers, programs, etc., without fear of government reprisals. 2. To provide a friendly central repository for cryptographic libraries, code, and papers, thus making it easy to find and use such information. 3. To provide a reasonably high bandwith connection for North Americans. 4. To exercise "freedom of the press" and press towards a constitutional EAR. HOW MUCH SPACE WILL THIS TAKE? My total archive space was at about 125 megabytes, but it had been trimmed from what I would like to have. For example, downlevel versions of software were generally deleted, and some things that are historically and cryptographically interesting were not carried. I forsee usage of around 500 megabytes or more in the near future if we can make room for it. The storage need not all be at the same site, however. HOW MUCH BANDWIDTH WOULD IT TAKE? I'd like to see at least ISDN connectivity. I've seen as many as 425 files downloaded in a day from the current archive. Again, the storage and loading need not all be at the same site. WHAT DO YOU MEAN BY NOT HAVING ALL THE STORAGE AT ONE SITE? I envision a new plan for running the archive such that one master index page (like the "export controlled" one at http://www.sni.net/~mpj/na) points to hidden directories all over the continent, wherever free space can be gleaned. The only requirements on the remote sites to maintain the "export controlled" status would be to maintain a cron job that changed the name of the hidden ftp directory containing the files on the same schedule and using the same key as used at the index site. For now, http://www.sni.net/~mpj/na can remain as the password-controlled index site. This does require a slight change to the architecture of the "export control" system in that the directory name would be a function of the current time (UTC) and a secret key, instead of being truly random like it is, now. The relative loss of security in this change is inisgnificant relative to the (obvious) weak links of the system. (Yes, I know that it can be defeated, but I also believe that the system complies with the EAR as well as most do, anyway.) The gain in this approach, of course, is that the index and ftp site need not reside on the same server, as long as the system clocks are reasonably well synchronized (within a few minutes). One other advantage of having several sites is that popular files can be placed on several different servers to lower the average traffic from any one server and to make the system more robust against failures and overloads. The archive would still have a single point of failure (at least initially) in the index site, but that could also be replicated fairly easily as long as users don't mind obtaining a separate password from each index site. WHAT REMOTE SITES DO YOU PLAN TO USE? I've had several people make inquiries or make offers, some of which sound better than others. I hope that this one open letter answers all of the questions that I got. I am looking for sites that: 1. Are *nix-based (at least for now). 2. Have some free disk space and bandwidth that can be used for this cause. 3. Have GNU C++ installed (or at least are identical to a host that I have access to that does). 4. Grant me access to a shell account and an ftp account to maintain the site. 5. Grant me access to cron so that I can have the hidden-directory renaming program run at the right schedule. 6. Are likely to be available for a reasonably long term. 7. Are in the USA or Canada and controlled by a U. S. or Canadian citizen. WHAT MAKES PEOPLE THINK THAT YOU WILL GET ALL OF THESE FREE RESOURCES? The same thing that makes me think that people will donate otherwise idle CPU resources for the fun of cracking a DES key or factoring very large numbers. HOW DOES THE "EXPORT CONTROL" SOFTWARE WORK? Ahh... here is the meat of the message that keeps it on topic for coderpunks and sci.crypt: First of all, it is important to understand the design restraints. The EAR states that mere posting of cryptographic software on the internet is not an export if guests must affirm a couple of things (see the regulations) and if there is some kind of check that the "address of the receiving computer is verified to be in the USA." Strict compliance with the latter is impossible, but if the guest's email address is in a domain not commonly used in the USA and Canada (.gov, .com, .org, .edu, .mil, .net, .us, or .ca), then I suspect the guest of lying and deny access. Naturally, this is imperfect, but it is honestly the best I could figure out how to do on a normal ISP shell account that gives me no CGI script access. This really boils down to the honor system. That is OK with me if it is OK with the U. S. Government, and the way I interpret the law, it is. Given that, here is the process: 1. http://www.sni.net/~mpj/usa is an html form that asks 3 "magic" questions to verify eligibility to legally access the strong cryptographic software, as well as the guest's email address. The 3 questions all default such that the user must change each answer to be granted access. The email address must be correct, because the user name and password are sent back via email, not as a web page. The "submit" button sends this data to cgiemail, an application that Colorado SuperNet does allow me to use. This form also invites nonqualified guests to explore most of the same data via http://www.sni.net/~mpj/freecryp.htm (links to crypto sites outside of North America). 2. When cgiemail gets the data from the above form, it simply formats the data using a template I supplied and mails it to me at mpj(a)csn.net. 3. I have an incoming mail filter that checks for any automated messages from cgiemail (which all have a rather long fixed hexadecimal number for a subject line), and processes them. If the guest answered all 3 questions properly, and the email address given doesn't "look foreign," then a form letter is filled in with a valid user name and password and mailed to the given email address. (There are some other checks, like limiting the email address to one destination, etc.) Noncompliant requests are simply discarded (since the "thank you" message from the submission form really already answered them). I thought about a courteous denial letter, but most of the bogus submissions also have bogus email addresses, so I decided not to do that. 4. If our guest can spell his or her email address right (among other things), then the email message directs him or her to http://www.sni.net/~mpj/na with a valid user name and password. 5. http://www.sni.net/~mpj/na is password protected using the security features of the Apache web server (as slightly tweaked by Colorado SuperNet). This is the index of the files in the archive, which are in a subdirectory of a hidden directory with a non-obvious name. 6. The hidden directory names are changed periodically to discourage the use or posting of a copy of the page at http://www.sni.net/~mpj/na without password protection. The idea is that by the time the cheater posted it and anyone found it, the hidden directory names would have changed again, invalidating the renegade index. The index is altered on the same schedule to the same new names by a companion program. (Right now the same program does both tasks, using a truly random number based on the arrival times and CRCs of all of my mail, but this would have to change in the new distributed archive model). IS THAT REALLY GOOD ENOUGH? I think so. It is the best export control model that I have seen that doesn't lock out U. S. and Canadian citizens in the U. S. A. and Canada. I saw a little more elaborate system on a Microsoft web site for distributing some 128-bit RC2 software, but it locked me out because it didn't like the way Colorado SuperNet registered their "whois" information. It also locked me out from work, since SSL connections can't get past our firewall. My model is much less likely to lock out a duly qualified guest, and it is much better than my old "warning message only" model that I used before crypto export regulations passed from the ITAR to the EAR. WHAT ABOUT CRYPTO SITES OUTSIDE OF NORTH AMERICA? Please keep them up, and be ready to mirror any information that might suddenly become legal to export from the USA on short notice. I say this because the EAR is being challenged in court, and it is likely that cryptographic software export regulations may be struck down. It is also likely that the U. S. Government may quickly move to replace those regulations with others in a very short amount of time after the EAR is struck down. I don't want to encourage anyone to violate currently active regulations, however. If you have a good cryptographic software site outside of North America, and it isn't on my list at http://www.sni.net/~mpj/freecrypt.htm, please let me know. WHAT IS YOUR PGP KEY? RSA key for PGP 2.6.x: ftp://ftp.csn.net/mpj/mpjkey.asc (mpjA) DH/DSS key for PGP 5.0: ftp://ftp.csn.net/mpj/mpjdhkey.asc (mpj(a)ebible.org) (Note that my RSA key uses mpj(a)csn.net for an address. That old address still works.) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBM+6USm+Iqt/O4EnZAQFVFgf+IQq7oZavZxgMwT2530w7LWPkNLqlbG5z BSi1QGasmZrumAuMOG7M28prFZVg2hzExKUejlSXao7ywa3fnzLb0BF8WlDlFsS/ ysSQTB1NLzgjm3L8pqImdNGrP6ECFSFsTm3KOGxuu/NAVfEyBaoV5VEwxlUJmWBu ifsmv7aBOOfY4g2xa9XQay4+rIx4QTr6k6OJenJ0f+eLnC/JjG7Dz3n3Mh0vbu6p Vc9ib9jjkv+eawKv5+BnFUNc/hILsnw1yPQuomc7/G/YMJwbd7Ps/+LVRqmg0oxD ECLfAI/BI6KxUh8EDGH91SnSXNHAYwtA1puIrQka1zkPPTr/psA/fw== =9Zof -----END PGP SIGNATURE----- Michael Paul Johnson mailto:mpj@ebible.org (aka mpj(a)csn.net) PO Box 1151 http://www.ebible.org/bible <- Holy Bible Longmont CO 80502-1151 http://www.sni.net/~mpj/crypto.htm <- Crypto archive USA PGP RSA key fingerprint (mpjA): 3E67 A580 0DFB D16A 6D52 D3A9 1C07 4E41 PGP DSS/DH fingerprint: 28AE B775 DD65 62C7 0717 ECDA 448F E0C7 17D7 47BB

1 0