December 2003 - cypherpunks-legacy

Re: Need PGP-awareness in common utilities
by Deranged Mutant 17 Dec '03

17 Dec '03

On 6 Jul 96 at 15:11, bryce(a)digicash.com wrote: [..] > I really don't see why programs like majordomo, UseNet > moderation-bots, and most noticeably the PGP key distribution > program are PGP-unaware. > Okay, fine. Having waited for FIVE YEARS or however long it has > been, you who are responsible for such handy dandy programs may now > convincingly argue that you might as well wait for another few > months to get PGPlib. But I sincerely hope that once PGPlib arrives > we don't wait another five years before using it. Good point... > There is another argument that people sometimes make-- that > it is too complicated to ensure pubkey<->True Name. SO WHAT! I've <i>never</i> seen that argument. It's a non-issue for making programs PGP-aware. [..] --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Re: Transforming variable- to fixed-length keys
by Deranged Mutant 17 Dec '03

17 Dec '03

On 7 Jul 96 at 1:47, pgut001(a)cs.auckland.ac.nz wrote: [..] > I've run into a problem in writing a general-purpose n-byte input to m-byte > output transformation function. What this does is take an arbitrary-length > user key and transform it to a fixed-length encryption key (for example an > entered passphrase into a 112-bit triple-DES key). The constraints on memory > usage are: > > - The input (user) key can't be altered (you can't change data passed in by the > caller) > - The user key can't be copied to an internal buffer (it can be of arbitrary > length, and is sensitive material so shouldn't be copied elsewhere) > > In other words there's no temporary storage available apart from what's > provided in the output key. This is almost always a different length from the > input key. > > Some other constraints are: > > - The transformation must be algorithm-independant (it shouldn't, for example, [..] > - The transformation must be able to be iterated to make a password-guessing > attack harder to perform. Hmm. What about the following: Use a constant (non-weak) key for a cipher (perhaps the hash of the passphrase under certain circumstances?) For iteration-0, CFB (or some other feedback mode)-encrypt the passphrase from the input buffer to the output buffer (assuming the library doesn't require that the plaintext and ciphertext be in the same buffer) For following iterations, repeatedly CFB-encrypt the buffer, using a counter in data bytes. This method could use hash algorithms in MDC or Luby-Rackoff forms as well as block ciphers (and perhaps some stream ciphers). Another method might be to seed a PRNG similar to that used in PGP 2.x with the passphrase, have it stir the bytes a number of times, and then use the output as the key: randPoolAddBytes(passphrase, passlen); for(i=0;i<iterationCount;i++) randPoolStir(); randPoolGetBytes(key, keylen); > Here's my initial approach, if anyone has any comments to make on this or knows > of a better way to do it, please let me know. [..] > The first stage in the key hashing prepends the length of the string as a > big-endian 16-bit count to the user key: > > +------+-------------------------------------------------------+ > |Length| User Key | > +------+-------------------------------------------------------+ > > The aim of the hashing is to reduce this variable-length input string to a > fixed-length key appropriate to the encryption algorithm being used. This is > done by treating the user encryption keys as circular buffers and repeatedly > hashing chunks of the user key and xoring the result into the output buffer. [..] > Since the input to the hash function is much larger than its output, a > significant amount of the user key affects each chunk of the encryption key. > The size of each "chunk" is determined by the hash function being used. For > example with the MD4 hash function, 64 bytes of user key affect each 16 bytes > of encryption key. [..] Questions: Are you using the previous chaining-variables/hash for each successive chunk? How do you pad passphrases that are smaller than the minimum input for a hash function? Rob. --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

[RANT] Re: CWD -- Jacking in from the "Keys to the Kingdom" Port
by Alan Olsen 17 Dec '03

17 Dec '03

At 03:27 PM 7/5/96 -0400, Mark M. wrote: >> B) Forget the CONFIG.SYS ... what about kids using Macs or some future >> "Kid Safe" system that has the filters in an eeprom? I'm talking >> about bypassing the censorship on the client-server level. Relatively >> platform independent. > >Using a hardware based filter is about as bad as using the IP security header >fields for content descriptions. It's not at the level where filtering >belongs. Filtering should be at the software level where it currently is. >Since this can easily be broken, it might be better to have "Kid Safe" ISP's >that would use a firewall to filter data. Or even better yet, they could actually teach thier children to deal with such information instead of sheltering them from it. I have dealt with a number of parents who have the idea that they can filter everything the kid hears or sees. The type of intelectual and emotional basketcases that result are not very plesant to interact with. They tend to go through alot of rough times when they have to go out into the world and see a wide variety of views, instead of just seeing what mommy and daddy want them to. What happens from there is generally not very pretty or very fun for the person involved. I do not believe that these types of filters are good. If you have that much concern about what your child can see, then you should not give them net access at all. (And remember to also not to leave them at the library where they might find just as much filth...) "If you don't want your kids to be hit by information, then don't let them play on the information superhighway." Without contradictoy viewpoints, children do not learn how to decern between them. They get indoctrinated into the idea that they must accept ideas as they are fed to them. That learning consists of taking what is provided and not to go out and find those ideas which might be "harmful" or "dangerous" without perental supervision. What we are getting is a bunch of emotional cripples who cannot handle anything intelectually sharper than a rubber ball. (And it must be a ball bigger than two inches in diameter, else they might choke on it.) With these sort of tools, we are conditioning our children that it is OK if someone filters their information before they see it. (Without even knowing the *KIND* of information being filtered, because even *THAT* level of knowledge is harmful and/or proprietary.) That it is OK for some parental figure to eliminate all the "nasty" and "awful" information before someone can hurt themselves with it. That itt is OK to prevent others from viewing information to complex for their childlike minds. We are becoming a nation of the babysat. Anything that our nannys deem harmful is hidden away in the bedrooms of the parental units. And maybe it is harmful. They have to scan through it all day long and look what kind of self-righous pricks they have become! At least I am able to instill some sort of love of knowledge and exploration into my daughter. Hopefully it will stick before the control freaks in this culture are able to knock it out of her... --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "Microsoft -- Nothing but NT promises."

1 0

Re: MacPGP 2.6.3 released
by Zbigniew Fiedorowicz 17 Dec '03

17 Dec '03

I have changed the method of distribution of FatMacPGP 2.6.3. It is now available by anonnymous FTP from Mike Johnson's ITAR compliant crypto archives at ftp://ftp.csn.net/mpj/. My web page http://www.math.ohio-state.edu/~fiedorow/PGP now contains detailed instructions and URL links explaining how to obtain the software from Mike Johnson's site, rather than the software itself. In particular, it is no longer necessary to have a previous version of PGP in order to get FatMacPGP 2.6.3. Note: my system administrators have changed the IP address of www.math.ohio-state.edu this weekend. If your DNS server has difficulty finding the site, you might try http://128.146.111.31/~fiedorow/PGP Feel free to redistribute FatMacPGP 2.6.3 to friends, acquaintances, etc and to put it up on local BBS's. It is your personal responsibility to insure you don't to violate any laws or international treaties doing so. Zig Fiedorowicz

1 0

Netscape 3.0b5 can unanonymize Anonymizer
by Ian Goldberg 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The new netscape has this "feature" where the RHS of KEY=value pairs in tags can contain inline Javascript, which is evaluated to get the actual RHS. For example, the HTML: Did you really think you could be <a href="&{window.open('noanon.html','', 'toolbar=1,location=1,directories=1,status=1,menubar=1,scrollbars=1'); '/'};">anonymous</a>? will open a new, unanonymized, window (you don't even have to click on the link). The main problem is that the Anonymizer doesn't filter out the new way of embedding Javascript: &{this.is("javascript code")}; So, if you use the Anonymizer with netscape 3.0b5, _disable_ Javascript until this is fixed (better yet, disable Javascript and Java entirely, but that's another story for another time...). - Ian -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMd6/nEZRiTErSPb1AQGEPgQAu9NaxafrQDrqdTLUkzQ7k0D6Pq8FxIx1 7Mo3j6ACs6Flp2Tq+2szh6Ch+U0r21LL5NuC3zQ/BA9j/UmqU+c5XM7NRFFGEEhY f1RakLlaiWp+gnxv3dgWWMUZ30iB01kNbIGcl4X3FPLUpyavK45KoqjRJh13s/K+ ACWmg1pgmXk= =23r4 -----END PGP SIGNATURE-----

1 0

Re: NYT/CyberTimes on CWD article
by eli+＠gs160.sp.cs.cmu.edu 17 Dec '03

17 Dec '03

>http://www.nytimes.com/library/cyber/week/0706patrol-reporters.html > "If we believe the encryption scheme has > been compromised, we will make another > one." Heh. It seems that these companies are going to have a problem as long as they use lists of *excluded* sites. Forget insight into company policy; these are global indices of "smut" on the net. (The lists of the more liberal companies are probably most attractive to those not titillated by NOW position papers.) They have to give you the list, and they have to give you software that uses it, so there's no way to achieve complete secrecy. I think the best they can do is to distribute a list of hashed URLs. -- Eli Brandt eli+(a)cs.cmu.edu

1 0

Re: Radiological Survey Meter (fwd)
by David Lesher 17 Dec '03

17 Dec '03

If you want such for random #'s.... Tony S. Patti <103514.36(a)CompuServe.COM> of Cryptosystems Journal mentioned he'd found a meter as follows: RESOURCES UN-LTD. 800-810-4070. Victoreen Model 1 from 1964, in the original box. $39.00 -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Re: doubleclick monitoring web browsing habits
by dp＠tir.com 17 Dec '03

17 Dec '03

How do I get off the list.......

1 0

demo rating
by bryce＠digicash.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Certificate-Type: Chudov/Wilcox Content/Author Rating Rating-Type: Content Object-ID: Date: Sat, 06 Jul 1996 23:16:59 +0200/From: bryce(a)digicash.com Topicality: 10 Entertainment: 10 Value: 10 Signer: 0x2c2998ad Timestamp: Sat Jul 6 23:59:15 MET DST 1996 Signature: <wrapped> -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.1b2 iQB1AwUBMd7hzkjbHy8sKZitAQE2EgL/SzCdEDihADRwDnGMy/GmkUF/3z082FRz uv0QbyR32Se15q+nkNZoj0vrMB9oFdFDv5fFON7oun3kLN+BukCAQTwta2+CYaIQ F6CwqeZz5TdAFYLB8lrgM0jAQDNaIiI6 =q+l+ -----END PGP SIGNATURE-----

1 0

Re: Need PGP-awareness in common utilities
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 23:56 7/6/96, bryce(a)digicash.com wrote: >Hm. That might be an interesting addition to my plan, but the >first step is to generate ratings and to consume them at each >individual's mail-handling site. So I, for example, would run a >script every time I received mail (or every hour, or every day, >etc) which looked for ratings certificates, PGP-verified them, >and saved the rating in a database. Then I would run another >script (every time I received mail, or every hour, etc.) which >identified incoming messages and _did_ something to them if >there were sufficient ratings in the database to merit _doing_ >something to them (e.g. delete, promote to a "well-rated" >folder, demote to a "poorly-rated" folder, forward to my >friends, forward to my enemies, etc.). As has been discussed in numberous previous threads on this topic, even a passive rating system is very hard to implement. The computer doesn't know if you hit delete because the post was garbage or because you are running late on some project. An active rating system is virtually impossible to implement, given the added workload on the readers. Good lucky anyway, -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. Disclaimer: My opinions are my own.

2 1