- cypherpunks-legacy@lists.ogf.org

Relation between number theory and cryptography
by Clark Reynard 14 Jul '93

14 Jul '93

Hi. Me again. I asked this one a while back and got no response. sci.crypt was equally unresponsive. It concerns the possibly obscure relation between cryptography, number theory and information theory. Is there considered to be a one-to-one isomorphism between the units in a plaintext-cyphertext pair? By this, I mean, are they considered to contain the same information? If not, does encryption lessen or increase the amount of information in the units of the plaintext-cyphertext pair, and why? Is this affected by whether or not the key is known? If the key has been irretrievably lost, does this lessen the amount of information, or does the 'potential' informational content remain the same? Is cryptography considered to be as simple as, say, Huffman coding, for purposes of informational content? That is, is the relationship between the units of a plaintext-cyphertext pair considered to be more or less 'transparent,' or entirely isomorphic? Does the Second Law of Thermodynamics enter into this? Is there a minimum amount of energy required to extract information from cyphertext, or a minimum amount of waste of energy? If these questions are too difficult to answer in a short article, does anyone have citations to a source which could explain this to me? I'm not certain how much research has been done into this rather esoteric topic, and my main interest is theoretical, though I'd be interested in knowing any practical applications of information theory and number theory to cryptography. ---- Robert W. Clark Just Say No! to the rclark(a)nyx.cs.du.edu Big Brother Chip

1 0

Remailer comments
by wmo＠rebma.rebma.mn.org 13 Jul '93

13 Jul '93

While checking for problems in the rebma remailer's logs, I noticed the following: Some folks have sent PGP encrypted test messages without including the :: Encrypted: PGP text, or the Encrypted: header. Also, some folks have tried some variations on the :: Request-Remailing-To: line, such as just To:, putting the :: and the Request- line together, etc. Those things won't work, and you'll get nothing back. Anyone who has tried to use the remailer here and has failed, send me a note and I'll send you the instructions. Or, I think Karl (Karl Barrus <elee9sf(a)Menudo.UH.EDU>) has a complete set of information and scripts to help out. Karl, you might consider including a terse list of instructions with your regular remailer mailing. (Oh, to avoid starting the remailer-operator-responsibilities-discussion, I'll state my policy on logs on this machine. I glance at 'em to make sure that there aren't any errors in the scripts, and then I remove 'em. If you're going to be an asshole via my remailer, I'd appreciate it if you used PGP so that there's no clear text here, so that I don't have to ever revise this simple policy.) -Bill

1 0

Hoptoad disk screwup
by gnu 13 Jul '93

13 Jul '93

The partition that holds /var/spool has had two hiccups in the last few days. This has caused some downtime, and possibly caused some mail to be lost. As far as I know, the NSA didn't do it :-))), so y'all can keep your paranoia at the usual level, whatever that is. John

1 0

REMAILER HEADERS
by remail＠tamsun.tamu.edu 13 Jul '93

13 Jul '93

Some of you know the sender of the below message, please don't blow my cover, I'm testing the remailers and people's knowledge of message id's (if that would even be an accurate way of tracing the message). Cypherpunks remailer addresses and headers from those sites appear below. If you can trace the origin (sender) of this message please send me mail personally rather than to the list. I'm using my favorite remailer here and I want to make sure it's working right. I have sent mail to the below sites as a test for anonymous remailing returns and to see what headers I get back. It has been maybe 4 days now since I began this experiment, some of the sites below have still not remailed my test message. My main curiosity in this quest is to determine what each header will look like when the mail is recieved. I think this is important in determining which remailer to use. The below is the list of remailers with the "unique header to remailer" info below each site number. If you wish to discuss this matter further, please send a follow up message to the cypher list with your address included and "Re: Unique header". I'm really not too concerned about remaining anonymous, I just want to see if this scheme is really airtight! Thanks! -z A typical mail header looks similar to the below: (I have removed the date, time, etc. to protect my privacy) >From rebma!remailer(a)kksys.mn.org Thu Jul x 00:38:01 1993 Received: by ahost.some.school.edu (5.57/Ultrix3.0/cc-ix.mc-1.5) id AA02491; Thu, x Jul 93 19:00:54 -0500 Received: from kksys.mn.org by uum1.mn.org with bsmtp (Smail3.1.28.1 #3) id m0oE6Du-00007JC; Thu,x Jul 93 00:21 CDT Received: from rebma by kksys.mn.org with uucp (Smail3.1.28.1 #13) id m0oE5jG-0007TsC; Thu,x Jul 93 00:50 CDT Received: by rebma.rebma.mn.org (Smail3.1.28.1 #1) id m0oE6nS-0002CzC; Thu, 8 Jul 93 17:58 PDT Message-Id: <m0oE6nS-0002CzC(a)rebma.rebma.mn.org> Date: Thu, x Jul 93 17:58 PDT To: me(a)myhost.some.school.edu From: nobody(a)rebma.rebma.mn.org Subject: 9 Remailed-By: Mr. Nobody <remailer(a)rebma.mn.org> Status: O ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Check out the pub/cypherpunks directory at soda.berkeley.edu (128.32.149.19). Instructions on how to use the remailers are in the remailer directory, along with some unix scripts and dos batch files. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ =========This is where the list of remailers and headers begins=========== *** Please keep in mind that in the below I included only the "unique to *** remailer" parts of the header.*** 1: nowhere(a)bsu-cs.bsu.edu From: Anonymous <nowhere(a)bsu-cs.bsu.edu> To: omitted X-Remailed-By: Anonymous <nowhere(a)bsu-cs.bsu.edu> X-Ttl: 0 X-Notice: This message was forwarded by a software- automated anonymous remailing service. 2: hh(a)cicada.berkeley.edu From: nobody(a)cicada.berkeley.edu 3: hh(a)pmantis.berkeley.edu No response after 4 days 4: hh(a)soda.berkeley.edu From: nobody(a)soda.berkeley.edu Remailed-By: Eric Hollander <hh(a)soda.berkeley.edu> 5: 00x(a)uclink.berkeley.edu From: nobody(a)uclink.berkeley.edu Remailed-By: Tommy the Tourist <tommy@out> 6: hal(a)alumni.caltech.edu From: nobody(a)alumni.cco.caltech.edu Comments: This message is NOT from the person listed in the From line. It is from an automated software remailing service operating at that address. Please report problem mail to <hal(a)alumni.caltech.edu>. 7: ebrandt(a)jarthur.claremont.edu From: nobody@eli-remailer Remailed-By: Eli Brandt <ebrandt(a)jarthur.Claremont.EDU> Source-Info: From (or Sender) name not authenticated. 8: phantom(a)mead.u.washington.edu No response after 4 days 9: remailer(a)rebma.mn.org From: nobody(a)rebma.rebma.mn.org Remailed-By: Mr. Nobody <remailer(a)rebma.mn.org> ** The reamiler at rebma.mn.org took 3+ days to remail. This could be an advantage to some, disadvantage to others. You decide. 10: elee7h5(a)rosebud.ee.uh.edu From: nobody(a)rosebud.ee.uh.edu 11: hfinney(a)shell.portal.com From: nobody(a)shell.portal.com Comments: This message is NOT from the person listed in the From line. It is from an automated software remailing service operating at that address. Please report problem mail to <hfinney(a)shell.portal.com>. 12: remail(a)tamsun.tamu.edu From: remail(a)tamsun.tamu.edu Remailed-By: Anonymous <remail(a)tamsun.tamu.edu> 13: remail(a)tamaix.tamu.edu From: remail(a)tamsun.tamu.edu Remailed-By: Anonymous <remail(a)tamsun.tamu.edu> 14: remailer(a)utter.dis.org Received: by soda.berkeley.edu (5.65/KAOS-1) id AA13859; Tue, 6 Jul 93 03:09:09 -0700 Received: by merde.dis.org (4.1/SMI-4.2) id AA04354; Tue, 6 Jul 93 03:11:48 PDT From: nobody(a)dis.org Remailed-By: remailer bogus account <remailer(a)utter.dis.org> 15: remail(a)extropia.wimsey.com No response ever! ...unless you use encryption. Details will follow in the near future. NOTES: #1-#5 no encryption of remailing requests #6-#14 support encrypted remailing requests #15 special - header and message must be encrypted together #9,#14,#15 introduce larger than average delay (not direct connect) #9,#14,#15 running on privately owned machines

1 0

sorry if you already read this, but...
by TO1SITTLER＠APSICC.APS.EDU 13 Jul '93

13 Jul '93

From: SMTP%"more(a)hpcwire.ans.net" 13-JUL-1993 23:35:43.74 To: to1sittler(a)apsicc.aps.edu CC: Subj: 738 ANS CO+RE Security to Use RSA Public Key Cryptography Date: Tue, 13 Jul 1993 22:38:28 -0700 From: More Select News <more(a)hpcwire.ans.net> Message-Id: <199307140538.AA23787(a)hpcwire.ans.net> To: to1sittler(a)apsicc.aps.edu Subject: 738 ANS CO+RE Security to Use RSA Public Key Cryptography ANS CO+RE Security to Use RSA Public Key Cryptography ----------------------------------------------------------------------------- Contacts: ANS CO+RE Systems Inc. RSA Data Security Inc. Carol Harvey, Public Affairs Kurt Stammberger, Technology Marketing 703/758-7700 415/595-8782 harvey(a)ans.net kurt(a)rsa.com ANS CO+RE's Security Services to Incorporate RSA Public Key Cryptography REDWOOD CITY, CA and ELMSFORD, NY -- ANS CO+RE Systems Inc. announced major new extensions to its advanced InterLock family of security services. The new features focus around the incorporation of RSA Data Security Inc.'s Public Key Cryptosystem. RSA's techniques are widely acknowledged as being the most secure means of data encryption and authentication available today. InterLock is a suite of security services that control access among segments of an enterprise's private IP network and/or among multiple enterprises that communicate over a IP private network. InterLock also controls access between private networks and the public Internet. In addition to RSA key exchange- enabled end-to-end encryption, InterLock services include TELNET, FTP, SMTP, X windows, and NNTP. Network access is controlled by a rule base that can be configured for each user according to userid, network service, inbound/outbound connection, time of day, day of week, public/private network and/or host address, authentication method and enforced encryption. ANS CO+RE developed the new product with RSA's BSAFE 2.0 toolkit, the world's best-selling cryptography software developer's kit. BSAFE is the same toolkit that served as the encryption "engine" for the developers of Novell NetWare 4.0, Lotus Notes, WordPerfect InForms and Fischer International Workflow.2000. BSAFE provides an easy path towards integration of state-of- the-art encryption and digital signature technology -- without requiring the developer to have a background in cryptography or number theory. RSA security technology is a standard on the Internet, the world's largest network, and on the secure networks of businesses and financial institutions worldwide. RSA president Jim Bidzos, commenting on the deal, said, "As the Internet grows, more and more confidential and mission-critical data is flowing over it -- unfortunately, the open nature of the Internet makes that information relatively easy to steal, alter or forge. The RSA-based Internet PEM (privacy-enhanced mail) standards have provided a good start by offering secure messaging capabilities to Internet users -- but now any IP user can get a complete network security implementation, with RSA built right in, with ANS CO+RE InterLock." Al Hoover, VP of Information and Applications for ANS CO+RE stated, "We've been looking to incorporate a public-key based key management system that is both as advanced as the other InterLock services and easy to integrate. RSA's Public Key Cryptography fills that need perfectly, and we will be pleased to offer it to our customers beginning in the fourth quarter of this year. It represents our continuing efforts to build on our foundation of quality security services." RSA Data Security Inc. is a recognized world leader in cryptography. The Company develops and markets software developer's kits, end-user products, and provides comprehensive consulting services in the cryptographic sciences. RSA technology has been embedded in the products of companies such as IBM, Apple Computer, DEC, Microsoft, Sun Microsystems, Novell, Lotus, Motorola, Northern Telecom, AT&T, WordPerfect, Fischer International, General Electric, Hughes and many others. Founded in 1982 by the inventors of the patented RSA Public Key Cryptosystem, the company is headquartered in Redwood City, California. ANS CO+RE Systems, Inc. is a wholly owned subsidiary of Advanced Network & Services, Inc. of Elmsford, NY. In addition to offering network security services, the company markets attachments to its nationwide T3 backbone network, and provides other related support, such as network management outsourcing, network design and engineering, and systems integration. ----------------------------------------------------------------------------- InterLock and the InterLock logo are servicemarks of ANS CO+RE Systems Inc. X Windows is a trademark of the Massachusetts Institute of Technology. The RSA logo and BSAFE are trademarks of RSA Data Security, Inc. Copyright 1993 HPCwire.

1 0

Whose opinion? (was Re: anonymous mail)
by greg＠ideath.goldenbear.com 13 Jul '93

13 Jul '93

-----BEGIN PGP SIGNED MESSAGE----- Matthew B Landry writes: > On the subject of whether personal postings should be considered > as representing the company, I should point out that: > > 1: NSF and several regional nets have acceptable use policies which > do not permit commercial use. > 2: Messages posted by the company (or by someone who is assumed to > represent the company) would be in violation of these policies if the > messages crossed the applicable networks. I don't think a description of a policy is at all clearly "commercial use". Advertising, and use of net resources in the course of doing business seem to be commercial use - but a discussion with outside folks about policies or conditions doesn't seem to be commercial use. To suggest that net traffic originating at a site with a .com domain name is commercial seems to over-reach. > 3: There is no way to prevent a specific message over usenet from crossing > a specific network. > 4: The owner of a network site (the company) is assumed to be responsible > for any "unacceptable use" traffic that comes from the site. I don't think I buy this one, either. If I can't control traffic (see #3) how is it reasonable to say that I am responsible for it (#4)? > 5: This liability would leave the company open to having its net feed > cut off for such unacceptable use. This assumes that the net feed comes from a provider which restricts commercial use. Some providers (like Alternet) welcome commercial use. > It is therefore in the best interests of any corporation with > Internet/Usenet access to _assume_ that messages posted by its employees > are not company business. It is probably convenient for policymakers to make this assumption. It is, however, perhaps naiive. If I see a posting from Jim Bizdos, I *do* assume that he is speaking for RSADSI/PKP, unless he makes efforts to disclaim such attribution. Ditto for other folks who I know or suspect hold positions of power or influence with other institutions. I suspect other folks on the net react similarly to posts (apparently) coming from people who may have some impact on corporate/institutional policy/behavior. I think it's probably best to assume that people *will* associate what people post from a site's name with that site, especially absent disclaimers to the contrary. -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLEN3H33YhjZY3fMNAQHMAQP/VJX86pXxyZqXaEHsWIeH1cLnjsPW/9cR gfNdp/3KRwZBwLAR/BbqPlfZUnY6VHJKtbJUHVDSMAOcgRZ9E9+3L6ghBFX3J4lO aKS9SnAsEDOSY5PMqAF7z9YShP1FqVuRRq7XKMF6KjIfH/+rIsjj5AR0kSa5BB6p kbBW/jis1U0= =iuOy -----END PGP SIGNATURE----- -- Greg Broiles greg(a)goldenbear.com Golden Bear Computer Consulting +1 503 465 0325 Box 12005 Eugene OR 97440 BBS: +1 503 687 7764

2 1

new crypto standard to be announced
by smb＠research.att.com 13 Jul '93

13 Jul '93

Today's NY Times says that Novell and a bunch of other companies (including AT&T, but I haven't been able to track down any details yet) *and* the British Ministry of Defense are going to announce a new crypto standard. The article indicated that RSA and DES were going to be used, and portrayed the announcement as a rebuff to Clipper. --Steve Bellovin

2 1

collecting references on parallel implementations of crypto s/w
by jet＠nas.nasa.gov 13 Jul '93

13 Jul '93

Any pointers? I'm about to head off to Boston for two weeks to do work at a vendor, need some 'light reading' for the hotel and plane... -- J. Eric Townsend jet(a)nas.nasa.gov 415.604.4311| personal email goes to: CM-5 Administrator, Parallel Systems Support | jet(a)well.sf.ca.us NASA Ames Numerical Aerodynamic Simulation |--------------------------- PGP2.2 public key available upon request or finger jet(a)simeon.nas.nasa.gov

1 0

subscribe Egon <RClarke@AC.DAL.CA>
by RCLARKE＠ac.dal.ca 13 Jul '93

13 Jul '93

subscribe Egon <Rclarke(a)AC.DAL.CA>

1 0

PGP 2.3 now avail for Intergraph Clipper CPU
by fnerd＠smds.com 13 Jul '93

13 Jul '93

paul(a)poboy.b17c.ingr.com (Paul Robichaux) says: > I recently finished porting and testing PGP 2.3 for the Intergraph Clipper > C400 CPU. ... Bravo! Cypherpunk makes moral statement and scores rhetorical point with code! Except, I wish the targets of the joke could decode it. -fnerd quote me

1 0