December 2003 - cypherpunks-legacy

Re: Netscape hole without .Xauthority (fwd)
by Michael J Gebis 17 Dec '03

17 Dec '03

Robert Owen Thomas wrote: > more and more, networks are becoming flooded with X traffic. although X > has always been known to be a potential security hole, i think X-attacks > are going to increase dramatically in the coming months. > > i commonly hear of sights with Xauthority enabled, only to have the user > community type "xhost +" at the prompt. bad karma. the days of pumping > rude & crass noises to someone else's workstation will soon graduate to > more nefarious and insidious attacks. > > is anyone looking into a means of securing X (above and beyond the current > weak solutions)? I have not used it for this purpose, but ssh claims to do "Secure X11 sessions." Actually, I'm interested in what the cypherpunks think of ssh in general; I'm not able to do a strong analysis of the code myself. If it does everything it claims to do, it's a very powerful tool; however, I don't know of any in-depth studies of ssh security. -- Mike Gebis gebis(a)ecn.purdue.edu

1 0

[Fwd] Security Threat to Internet shopping (DT)
by Holger.Reif＠PrakInf.TU-Ilmenau.DE 17 Dec '03

17 Dec '03

>Security threat to Internet shopping > >Daily Telegraph (paper edition), 3 October 1995, p. 12 > >[...] >However, users of Microsoft's Windows 95 have found that it ignores the >security passwords on private electronic mail sent or received using >software other than Windows 95. Never heard of this before, but it seems that MS assumes there's no mail like windows'95 mail? If all use it, you have no holes any longer. You or your partners don't use Windows'95? That's your problem not ours! read you later - Holger Reif http://remus.prakinf.tu-ilmenau.de/Reif/

1 0

Random number generators
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

http://www.uni-karlsruhe.de/~RNG/ > Random number generators > > -------------------------------------------------------------------- > Diese Seite gibt es noch nicht in Deutsch. > -------------------------------------------------------------------- > > Classification of random numbers > > Random numbers for use in computer programs can be classified into 3 > different categories: > > * Truely random numbers: > Truely random numbers obviosly cannot be produced by computer > programs, they must be supplied by an external source like > radioactive decay. Such sequences are available (e.g. on > magnetic tape), but clumsy to use and often not sufficient in > terms of speed and number. > * Pseudorandom numbers: > A sequence of numbers is generated by an algorithm in a way > that the resulting numbers look statistically independent and > uniformly distributed. This is the prevailing method used in > random number generators. > * Quasirandom numbers: > These are generated by algorithms tuned to optimize the > sequences uniform distribution, which can improve the accuracy > of Monte-Carlo integration. These numbers are not independent > and thus cannot be used generally. > > Other than uniform distributions can be generated by suitable > transformations of the basic uniformly distributed sequence. > Numerical libraries often offer a rich set of distributions. > > Desirable properties of (pseudo) random numbers > > A good random number generator (RNG) should have the following > properties: > > * Good statistical properties: > There are theoretical and empirical tests to judge a RNGs > quality. Every generator should always be tested with one's > actual application: the standard tests can only disqualify a > RNG and may not check for the properties the application > requires. > * Long period: > RNG algorithms are iteration formulae. The state is often > stored in a single integer, in this case there cannot be more > states than representable integers (recall 2^30 \approx 10^9). > * Reproducibility: > All generators can initialize the sequence by a starting seed. > Storing and reloading a generator's internal state is also > useful. > * Portability: > This concerns both programming language (e.g. Fortran 90 or > ANSI C) as well as machine-dependent (e.g. floating point > representation) aspects. The ideal RNG produces (bit-) > identical results in every environment. > * Efficient implementation: > This may be irrelevant for "general purpose" generators. But > time-critical applications may require inline coding and/or the > generation of whole vectors of random numbers at once. Vector > and parallel computers need special RNG methods. > > Which of these aspects is most important depends on the actual > application, of course. > > Miscellaneous RNG material > > What follows is a collection of material on pseudorandom number > generators. I hope to improve this soon... > > * The RNG Chapter of Designing and Building Parallel Programs by > Ian Foster > * The pLab pages at Salzburg University > * The RNG Document of ORNL's Computational Science Education > Project > * My publications on RNGs are available online, also some slides > * My BiBTeX-bibliographies of articles and books on random number > generation > * The RAND/VP package contains a RNG tuned for our vector > computer SNI S600/20 > * The NAG and IMSL Fortran libraries contain random number > generators for various distributions > * Popular public-domain sources include the StatLib and NetLib > libraries > * My publications on RNGs and the RANEXP library are available by > anonymous ftp also. > URL: ftp://ftp.rz.uni-karlsruhe.de/pub/misc/random/ > * A good source of RNG codes and articles is the journal Computer > Physics Communications, ISSN 0010-4655, published by > North-Holland. > > -------------------------------------------------------------------- > Michael Hennecke / 21.07.1995

1 0

Re: `Hack Microsoft' challenge is NYT Computer News Daily's top story
by MIGUELDIAZ＠megaweb.com 17 Dec '03

17 Dec '03

>MIGUEL DIAZ writes: >> I don't know about everyone else, but a T-shirt seems a > very >> small reward for uncovering a "hole" in the encryption >> algorithm of Microsoft products. > >I don't know about anyone else, but helping to protect the > confidential data >of millions of users around the world seems a very large > reward for >uncovering a hole in the encryption algorithms of M$ > products. > >Clearly, YMMV. > >-Futplex <futplex(a)pseudonym.com> If it means protection only when using a proprietary product owned by Microsoft then no, I still don't see it as much of a reward. If we are talking a system which can be used by everyone at no cost, then yes that would be motivating.

1 0

No Subject
by mg5n+alias!rngaugp＠andrew.cmu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- There is now support for using a hardware random number generator with the most recent versions of PGP. Versions pgp 2.62 unofficial international versions, pgp 2.62 international version and pgp 2.62 (from mit) are supported. The files for this modification of pgp are at the export controled ftp site in the directory: ftp://ftp.csn.net/mpj/I_will_not_export/crypto_????????/pgp/rng the files are: rg262mit.zip rg262i.zip (Can be used in Canada) rg262ui.zip (Can be used in Canada) Sources for the modifications are included. Executables are included for OS/2 and MSDOS. In the above ????????? varies because of the export control scheme. To get the files if you are in the U.S. and Canada first get the file ftp://ftp.csn.net/mpj/README.MPJ and follow the instructions. Many thanks to mpj(a)netcom.com for providing storage at the export controled ftp site. Here is the README file that comes with the modifications. - ---------------------------------------- Hardware Random Number Support for PGP. Version Ever get tired of typing in keyboard timing strokes while generating a PGP key? Ever want to use PGP unattended, but be foiled because there is no one there to type the keyboard timing strokes? Ever wonder if PGP's method of generating random number might have some subtle flaw which would expose it to cryptanalysis? This is a modified version of PGP which allows it to be used with a hardware random number generator. Two kinds of RNG are supported: First, any RNG with a IO driver that makes the RNG look like a file that can be opened (fopen) such that each byte read is a random byte. Second, a bus RNG under the x86 architecture such that random bytes my be obtained with a simple "IN" instruction. The CALNET/NEWBRIDGE RNG is an example of this kind of RNG. A crude sanity check is done to check that the bytes appear to be random. To use the hardware random number generator feature of this software, you must define _ONE_ of the new configuration file parameters RNGDRIVER or RNGPORT in config.txt or from the command line. If you have a RNG of the first type, define RNGDRIVER to be the complete path to the RNG driver. If you have a RNG of the second type, define RNGPORT to be the port number from which to get random numbers. You can use hexadecimal i.e. 0x300. Examples: RNGDRIVER=/dev/random or RNGPORT=0x300 If neither of these are defined the modified PGP will get its RANDOM numbers in exactly the same way that regular PGP does, through keyboard timing. If one of these parameters is set correctly, the modified PGP will get its random numbers from the RNG and you will never be asked to type keyboard timing stokes. I have compiled a version of PGP that supports a hardware RNG for MSDOS and OS/2. I have included the source files for each file that has been modified. To compile get the original source files, put in the modified files and compile as usual. The new source files and this software are covered by the same license as the original, LICENCE. There are similar available modifications for the other two major versions of PGP, OTHERS. If someone out there has an PSI-LINE random number generator that attaches to a RS-232 port as if it were a modem, please test it with this software. If the software line characteristics (baud rate, flow control, stopbits, ect) are set correctly (You will have to do this yourself, as this modified PGP does not do this) then all you should have to do is set RNGDRIVER to the RS232 device name. I have not tested this because I do not have this kind of RNG. Someone may wish to add code to set the software line characteristics, but this may be difficult, as the code would vary by operating system and even among the various flavors of UNIX. If you do such a test please report the results to alt.security.pgp and cypherpunks. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHK/Sc29s2mG+tTVAQE0hwQAoDsgqF6AoIGCNOSOdWZemrGRl4/MVvjR xiwhgROtjFM1FEL4Ak/j8YlR/LSCbOdeF3hZzesaZq8xC25qwlXFEtDX8kqim3zh bOglEMW/x3M9uBQLm0Nyc8FTickaAD3L1Gsa/YMY2slmN3PrZiY0/KSVpPXEMHjK GjeM2U7XJSk= =E5gC -----END PGP SIGNATURE-----

1 0

Re: FORGED CANCELS of posts on n.a.n-a.m
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

[alt.religion.scientology restored, since that's where most of the discussion of forged cancels has been taking place so far ] In article <44pmiq$h7t(a)segfault.monkeys.com>, rfg(a)monkeys.com (Ronald F. Guilmette) writes: >In my opinion, the simple, obvious, and correct solution (which should have >been implemented from day one, IMHO) is to modify the currently prevalent >news processing packages (i.e. INN and Cnews) so that rather than physically >removing canceled news article files from the directories where they exist, >they are instead edited (by INN and/or Cnews) in place, and retained for >future reference. Because of the prevalence of forged cancels, my site just ignores all cancels. Unfortunately, most other sites, including our feeds, honor forged cancels. [Good suggestions skipped] >Bottom line: Article cancelations are known to be based upon highly in- >secure mechanisms. Forged cancels are becoming more common. Many of >these are desirable deletions of spam. Others are problematic instances >of untrustworthy individuals attempting to act as unelected news admini- >strators for the entire Internet. Until such time as more secure article >cancelation mechanisms are put in place (and perhaps even afterwards) >mechanisms which provide for the retention of adequate audit trails >relating to canceled articles should be created and widely adopted. >The current approach/convention/solution/mechanism of physically *deleting* >an article file whenever _anybody_ on the world-wide Internet tells your >news system to do so is simply not acceptable. The cancellation mechanism described in RFC 1036 does not use digital signatures, but is based on the honor system. RFC 1036 says in section 3.1: "Only the author of the message or the local news administrator is allowed to send this message." However no mechanism is provided to authenticate the origin of a cancel. Of late, a small group of control freaks has abused this security hole, claiming (with no basis in reality) that some sort of consensus permits them to act as the self-appointed judges of the contents of other people's Usenet articles, to impersonate other posters, and to distribute forged cancels to other sites to censor the offending articles. E.g., one graduate student at Lehigh University falsely claims to be a sysadmin and regularly forges cancels for articles in n.a.n-a.m critical of his forgeries and other net-abuse; and a crtiminal cult has been forging cancels for articles discussing its dogmas. I'd like to remind everyone of the well-thought-out scheme for authenticating cancels proposed some time ago by Taneli Hujskonen and Benjamin Franz, that can also be integrated into a Lazarus-like system for tracing forged cancels. Let H denote a one-way hash function (also known as message digest), such as Ron Rivest's MD5 or Ralph Merkle's Snerfu. Efficient source code to compute them is readily available and not subject to export restrictions, unlike PGP. Such functions have the property that's it's easy (for a computer) to compute M = H(N), but, for a given M, it's intractable to find N such that M = H(N). Let the poster specify a secret passphrase whenever s/he posts an article. This passphrase will be required to cancel the article. However it will not be revealed by a cancel and can be reused. With user-friendly software, the poster might store the passphrase in a profile and use the same passphrase for all articles, or change it for every message. When an article is posted, two quantities are computed by the posting program: M1 = H(article body + newsgroups + message-id + date + passphrase) and M2 = H(M1). The posted article contains the header "Cancel-lock: M2". When an attempt is made to cancel/supersede an article X with a "Cancel-lock:" header, the user is asked to supply the passphrase. The posting software computes M1 = H(X's body + newsgroups + X's message-id + date + passphrase) once again and adds the "Cancel-key: M1" header to the article containing "Control: cancel <X>" or "Supersedes: <X>" that's being posted. (Note that without knowing the passphrase it's intractable to match the M1.) Whenever news server software (such as inn) detects either "Control: cancel <X>" or "Supersedes: <X>", INN should retrieve the original article <X> and looks for the "Cancel-lock: M2" header. If one is found, then the old article may be cancelled only if the new article contains the header "Cancel-key: M1" such that H(M1) = M2. If the cancel cannot be authenticated (e.g., because the original article lacks the "Cancel-lock: M2" header, or the cancel lacks the "Cancel-key: M1" header such that H(M1)=M2), then INN should forward the unauthenticated cancel to one or more "collection centers" so the author of the original article may be notified. A site may choose to honor the unauthenticated cancel anyway if the article being cancelled lacks the "Cancel-lock: M2" header, but should ignore it if "Cancel-lock:" is found, but no matching "Cancel-key:" is given. Each "collection center" deamon should wake up periodically (say, every hour), group the collected unauthenticated cancels by message-ids of the cancelled articles, and e-mail the (distinct) addresses (other than "usenet@*" or "news@*") mentioned in the "From:", "Sender:", "Authorized:", and "X-Cancelled-By:" headers, quoting the unauthenticated cancel and the Path's as seen at many different sites that forwarded the cancels. This way, if the unauthenticated cancel is indeed forged, its author will see within hours that it has been fraudulently cancelled _and_ will automatically receive enough "Path:" samples from all over the world to see where it was posted, by comparing the "Path:" headers in several forwarded copies. A user or an entire site can easily "opt out" of havings "bona fide" cancels reported by always using the proposed "Cancel-lock:/Cancel-Key:" headers. This scheme would be upwardly compatible with all existing Usenet software. It would also be compatible with the "NoCeM" proposal, where trusted censors could issue digitally signed "advisory cancels" without impersonating the original posters. Such advisory cancels would not be subject to hash checks. --- Dr. Dimitri Vulis Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

1 0

Digest [full] version available
by Alan B. Clegg 17 Dec '03

17 Dec '03

I have setup an un-moderated digest of the Cypherpunks mailing list and it is now available for everyone.. My main goal on Cypherpunks is to lurk and the digest version lets me do that without being forced to read each one as it comes in.. [or filter the posts into a mailbox that I have a bad tendancy to leave for long periods of time...] Digests will be created every 40K bytes. subscribe by sending e-mail to majordomo(a)gateway.com with a BODY line: subscribe cypherpunks-d Enjoy.. -abc It's time to stand and cry | Alan B Clegg That Freedom will not live | President Beyond our willingness to die | Gateway Communications -Lester Bork | http://www.gateway.com

1 0

Re: New Netscape bug (in version 1.12)
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DFv6uo.4so(a)sgi.sgi.com>, Ray Cromwell <rjc(a)clark.net> writes: > C'punks, > I just got back from a vacation in Raleigh, and downloaded the > new "fixed" Netscape 1.12. It took me about an hour, but I've > discovered another bug and potential security hole. This one relates > to mailto:. > The bug is as follows. Create a HTML file with a hyperlink containing > the following URL > foo > This bug doesn't seem to crash Netscape, instead, it crashes my XServer > as soon as the mail window pops op. I'm too tired right now to try to > analyze it, but it might be another stack bug, this time, in the X > libraries because Netscape isn't doing any sanity checking. This is a bug in your X server, not in netscape. The X server should never crash no matter what you send to it. > I need help testing this bug on other platforms. I have created > a test page. Go to http://www.gl.umbc.edu/~rcromw1/crash.html > to test. This doesn't crash my X server (SGI Irix 6.2), so it's probably specific to XAccel. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

6 7

Re: David Chaum testimony
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <9509048128.AA812845568(a)smtpgwys.senate.gov>, Jerry_Ellig(a)jec.senate.gov wrote: > I'm a professor from George Mason University on leave to do some work > with the Joint Economic Committee on the economy of the 21st century. > I found your e-mail address attached to some congressional testimony > by David Chaum. Does anyone know when he testified, and before what > committee? Being new on Capitol Hill, I haven't yet found the easy > way to find this out from inside the government! The full text of the testimony is available at http://www.digicash.com/publish/testimony.html - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMHL4SSoZzwIn1bdtAQEjdAGAhUoSwRu803hFI8ARmqsmbASy1CNNK7Cj rl5Tw5mMVGoZcPwhsyO5Af02z6lhIfyw =L1hB -----END PGP SIGNATURE-----

1 0

Mailing list
by accw5＠glen-net.ca 17 Dec '03

17 Dec '03

I wish to join the mailing list accw5(a)glen-net.ca

1 0