December 2003 - cypherpunks-legacy

Re: "Email-Firewalls" / Instant Corporate PGP
by Hal 17 Dec '03

17 Dec '03

From: Vincent.Cate(a)FURMINT.NECTAR.CS.CMU.EDU > #!/bin/csh -f > # > # Vince Cate > > setenv PGPPATH /usr/vac/pgp > setenv PGPPASS "not really vinces passphrase" > > cd $PGPPATH > > cat > mailtmp.asc > > egrep 'Date:|From:|Subject:|To:' mailtmp.asc > mailtmp > echo " " >> mailtmp > > pgp -f < mailtmp.asc >> mailtmp > > /usr/ucb/mail -s "Was encrypted" vac < mailtmp > > exit 0 A more secure way is not to setenv PGPPASS but rather: setenv PGPPASSFD 1 and then (echo "vinces passphrase" ; cat mailtmp.asc) | pgp -f >> mailtmp The PGPPASSFD means take the passphrase from file descriptor 1, which is the standard input. This way it never appears in the environment of a process. Many unix systems have a switch to ps to show all processes' environments. Hal

2 1

No Subject
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hello again. I have been too busy to post very much to the net recently, but I'm still here. As an experiment, I wanted to hack PGP 2.3A to produce and use 2048-bit keys. There was nothing sophisticated about this hack. I just changed MAX_BIT_PRECISION in mpilib.h to 4096, upgraded the POOLSIZE in random.c to 1024, and changed the version number to "2.3b" in pgp.c so I would know when I am running the hacked version. Generating 2048 bit keys is very painful, because over 260 bytes need to be typed for the pool. It took over five minutes to generate the key after the pool was full. Once created, though, encryption and decryption are not significantly slower than with 1024 bit keys, at least not on my 486DX2/66 running Linux 1.0. It only took 3 seconds to encrypt pgpdoc1.txt (using -ea) and 8 seconds to decrypt the result. Of course, the large keys created with "2.3b" are not compatible with any other version. I attempted to use the PSEUDORANDOM compiling flag, but pgp refused to link. I suppose I should put some more effort into resolving this problem. I am sending this note out for those who would like to play with big keys, but did not want to take the time to hunt through the source looking for the necessary values to change. Please treat this as an *experiment*. It is entirely possible that "2.3b" is potentially insecure, because I have not made any attempt to locate all of the memory-erasing routines that clean up after key generation and encryption and confirm that they erase all of the new memory used. I hope that the more sophisticated cypherpunks will not sneer too much at my feeble beginner's efforts. I would like to hear from anyone who performs this experiment, perhaps with a more sophisticated hack, and does timing tests on other machines, especially slower machines like 386's and 68020's. Lady Ada -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLd53bKXNQdJx1hMZAQHaEwQApOWGq0P+OqsgYolbZrjaIWhrghhV9KcY X5DqgKK8NLdND1aR17JVwUEQeo3eFok6NTjioiLg4sIQdTQNOX8Nd9bQgMxswyyi EIe/6Ki9YrxlArteUoc0zy7MaB0V1sxH3CdvEQmLnr8XKU03pnD7FCZXedjhic93 +Tt4fNrNGYk= =LmWA -----END PGP SIGNATURE-----

1 0

PGP2.5 pulled and PGP2.6 coming....
by lile＠netcom.com 17 Dec '03

17 Dec '03

I found this on MIT's ftp server... -lile at: net-dist.mit.edu ftp> pwd 257 "/pub/PGP" is current directory. ftp> ftp> get README - 200 PORT command successful. 150 Opening ASCII mode data connection for README (1670 bytes). -----BEGIN PGP SIGNED MESSAGE----- The beta version of PGP 2.5 is now being removed from MIT file servers. In about a week, MIT will begin distribution of a new release numbered PGP 2.6. PGP 2.6 will incorporate a new version of RSAREF, scheduled for release by RSA Data Security next week, and will also correct bugs that were reported in PGP 2.5. In order to fully protect RSADSI's intellectual property rights in public-key technology, PGP 2.6 will be designed so that the messages it creates after September 1, 1994 will be unreadable by earlier versions of PGP that infringe patents licensed exclusively to Public Key Partners by MIT and Stanford University. PGP 2.6 will continue to be able to read messages generated by those earlier versions. MIT's intent is to discourage continued use of the earlier infringing software, and to give people adequate time to upgrade. As part of the release process, MIT has commissioned an independent legal review of the intellectual property issues surrounding earlier releases of PGP and PGP keyservers. This review determined that PGP 2.3 infringes a patent licensed by MIT to RSADSI, and that keyservers that primarily accept 2.3 keys are mostly likely contributing to this infringement. For that reason, MIT encourages all non-commercial users in the U.S. to upgrade to PGP 2.6, and all keyserver operators to no longer accept keys that are identified as being produced by PGP 2.3. -----BEGIN PGP SIGNATURE----- Version: 2.5 iQBVAgUBLdezEVUFZvpNDE7hAQGRhAH+KACuaOfMynsL9QGmJpp9ToWEJB+1OFGb whoZbHbw/H268zIrFoCcm24UITcBiIcuSsk3ydpMyFTb/YBgIbzgqQ== =EbV1 -----END PGP SIGNATURE----- 226 Transfer complete. remote: README 1704 bytes received in 0.27 seconds (6.1 Kbytes/s) ftp>

1 0

Re: "Email-Firewalls" / Instant Corporate PGP
by Hal 17 Dec '03

17 Dec '03

From: ecarp(a)netcom.com (Ed Carp) > > A more secure way is not to setenv PGPPASS but rather: > > setenv PGPPASSFD 1 > > The PGPPASSFD means take the passphrase from file descriptor 1, which is > > the standard input. > > I thought stdin was 0, and stdout was 1... Oops; Ed is right, of course; that should be setenv PGPPASSFD 0. Hal

1 0

Re: Is my DH exchange secure?
by Hal 17 Dec '03

17 Dec '03

> With a strong prime, there is no need to use generators, as Eric implied. My wording here was a little clumsy; I was not contradicting Eric but rather attempting to amplify his comments. There is no need to look for primitive roots (elements of maximal order); rather you just want to avoid elements of low order. I found the paper I referred to which described the tradeoffs between the order of the group and the size of the modulus. It is "Efficient Signature Generation by Smart Cards", by C.P. Schnorr, in the Journal of Cryptology, 1991, v4, pp161-174. This is the patented Schnorr signature which has been the basis for PKP's claim that the federal Digital Signature Standard infringes the Schnorr patent. (Bruce Schneier recently posted on sci.crypt that a paper presented at Eurocrypt 94 analyzed all the different discrete- log based signature scheme, and in his opinion cast doubt on this claim of infringement.) Schnorr deals with a prime p, and a smaller prime q which divide p-1. In his system, q is a lot smaller than p, just big enough to provide the requisite security. Small q's allow for faster calculation of g^x since x is, say, 140 bits rather than 512 bits. Here is what Schnorr writes on page 163 (he uses "alpha" where we were using g, as the generator of the group): "The Security Complexity 2^t. We wish to choose the parameters p, q so that forging a signature or an authentication requires about 2^t steps by known methods. For this we choose q >= 2^(2t) and p such that 2^t is about exp(sqrt(ln p ln ln p)). The security number t may depend on the application intended. For signature we consider in particular t=72 rather that [sic] t=64, since 2^64 steps may be insufficient in view of the rapid technological progress in computing power and speed. For p>=2^512 and q>=2^140 the discrete logarithm problem requires at least 2^72 steps by known algorithms. (It may soon be necessary to increase the lower bound p>=2^512 due to the current progress in computing discrete logarithms.) The restriction that the order of [alpha] is a prime much smaller than p provides no advantage in any of the known discrete logarithm algorithms provided that q>=2^140. The prime q is necessary to avoid an index calculus attack and a square root attack (see Section 2)." The attack described in section 2 is interesting. Also known as the baby-step-giant-step attack, it is a simple meet-in-the-middle-technique. Suppose you wanted to solve a^x=y given a and y. Suppose for simplicity that x is known to be in the range of 0 to 100. What you can do is to calculate two lists. The first is ( a^10, a^20, a^30, ..., a^90 ). The second is ( y/(a^1), y/(a^2), y/(a^3), y/(a^4), ..., y/(a^9) ). Then you just look for a number which is common to both lists. If a^20 is the same as y/(a^4) then we know that y = a^24. So this takes square root of q in time and space. Schnorr says that Pollard has a trick to use less space. (Remember the discussion we had here some time back of the prac- ticality of meet-in-the-middle attacks given the huge space needs for even 2^64 hashes? I think Pollard's trick may apply to those as well.) Hal

1 0

Re: "Email-Firewalls" / Instant Corporate PGP
by Vincent.Cate＠FURMINT.NECTAR.CS.CMU.EDU 17 Dec '03

17 Dec '03

ecarp(a)netcom.com (Ed Carp): >I thought stdin was 0, and stdout was 1... That works much better!!!! Thanks. I also made an outgoing "pgp-send" and renamed the incoming to "pgp-receive". The pgp-send can be used for many users but does need a new line in your .maildelivery for each. They are both FTPable from: ftp://furmint.nectar.cs.cmu.edu/security I also include them below. -- Vince #!/bin/csh -f # # pgp-send # # This lets you set up mail addresses like "vac+eric" so you # can send that you send encrypted mail without any extra work. # To use this add lines like the following to your .maildelivery # file: # # Addr vac+tovince pipe ? /usr/vac/pgp/pgp-send vac+pgp(a)cs.cmu.edu # # The "vac+tovince" is your own alias for this person. The # vac+pgp(a)cs.cmu.edu is both the mailing address and what PGP uses # to find the key. # # This assumes PGPPATH is set and pgp is on your PATH. # If not either fix that, or add a "cd" to that directory. # # Note that the unecrypted mail will be on your machine a little # longer this way so this is a bit less secure than encrypting the # mail by hand. However, this is a short period, and if your # machine's security is broken they could have read your mail as you # wrote it. # # With this, someone would need to do some "breaking and entering" # to get at your mail. # # Vince Cate # vac(a)cs.cmu.edu # # cd /usr/vac/pgp set TO = $1 cat > sendtmp.txt pgp -fe $TO < sendtmp.txt | /usr/ucb/mail -s "encrypted mail" $TO /bin/rm sendtmp.txt exit 0 #!/bin/csh -f # # pgp-receive # # The idea is to have an email address like "vac+pgp" that causes # this script to be run which decrypts the mail and then sends it # to your normal address. # # This lets you receive encrypted mail on a Unix machine without # having to do anything extra. It will work with any Unix machine # that supports .maildelivery files using any mail reader. It # could even be used to forward mail to non-Unix machines if you # thought you were on a reasonably secure net. The entry in the # .maildelivery file should be something like: # # Addr vac+pgp pipe ? /usr/vac/pgp/pgp-receive # # This would be safe if your host machine were safe. In any case, # someone has to do some "breaking and entering" to get your mail. # So this is much better than no encryption at all. # # This file is ftp://furmint.nectar.cs.cmu.edu/security/pgp-receive # Vince Cate # vac(a)cs.cmu.edu # # For me the pgp directory is protected, so is a good to be in # that directory both to drop the temporary file. # The setenve PGPPASSFD 1 tells PGP to get the passphrase from # the standard input. To install this you need to edit the 3 # places with a "vac". setenv PGPPATH /usr/vac/pgp setenv PGPPASSFD 1 cd $PGPPATH cat > mailtmp.asc egrep 'Date:|From:|Subject:|To:' mailtmp.asc > mailtmp echo " " >> mailtmp # This is less secure since some Unix ps commands can show other # user's environemnts. # # setenv PGPPASS "not really vacs passphrase" # pgp -f < mailtmp.asc >> mailtmp setenv PGPPASSFD 0 (echo "not really vacs passphrase" ; cat mailtmp.asc) | pgp -f >> mailtmp /usr/ucb/mail -s "Was encrypted" vac < mailtmp exit 0

1 0

Re: "Email-Firewalls" / Instant Corporate PGP
by Vincent.Cate＠FURMINT.NECTAR.CS.CMU.EDU 17 Dec '03

17 Dec '03

The pgp-send body should just be: >set TO = $1 > >cat | pgp -fe $TO | /usr/ucb/mail -s "encrypted mail" $TO Can always check: ftp://furmint.nectar.cs.cmu.edu/security/pgp-send ftp://furmint.nectar.cs.cmu.edu/security/pgp-receive For latest version... -- Vince

1 0

Cantwell Bill Clears Committee
by jmdaluz＠kquest.com 17 Dec '03

17 Dec '03

I found this in sci.crypt today. Does anyone know if a full House vote on the export bill is the next step here? In any case, it's definitely time to contact our Reps again and remind them of the importance of this act. --------------------------------------------- From: castor(a)hassle.Stanford.EDU (Castor Fu) Newsgroups: sci.crypt Subject: US Crypto Export controls may weaken -- Cantwell bill clears committee Followup-To: talk.politics.crypto Date: 21 May 1994 20:15:58 GMT Organization: Stanford University Lines: 21 Distribution: world Message-ID: <CASTOR.94May21131558(a)hassle.Stanford.EDU> NNTP-Posting-Host: hassle.stanford.edu X-status: N In the clari.nb.govt an article (<NB940520.15(a)clarinet.com>) reports that Maria Cantwell's (D-WA) amendment to the Export Administration Act has cleared the House Foreign Affairs committee. The bill would turn over responsibility for all non-military crypto to the Commerce dept, and that most forms will be exportable without licensing. For more information on the bill, HR3627, look for Cantwell at ftp://ftp.eff.org/pub/EFF/Policy/Legislation/Bills_by_sponsor Presumably, this means the bill will proceed to a vote before the House. (Question for US readers: does your rep's position on HR3627 match yours?) I realize this does not quite meet the "charter" of sci.crypt, but since it is relevant news, I hope you will forgive the intrusion. I have directed followups to talk.politics.crypto -Castor Fu -- Jose M. daLuz KnowledgeQuest Online Research jmdaluz(a)kquest.com (508)996-6101(vox)/(508)996-6215(fax)

1 0

why moderate when you can write some code instead?
by D. J. Bernstein 17 Dec '03

17 Dec '03

(I'm not on cypherpunks... but alt.fan.david-sternlight is. [chuckle]) Attached is an article I wrote recently on the proposed moderation of alt.sources. You can see its possible relevance to talk.politics.crypto and sci.crypt. Someone just has to sit down and add a few lines to rn. ---Dan Path: silverton.berkeley.edu!djb From: djb(a)silverton.berkeley.edu (D. J. Bernstein) Message-ID: <5423.May2612.03.1993(a)silverton.berkeley.edu> Date: Wed May 26 12:03:19 GMT 1993 Newsgroups: alt.sources.d,alt.config Subject: Re: Serious proposal to make alt.sources MODERATED References: <1993May10.171718.26298(a)infodev.cam.ac.uk> Organization: IR Whenever a social problem is caused by technology, it can be fixed by better technology. I want to tell rn, ``Make me a newsgroup consisting of certain articles from alt.sources. Which articles? Well, read through alt.sources.index, take all the Message-ID's listed there, and select those articles from alt.sources for me. Call this new newsgroup alt.sources.indexed. Oh, yeah, dump all the other articles into alt.sources.nonindexed.'' Maybe this would be easier for rn if alt.sources.index articles had a specialized ``article selector'' format. No big deal. All that's important is that there be _some_ selector format which we can use. Note that I might decide later that I don't like alt.sources.index; I prefer the selectors which Joe Shmoe posts every day in alt.frobozz. I should be able to tell rn, ``Make me a virtual group with every article from Joe titled SOURCE SELECTOR. Call it alt.frobozz.shmoe.'' Then I can use alt.frobozz.joeshmoe in place of alt.sources.index. I expect that selectors, when properly implemented, will entirely replace moderated groups. They'd be an easy first step for the USENET Interface Project. ---Dan

1 0

Re: How bout that unbiased Clipper debate?
by nelson＠crynwr.com 17 Dec '03

17 Dec '03

In re Phil Karn's comment that Stuart Baker was an asshole. Perhaps he was just being one for pay? (see below): Newsgroups: alt.wired From: brian(a)tired.wired.com (Brian Behlendorf) Finally, the article by Baker was almost word-for-word the same pitch he had given at CFP and other places he's had the opportunity to speak. I wonder if his recent resignation from the NSA has anything to do with this... -russ <nelson(a)crynwr.com> ftp.msen.com:pub/vendor/crynwr/crynwr.wav Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Quakers do it in the light Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

1 0