December 2003 - cypherpunks-legacy

PGP (surprise, surprise..)
by jmueller＠gac.edu 17 Dec '03

17 Dec '03

Greetings, Could anyone tell me, is it true that PGP 2.3 was watered down to appease the RSA folks? If so, would it be a better idea to use 2.2? Thanks. -- Joel Mueller - <Insert your favorite witty quote here; I'm tired.> GAT/O -d+(---) -p+ c++@ l+ u++ e m+ s+/- n- h-- f+@ g+(-) w+ t(--) ry? PGP 2.3a Public Key : finger jmueller(a)gac.edu or on keyservers. 0C6D75 01 0E 16 A7 29 C4 48 75 54 CD 99 09 88 88 3C 39

1 0

Mondex card
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

I don't know if you all have heard of the Mondex card that is going to be impl -emented in England. Does anyone have any info/articles on it (the New York Times had a small piece in the Sunday Magazine)? Will foreigners be given Mondex cards when they enter the country? Reuben Halper PGP key available on request

1 0

Re: PGP (surprise, surprise..)
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Joel Mueller asks: > Could anyone tell me, is it true that PGP 2.3 was watered down to > appease the RSA folks? If so, would it be a better idea to use 2.2? > Thanks. No, of course it wasn't. There was some hoax article on the network purporting that PGP was rigged, which didn't even have Phil's name right. First of all, you can look at the code yourself, and see the differences between 2.2 and 2.3 and successors - the discussion on the net centered around bug fixes and getting things to work consistently across platforms. Second (or zeroth), RSA has been annoyed at Phil for a while :-) Among other things that have been done to deal with this, Phil is no longer developing mainstream freeware PGP, though he has worked on licensed commercial versions like ViaCrypt. The PGP official development is going on outside the US, where it's not covered by the PKP/RSA patents and where there isn't a problem exporting the code (US ITAR doesn't forbid importing crypto software.) So don't worry. If you're concerned about not violating RSA's patent, buy the VIaCrypt port for $100 (plus shipping and sales tax.) Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

1 0

Re: Update on user-level hack to do telnet encryption posted recently
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

> Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with > the BSDI distribution (original code in the US, a re-implementation on > supplementary floppies in the UK) Not the same program at all. Why don't you actually read some of the RFCs instead of making yourself look foolish? Well if you have nothing useful to contribute but won't shut up anyway, I will. This conversation is over. > Not *one* of the dozen odd sites I telnet to is running it. Have you asked them to run it? Have you considered simply running the daemon yourself on another port instead of implementing some crude hack? I already do this. Goodbye. :: ^From.*metzger |/dev/null G

3 2

Re: PGP (surprise, surprise..)
by dmandl＠panix.com 17 Dec '03

17 Dec '03

jmueller(a)gac.edu says: >Greetings, > > Could anyone tell me, is it true that PGP 2.3 was watered down to >appease the RSA folks? If so, would it be a better idea to use 2.2? Thanks. Completely untrue. I can assure you that RSA was no more appeased by 2.3 than by 2.2, though there is now of course a truly legal version in ViaCrypt PGP. Source code for the guerilla-ware versions is as always available for your inspection, and you're free to compile it yourself. You should use the latest one, period (I believe it's currently 2.3a for MS-DOS and UNIX; MacPGP is 2.3). --Dave. -- Dave Mandl dmandl(a)panix.com

1 0

Re: some technical steganography
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

> >> I assert that an "unrecognizable encrypted message" will be a >> random sequence of bits. Is my assertion correct? > > It's neither correct or incorrect because the specific > notion of randomness hasn't been specified. > I don't understand what you mean by "specific notion of randomness hasn't been specified". How many different "notions of randomness" are there? > Your statement is falsifiable, however, since > sometimes a non-random string of bits is what you want to > get out, if what you would expect to get out normally was > also non-random. And you want them to be non-random in the > same way. > I agree. The output of the reverse stego process should produce similar results, regardless of the presence of a hidden message. That's the point I've been trying to make. I've been attempting to make that point by describing a hypothetical stego system that, when run in reverse, produces a random sequence of bits. I suppose there could be other hypothetical stego systems that produce non-random output, but then you would need a decryption system that could understand and decrypted that non-random output. I prefer random bit sequences. Or perhaps I should say - bit sequences with no apparent structure. > > Of course, this assumes there is no other way to detect a > > hidden message besides reversing the stego process and > > testing the result. > > > > Don't count on it. Statistical tests can find > correlations you hadn't suspected were there. In fact, > for some message types, _not_ finding the correlations > may indicate dithering, or maybe a steganographic > message. > I agree completely. This is a large part of what makes effective steganography so difficult to achieve. Jim_Miller(a)suite.com

2 1

Re: New mailing list?
by mcb＠net.bio.net 17 Dec '03

17 Dec '03

I was thinking about Alan's proposal for a moderated real-world-crypto list (which sounds good, by the way!), and it brought up my main problem with cypherpunks, which is sheer volume, volume, volume! It's not a "noise" problem -- since the end of the LD foolishness the greatest part of what has been posted here has been intelligent, thoughtful stuff. But since c'punks has grown to the size of a newsgroup in volume, simply getting through it is *difficult*. My proposal is pretty simple: splitting the list into cypherpunks-tech and cypherpunks-policy. (Cypherpunks-announce would be left alone of course.) I think a large number of readers would want to be on both lists, but a large number (like myself) would *not*, and if nothing else, it would cut down the mailer load on toad. In short, technical crypto articles, reviews of papers, steganography stuff, PGP-specific stuff, all source code, etc., would go to the cypherpunks-tech list; while policy articles, Clipper stuff, political discussions, anarcholibertarian/extropian material, social implications of digital cash, etc., would go to the cypherpunks-policy list. I *know* there are people out there who would rather that the political stuff not get in the way of their technical discussions, and then there are people like me who are more focused on the policy issues (and regardless of technical background, are never going to be code-level crypto hacks). Comments? -- Michael C. Berch mcb(a)net.bio.net / mcb(a)postmodern.com

3 2

Meeting in Seattle?
by Ophir Ronen 17 Dec '03

17 Dec '03

Morning(or whatever fits your time zone) all, Is anyone in Seattle setting up a link for the meeting? If so, please let me know. Thanks, -Xeryus

3 2

Where'd pgptools go?
by Hal 17 Dec '03

17 Dec '03

I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version 1.0d. However, 1.0d is not the whole PGP Tools program. It is just an addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still needed to give you the whole of PGP Tools. Does anyone know of an FTP site which still has pgptl10c available? Thanks - Hal

1 0

Screen and secure sessions
by rcain＠netcom.com 17 Dec '03

17 Dec '03

What follows is part of a dialog I am having with netcom support right now about the use of the Screen hyper-shell. I've been using it between home and work and it is awesome if you have never seen it. The man pages for it in ascii are ~rcain/pub/screen.man if you are on netcom and want to check out what it can do. There is someplace here I could put it for anon ftp if somebody could tell me the name of that drirectory from a netcom shell. The dialog starts as a discussion of the problem I have with the two or three minute inactivity timeout on the San Jose modems and is mostly about the low impact I see it having on resource usage. If you know all about Screen or aren't really interested in a bunch of justification, go forward about 100 lines to get to the part that discusses crypto. Peace, Bob > Netcom Support sez: > > > > Robert Cain writes: > > > > > > [some stuff deleted] > > > > > > First the short duration of your modem timeout pushes the envelope of > > > the ridiculous. I'm not sure what it is but when a brief conversation > > > or call of nature causes it to disappear *IT IS TOO DAMNED SHORT*. > > > > I'm sorry you have a problem with our policy, but we have no > > intent to change it in the future. We'll take your suggestions > > under consideration, but as I said we have no plans to modify > > it at this time. > > You certainly sound intransigent. What would the implications of > doubling it be for example? You could at least try it for a while > and see if it has the effect of increasing the load on modem banks > signifigantly. What is the currently programmed inactivity interval > anyway? I lost it again in the middle of this damned note because > I got a phone call. Damn I hate it when that happens. At lest > this time there was a "vi -r" message in my mailbox after logging > on. > > > > > > > I have a solution to this that I am using on our sun network at > > > work. It is a package called "screen" that has wonderful features > > > like multiple windows (all stacked one atop the other) that are > > > easy to create and switch between if you want several contexts > > > available at once. The most exciting feature is that if I wish > > > to or if my line goes down, I can reconnect to it at the next > > > login and pick up as if nothing had happened. This would be a > > > wonderful feature at netcom too. I know that your no nohup > > > hacks prevent us from having processes that persist when we log > > > off (OR ARE FORCED OFF) but if you changed that specifically > > > for the screen processes and it's descendants to instead reduce > > > them to the lowest possible priority until a reconnect then all > > > this hassle would go away and netcom could offer a very neat > > > feature. IBM mainframes have had disconnect/reconnect forever and > > > I've never understood the lack of it on Unix. Here it is! It > > > is a very friendly and powerful capability. Users would love it > > > and the cost to netcom would be entries in process tables and > > > swap space for the processes. You seem to have more than enough > > > of those kinds of resources now. Please consider it. > > > > The use of "Screen" is not supported on Netcom because of its drain on > > system resources. It violates our policy against running detached > > backround processes. This is also a policy we have no plans to modify > > at this time. > > Hmmm, I'm not sure you read me. What I am suggesting would not > violate the intent of your policy WRT detached background processes. > Let me try and persuade you. > > If whatever you use to kill processes upon detachment, logout or forced > by timeout, could instead merely lower their priority to the minimum > then, as I said, they would not load the system's cycle capacity, > merely occupy some process specific tables and some swap space. I am > pretty sure that in one of the netcom newsgroups (to which I am posting > a copy of this) we hassled this out and it was determined what the cost > in real memory was for a process's tables that was totally swapped > out. It was truly insignifigant in proportion to the size of real > memory that is on the systems. There is little drain on system > resources if you do this unless the number of processes becomes > absurdly high. > > Yes, there is a cost for swap space. Is it possible to set up your > unix to use more than one swap area? If so then it could be arranged > that a user's pages were swapped into storage he is paying for > (possibly after he/she had exceeded some limit in the system swap > area) and then this would become a revenue generator for netcom rather > than a drain on resources. If that is not a thing you know how to do > then you could simply establish a daemon that checks the number of > processes (or the total size) and warns the user when he is in > violation of the limit. That limit should be based on a determination > of the real cost in process tables and swap space rather than just set > arbitrarily. I don't see how my request does much more than offer > serial line users <!!the same advantage that lucky telnet or rlogin users > enjoy!!>. They can and do stay logged in indefinitely and in effect have > various processes running all the time without concern about an > inactivity timeout. > > Arguing against having a bunch of virtual windows makes no sense > because you can effect that if you know emacs reasonably well anyway. > Screen is just an easier way that doesn't require one to learn emacs. > As a hypershell, Screen has *many* powerful features for power users. > For fairly naive users only a fairly few keystrokes need be > remembered to use it's most useful features. In combination with > the menu program you offer it would be very powerful across a slow > line. > > One of Screen's features is a rather elaborate filtering mechanism whereby > all incoming keystrokes and outgoing screen data can be filtered by > user programs. I would like to use this to add encryption for my phone > line. It would be straightforward to encrypt my outgoing and incoming > data here at my PC that is acting as a terminal since I think my terminal > emulator has similar filter hooks so the same programs that I used on > the netcom end or my work end would function on this end as well if I > explicitly wrote them to be that way. Given that, I would make Screen > effectively my login shell, have it negotiate (via the filters) a > secure link with my terminal emulator here at home and then go through > another password process before invoking my startup shell. Viola I no > longer have to worry about someone grabbing my real password nor can I > be snooped or spoofed between my system and a system at netcom. This > has *HUGE* advantages to users and I will use a cypher (IDEA) in a mode > that is *very* fast so that the system load that would be introduced > by the crypdec filters would not be all that great. I have all the > necessasary C libraries of long integer math routines and hard crypto > functions as well as the theoretical knowledge of crypto needed to code > what's left to write such a filter. > > Hell, Screen's capability would *greatly* enhance Netcom's account > attractiveness and good crypto could be used as a big selling point in > attracting commercial accounts where you make substantial profit per > account. In fact when I get this to work I wouldn't be surprised if > users demand it. :-) > > I have the man pages for Screen in my ~rcain/pub directory if anybody > at netcom wants to check out Screen's capabilities. I could also > make them temorarily available for incoming anon ftp if requested. > Now, while all this is true in theory, in all honesty I am too deeply involved in other things (like a day job) to actually do the implementation I speak of but I *do* have all the tools if anybody else wants to take a shot at writing the filters. Since screen runs across rlogin just fine, if this were done I could rlogin to any other machine on the net and have a secure session across the net. I think it could also be made to be secure across "talk" or "irc" sessions and even email between machines. It could also be used as the front end to any text based telnet port too. So if you want to be able to dial in securely at least and communicate with a system that is secure, and across systems that are secure badly enough to put the time into it (or pay me enough to quit my day job :-), here is a chance to maybe make some history. I think this is the right way to get a start on global network security. Screen offers such a rich environment for single windowed connections already that it is a natural starting point given that it's author has thought ahead to the kinds of filters we need. It also could care less what shell you run and it is transparent to the applications running below it (from the experience I have had to date) It is a work of art to begin with IMHO and with this crypdec capability there would hardly be a reason not to use it since if you don't know it and don't want to learn, you won't know Screen is there until you invoke it's commands with the ctrl-A key (which can be changed to anything else as an escape if you use applications that are fond of ctrl-A.) Peace and hoping, Bob -- Bob Cain rcain(a)netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ --

1 0