December 2003 - cypherpunks-legacy

NIST - PKP settlements not over yet
by Stanton McCandlish 17 Dec '03

17 Dec '03

[from Gregory Aharonian's Internet Patent News Service] A hostile response to a tentative agreement to settle a patent dispute over the proposed Digital Signature Standard has forced the National Institute of Standards and Technology to return to negotiations. Last summer, NIST officials thought they finally settled the DSS public key patent dispute by granting Public Key Partners (PKP) of Sunnyvale, California, an exclusive worldwide license for the Digital Signature Algorithm (DSA) on which the DSS is built. In exchange for sublicensing rights, the PKP group agreed to endorse NIST's DSS proposal. But F. Lynn McNulty, associate director for computer security with NIST's Computer System Laboratory, said a majority of potential DSS users balked at the deal. NIST published the settlement terms for comment, and McNulty said all but 10 of the 270 comments were critical. [as many of you may remember, EFF coordinated the transmission of these comments to NIST, who did not widely announce the request for comment at all. The uncharitable might call that an attempt to sweep the matter under the rug. The naive might call it an oversight. At any rate almost all of the comments NIST received were routed via EFF, who were happy to publicize it "for" NIST.] Many DSS critics have argued that another algorithm promulgated by RSA Data Security (Redwood City, CA), is a de facto industry digital signature standard and that it would cost too much to comply with a separate government standard. Now NIST is attempting to hammer out a new settlement based on the comments, McNulty said. "The real hang-up continues to be the patent issue", McNulty said. "We're still trying to resolve it". Scientists at CSL designed the CSS to serve as a standard agency tool for verifying the senders and contents of messages transmitted electronically. CSL also prescribed the public key Digital Signature Algorithm (DSA). But PKP, which holds the rights to public key patents on behalf of Stanford University, MIT, and most recently, German professor Claus Schnorr, charged that CSL's proposed algorithm infringed upon these patents. NIST originally sponsored DSA research, and agencies are exempt from any licensing fees. PKP, however, has maintained that vendors that incorporate the standard into their products should pay royalties. [Government Computer News 1/24/94, 58] -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Re: remailer delays
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

It's half done :-) ! Unfortunately the NSA run remailers haven't been handing out info, but this should help people know which blanks are still blanks ;-). God I hate these little sideways smileys! oooooooooooooooooooooooooooooooooooooooooooooo ooo$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ooo $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ o$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$o $$$$$ $$$" "$$$$$" "$ $ $ "$ $$$$$" "$ "$ $$$ $$$$" "$$ $$oo$$$$$ $$oo$ $$$$ $$$$ " $$$$$ $$ $ " $$$ o$$$$ $ $$o "$$$$$o "$ $$ $ $$$$$ $$ $ $$$o $$$$ o $""$$ $$$$$""$$ $ $$$$ $$$$ o $$$$$ $$ $ o $$$$ $$$$ $$$ $o o$$$$$o o$ $ $ $o $$$$$o o$ $o $$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$""""""""""""""""""""""""""""""""""""""$$$$$$$$$$$$""""""""""""$$$$ $$$$ "$$$$$$$$$$" o$$$$ $$$$ "$$$$$$$$" o$$$$$ $$$$ $$$$$$$$ $$$$$$ $$$$$$$$$$$$$ $$$$$$$$$ $$$$$$ $$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$ $$$$ $$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$ "$$" $$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$o "" o$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$o o$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$o o$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$$$o o$$$$$$$$$$$$ "$$$$$$$$$$$$ $$$$$$$$$$$$$$$ $$$$$$$$$$$$" $$$$$$$$$$$$ $$$$$$$$$$$$$$$$ $$$$$$$$$$$$$ $$$$$$$$$$$$ $$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$ "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$" $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ """$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$""" """""""""""""""""""""""""""""""""""""""""""""" Xenon's Full Disclosure Remailer List. Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB ...and? --------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- bsu-cs + ? ?/? + ? ? ? ? ? 23a - catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - colostate ++ ? SM/MQ ? - ? ? Un M ? - dis.org -/-- ? ?/? - ? ? ? ? ? 23a - extropia +/- ? SM + - - - Pr M 23a - jarthur +/-- St SM/MQ - -/+ ? ? Un ? 23a - menudo -- N SM - t1 "?" Y Un H 23a - merde -/-- ? ?/? - ? ? ? ? ? - - penet.fi -- St SM - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- N MQ - - - N Un M 23a - remba -- ? ?/? ? ? ? ? ? ? 23a - shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- Pinging isn't practical due to long delays. Probably reliable though. +/- Sometimes +, sometimes -. Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: simple counter. N: operator keeps no logs. C: Simple counter. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access needed. MQ: mailqueue accessible by anyone on the site. Could make logs. I have chosen nicknames based on a string common to both the outgoing address and to the address you see on an incoming message from the remailer. bsu-cs nowhere(a)bsu-cs.bsu.edu catalyst catalyst(a)netcom.com chaos remailer(a)chaos.bsu.edu cicada hh(a)cicada.berkeley.edu colostate nate(a)vis.colostate.edu dis.org remailer(a)dis.org extropia remail(a)extropia.wimsey.com jarthur ebrandt(a)jarthur.claremont.edu menudo nobody(a)Menudo.UH.EDU merde remailer(a)merde.dis.org penet.fi anon.penet.fi pmantis hh(a)pmantis.berkeley.edu qwerty qwerty(a)netcom.com rosebud elee7h5(a)rosebud.ee.uh.edu (elee6ue(a)rosebud.ee.uh.edu) shell hfinney(a)shell.portal.com soda hh(a)soda.berkeley.edu Discontinued remailers still on some lists out there: phantom(a)mead.u.washington.edu remail(a)tamaix.tamu.edu sameer(a)netcom.com sameer(a)berkeley.edu (spelling?) cdodhner(a)indirect.com remailer(a)entropy.linet.org?? 00x(a)uclink.berkeley.edu? remail(a)tamaix.tamu.edu? Background on each remailer: bsu-cs: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? catalyst: Run by Scott Collins. Machine: personal dial-up account on Netcom. Problems policy: Outgoing address blocking, with proof of ID. Contact catalyst(a)netcom.com. Software: Customized Hal's ? Security: Netcom keeps sendmail logs, which root(a)netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Comments: History: ?? chaos: Run by Chael Hall. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Comments: finger remailer.help(a)chaos.bsu.edu for info using any remailer. ?? gopher chaos.bsu.edu for a collection of info about Cypherpunks. Comments: History: ?? cicada: Run by Eric Hollander. Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". colostate: Run by ?? Machine: ??? Problems policy: ?? Contact ?? Software: ?? Security: ?? dis.org: Run by Peter Shipley. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? extropia: Run by Miron Cuperman. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Only accepts PGP remailing. ::/Encrypted:PGP header is optional. Privately owned, in Canada. Not directly connected (delays possible). History: ?? jarthur: Run by Eli Brandt. Machine: Sequent Symmetry. Problems policy: Destination blocking is available w/ sufficient ID. Contact ebrandt(a)jarthur.claremont.edu. Software: The usual, tweaked for MMDF. Hal's. Security: jarthur keeps sendmail logs. Comments: Although jarthur doesn't batch, its connection often results in outgoing mail getting batched out anyway (1-3 hours delay). History: Set up late '92. PGP added mid '93. menudo: Run by Karl Barrus. Machine: University machine. Problems policy: see policy at gopher site. Contact klbarrus(a)owlnet.rice.edu or elee9sf(a)menudo.uh.edu. Software: Modified Hal's. Security: Stores messages and sends them out randomly at midnight. Pads messages to 1K with random stuff. (?) Comments: elee9sf@menudo accepts RIPEM encryption. elee6ue@rosebud requires "digital cash" (basically random strings I made). Errors on elee9sf@menudo are forwarded klbarrus(a)owlnet.rice.edu where they are deleted. I still get mail at that address which is why I have it forwarded and not just dropped. History: No comment. merde: Run by Peter Shipley. Maching: ?? Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: History: ?? penet.fi: Run by Julf (Johan Helsingus). Machine: ?? Operator owned. Problems policy: Account revokation. Contact ??(a)anon.penet.fi. Software: custom. Security: Comments: By far the most popular remailer, dwarfing in a day what the entire Cypherpunk remailers combined carry in a month. Supports easy return addresses as well as non-anonymous mailing to someone's anonymous address (na1234... instead of an1234...). Your real address is kept on Julf's hard disk, but is fairly safe there, especially if you do not abuse your anonymity to harass someone. On a bad day your mail and especially Usenet posts may be delayed up to a day. Very reliable though. Sends error messages back to you for failed mail. Limited to 48K mail. History: ?? pmantis: Run by Eric Hollander. Machine: ?? Problems policy: ?? Contact ?? Software: ?? Security: Tread lightly. Being "phased out". Comments: History: ?? qwerty: Run by Xenon. Machine: dial-up account on Netcom. Problems policy: "What problems?". Contact qwerty(a)netcom.com. Software: Hal's remailer. Security: Netcom keeps sendmail logs, which root(a)netcom.com can read. Any Netcom user could also compile his own sendmail logs, by constantly logging mail as it arrives and leaves. Operator often logs in using telnet. Comments: You must use na1234(a)anon.penet.fi not an1234(a)anon.penet.fi. Finger qwerty(a)netcom.com for a blurb on the remailer and updates on its software. Request-Remailing-To: /dev/null is a bit bucket. whitehouse.gov gets blocked and fully logged. History: Up 2/94. Set up by Xenon who needed more remailers to use to send PGP info to people with, since anon.penet.fi was overloaded. rembe: Run by Bill (O'Hanlon?). Machine: ? Privately owned. Problems policy: ?? Contact ?? Software: ?? Security: ?? Comments: Not directly connected (delays?). History: Second oldest remailer. rosebud:(elee7h5@rosebud.ee.uh.edu) Run by Karl Barrus. Machine: University. Problems policy: See gopher site. Contact klbarrus(a)owlnet.rice.edu. Software: Hal's. Security: "syslog file can be read" Comments: Errors are "dropped". History: Third oldest remailer. rosebud: (elee6ue(a)rosebud.ee.uh.edu) Run by Karl Barrus. Machine: univerisity Problems policy: see gopher site. Contact klbarrus(a)owlnet.rice.edu. Software: standard scripts (Hal's) modified to accept cash strings. Security: "Syslog file can be read." Comments: Errors are "dropped". shell: Run by Hal Finney. Machine: ?? Problems policy: ?? Contact ?? Software: Hal's Remailer. Security: ?? Comments: whitehouse.gov blocked and fully logged. hal(a)alumni.caltech.edu forwards all mail to shell. History: ?? soda: Run by Eric Hollander. Run by: ?? Machine: ?? Problems policy: ?? Blocking of addresses. Mail sent to problem causer. Contact ?? Software: custom. ?? Security: Was keeping full logs till Xenon's bulk mailing venture. ?? Comments: History: ?? Remailer Public Keys: (I've got these).

1 0

FOR Xenon (what's his email?)
by nate＠VIS.ColoState.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Info on the nate(a)vis.colstate.edu remailer colostate: Run by Nate Sammons nate(a)vis.colostate.edu Machine: Sun 4/280 - direct ethernet connection to the Colorado State University backbone. Getewayed to CU/BOulder, and then into the Net backbone. Problems policy: No problems yet. Nobody at CSU really knows about it yet ;-) Contact Nate Sammons nate(a)vis.colostate.edu Software: Hal's Remailer software, modified Security: What do you want to know? - -nate BTW, thanks for the work! - -- +-----------------------------------------------------------------------+ | Nate Sammons <nate(a)VIS.ColoState.Edu> <nate(a)yuma.ANCS.ColoState.Edu> | | Colorado State University Computer Visualization Laboratory | | Data Visualization/Interrogation, Modeling, Animation, Rendering | +-----------------------------------------------------------------------+

1 0

PGP Tools & Magic Money Update
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PGP Tools and Magic Money would not run on a big-endian machine. This did not surprise me, because I don't have one to test it on. I sent a new version to csn.org which fixes a bug in fifo_moven, and includes a #define to force the precision to maximum on a big-endian machine. This should make it work, but will slow it down. The new version, when it shows up, should be in the pgp_tools directory. Go to /mpj, read README.MPJ, and it will tell you how to get into the crypto section. Check the file dates to see if the new version is there yet. I sent them on 2/6. Is there anyone who would like to fix it so it will run properly? The files pgptools.c and ptd.c in the toolkit, and mm.c, s.c, and c.c in the Magic Money system, need to be changed. There is a function called rescale which has to be run on mpi's after set_precision is called. I have no way to test any changes, so I can't write this. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVWRMcGoFIWXVYodAQHSCwQAhA8gZTKDEnzdFyC5UbB0HpvSe299w4F0 bmAA+vplPWNIuFx+RswN6UeCqr9v32tPHTopU4y8twWWJ6p+sA0laqfPVsubtuKK 0bJkasrhIYZDfh4X+RaXgiv50hrcqm87Str0asUOiv1sA7Mv9G5cTxQPwvm0Wiq1 BEjeR5cYn8M= =6VZI -----END PGP SIGNATURE-----

1 0

FOR Xenon (what's his email?)
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

na38138(a)anon.penet.fi or faster, qwerty(a)netcom.com. -=Xenon=- P.S. I'm e-mailing you separately.

2 1

FOR Xenon (address?)
by qwerty-remailer＠netcom.com 17 Dec '03

17 Dec '03

Gee, someone must have snuck into my account and changed all the 48s to 38s. I stand corrected. na48138(a)anon.penet.fi. Mister 38138 must be rather confused due to the "Bomb me!"s he's been getting :-). I'll send him a note to tell him. Maybe I can convince HIM to take over this project even! -=Xenon=-

1 0

Attack on Magic Money and Chaum cash
by Hal 17 Dec '03

17 Dec '03

I think there may be a security weakness in Magic Money coins, and in Chaum's "online" cash system from the Chaum/Fiat/Naor paper. Magic Money coins are numbers of a particular form, RSA-signed by the bank. They look like Y^(1/e) where Y is the number and e is the bank's public exponent corresponding to the particular denomination of the coin. The structure of Y is a 0, a 1, a string of bytes of 0xff, then a defined 18-byte string of bytes, then 16 random bytes. This Y is generated by the user, and is then blinded by multiplying by some random r^e, and sent to the bank. The bank RSA-signs Y*r^e to get r*Y^(1/e), and the user divides by r to get Y^(1/e). This is the coin. The coin is checked by raising it to the power e, to get Y, then checking to see if it is of the proper form. Actually, the Magic Money code only checks the 18-byte special string (just above the 16 random bytes) to make sure it matches the exact byte sequence that is always supposed to be there. In addition the bank checks the 16 random bytes against a list of spent coins to make sure this coin hasn't been spent before. The other relevant point is that the bank has to sign everything you give to it (with payment) - it can't check the bit pattern for legality, since what it is signing is blinded. So you can really get the bank to sign anything. Yesterday I opined that this would be safe, but now I don't think so. The danger I would see is an attacker who gets the bank to sign 2, 3, 5, 7, 11, 13, 17, 19, .... The bank won't know it is signing these special numbers because they are blinded. If someone gets a lot of low primes signed he may be able to forge money, especially with the incomplete checks in the Magic Money program. The idea would be for him to try to factor a legal Y using just the primes he has. If he can find a factorization using only small primes of a number which holds the magic 18-byte sequence in the right place, he can multiply together the signed forms of the primes to produce a signed version of that number. This would be a successfully forged coin. So, the question is whether it would be feasible to collect enough signed small primes to be able to generate more valid coins than you have primes. (It costs you a coin each time you get the bank to sign something, so for this to be a money-making venture you want to get more out of it than you put into it!) I think there are a reasonable fraction of numbers factorable by only small primes. Since there are 2^128 possible money values (based on the 16 random bytes) there should be quite a lot which are factorable by only small primes. Magic Money could help by checking the high bytes as well as the magic 18; it would be take more time to factor 1024 bit numbers than 272 bit ones ((18+16)*8), and there would be fewer that are factorable by small primes. But the problem would still exist. The attacker can run a fast sieve to identify numbers which are factorable in his set. The same attack would apply to Chaum's online cash. His cash is of the form, (x,f(x)^(1/e)), where f() is a one-way function like MD5. To forge this you would again get signed forms of the small primes, then keep picking random x's, until you got a f(x) which could be factored by your set. Presto, you can create a fake coin. I don't know how this attack can be prevented. Hal

1 0

Re: Attack on Magic Money and Chaum cash
by Hal 17 Dec '03

17 Dec '03

A quick follow-up: I suppose a cut-and-choose protocol in the withdrawal would prevent this attack. Instead of sending in one blinded coin to be signed you'd send in 100 blinded candidates, then the bank would pick 99 and you'd reveal the r's for the others (remember, they are blinded with r^e) so the bank can verify they are of the proper form. The bank would then sign the one remaining one and return it to you. What a pain! I hope someone can come up with something better, or show that the attack doesn't work. Hal

1 0

CRYPTA PLUS W/ RSA
by nobody＠rosebud.ee.uh.edu 17 Dec '03

17 Dec '03

01/31 0936 ( BW)(TELEQUIP) Business Editors HOLLIS, N.H. (JAN. 31) BUSINESS WIRE - January 31, 1994--Telequip Corp. today announced the first available PCMCIA compatible flash memory card with high-level embedded security functions. The credit card sized Crypta Plus is targeted at companies implementing secure tokens for mobile computer users. These tokens will allow users to conveniently communicate and access confidential data across public computer and telecommunications networks. Industry experts predict widespread use of secure tokens for corporate and customer communications, database access, electronic funds transfer, defense and government programs, and any other activity involving confidential electronic information transfer. Sales professionals will be able to travel with proprietary information and communicate securely with the home office. Physicians will be able to use tokens, loaded with patient files, to perform rounds, order tests and even write prescriptions that can be signed with a digital signature. It will be possible to process and pay insurance claims directly from the field. Mobile computer users will conveniently carry and securely communicate large amounts of confidential information. Crypta Plus cards have up to 20 Megabytes of solid-state, nonvolatile memory and require no batteries. The memory capacity will increase in conjunction with technological advancements in the flash chip industry. The patent- pending card consists of a data storage unit, storage-access locking circuitry, and a tamper-proof key information substorage unit in the form of a smartcard integrated circuit. A stored program within the smart card integrated circuit allows an access password to be programmed directly into the silicon from an external source. The locking circuitry prevents access to the data stored on the memory card unless the user inputs the identifying password. The smartcard integrated circuit can be used to perform cryptographic functions, including digital signatures. It also provides secure storage for the keys necessary to perform those functions. The Crypta Plus card satisfies three vital needs of mobile computer users: o It can securely store private information in a compact, easily transportable storage device. o It protects electronically stored data against unauthorized access if theCrypta Plus card is lost or stolen. o It makes cryptographic functions and secure key storage readily availableto allow protection and authentication of data being sent to remote sites. Several important technology trends have converged to make the development of the Crypta Plus card possible. The PCMCIA standard has been swiftly adopted by the industry leaders in personal computing. This allows the Crypta Plus card to operate cross-platform in most mobile computing devices. The explosive implementation of distributed networks and wireless communication now makes data security a vital tool for insuring and protecting personal and corporate interests. The rapid growth of Public-key cryptography and digital signature standards is creating secure environments for access, transmission and authentication of private information. Along with U.S. Government standards for digital signatures and encryption, Telequip will embed RSA, the popular Public-key cryptosystem into the Crypta Plus card. "We're excited about Telequip's Crypta Plus technology - it's a perfect match for distributed, robust security systems such as RSA," said Jim Bidzos, president of RSA Data Security Inc. The Crypta Plus card will also fully comply to the soon-to-be published PKCS 11 specification, which will be the first open, published standard for use of Public-key cryptography with tokens and smart cards. PKCS, or the Public Key Cryptography Standards, were established early in 1991 by a consortium of RSA Data Security and its major licensees, including Microsoft, Apple, Sun, Lotus, Digital, National Semiconductor, and many others. The backing of the PKCS consortium members will make PKCS 11 the most important standard for secure tokens and smartcards in the world. Michael F. Jones, president of Telequip Corp., points out that "Public-key cryptography and digital signatures are central to the future of electronic commerce. These techniques depend on successfully keeping the private key and its operations secure. The company believes the Crypta Plus card is an ideal personal token for performing private-key operations and implementing cross-platform security. It can be thought of as a portable object in which data, applications and security all travel together in one convenient package. Users will carry Crypta Plus cards with them to run applications, store data, configure systems, sign documents and access network resources." --30--ed/bos CONTACT: Telequip Corp. Greg Dunne, 603/881-5616

1 0

PGP Tools tester needed
by remailer＠merde.dis.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I tested PGP Tools with the #define in place to force all set_precisions to max unit precision. There didn't seem to be any speed difference, even with a 384-bit key. If this works okay, it could probably be left the way it is. Someone with a big-endian machine, please compile the new version when it arrives, and see if it works. Thank you. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLVWv78GoFIWXVYodAQElbwP+NDsswe8MDnbHhnsZaWdVsb8Nv+cRuyQ4 q1L6isffXz7CJ0I2CnS/guY7yp13qaJPJiiGCoBe+/6E1uwCKj0ePIwP2ifDxf1A 1pQ17Rc11atph4NKIRlvoLbX1xs4qyHfda9CEpccOgdNuq45KZ0d/zFxN+5XvIy8 Bp3N/K00TDM= =GmjR -----END PGP SIGNATURE-----

1 0