December 2003 - cypherpunks-legacy

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

Re: Where'd pgptools go?
by markh＠wimsey.bc.ca 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 on wimsey.bc.ca: /pub/crypto/software/dist/US_or_Canada_only_XXXXXXXX/RSA/PGP/PGPTOOLS: total 328 -rw------- 1 markh user 0 Feb 23 11:11 DO_NOT_EXPORT -r--r--r-- 1 markh user 21076 Feb 23 11:10 mgmny10e.zip -r--r--r-- 1 markh user 143871 Feb 23 11:10 pgptl10c.zip cd into /pub/crypto/software and read the README file for the current value of XXXXXXXX -- Mark Henderson markh(a)wimsey.bc.ca (personal account) RIPEM MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 ViaCrypt PGP Key Fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 cryptography archive maintainer -- anon ftp -- wimsey.bc.ca:/pub/crypto

1 0

Re: Where'd pgptools go?
by mpjohnso＠nyx10.cs.du.edu 17 Dec '03

17 Dec '03

Hal <hfinney(a)shell.portal.com> writes: >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 - OOPS -- I must have prematurely deleted something. I still have it on the Colorado Catacombs BBS (303-938-9654), and I'll put it back up on csn.org within a day or so. I thought I merged the new with the old to create the latest .zip file.... ___________________________________________________________ |\ /| | | | | \/ |o| | Michael Paul Johnson Colorado Catacombs BBS 303-938-9654 | | | | / _ | mpj(a)csn.org ftp csn.org \mpj\README.MPJ for access info.| | |||/ /_\ | aka mpjohnso(a)nyx.cs.du.edu mikej(a)exabyte.com | | |||\ ( | m.p.johnson(a)ieee.org CIS 71331,2332 VPGP key by finger | | ||| \ \_/ |___________________________________________________________|

1 0

Truly Stealthy PGP (algorithm)
by Hal 17 Dec '03

17 Dec '03

(I'm having a bit of trouble with my mail UA; all of my saved messages on this thread keep disappearing, so I apologize for a slight lack of continuity here. I'm having to work solely from memory of the earlier discussion.) If I understand Eric's general idea, we would keep trying session keys under a set of rules which would lead to the desired statistical distribution of the encrypted key. Here is an algorithm which would work. (I hope I am remembering the notation Eric used correctly.) Let L be the next power of 256 above the modulus n. Let t be the integer part of L/n, so that L = n*t + s with s in [0,n). Call the PGP IDEA session key SK, and the encrypted version of that m = SK^e. Now do these steps: 1) Pick a random SK in [0,n). 2) RSA-encrypt it to form m = SK^e mod n. 3) Choose a random k in [0,t]. 4) Calculate the "stegged" encrypted key as M = m + k*n. This will be uniform in [0,(t+1)*n) if m is uniform in [0,n), which I think it is. 5) if M is not in [0,L) (i.e. if M >= L) then go back to step 1. 6) Otherwise store M as a raw binary number taking log base 256 of L bytes. The idea is that once we get M uniform in [0,(t+1)*n) we can make it uniform in [0,L) simply by rejecting those candidates which were too high. This will only happen if k=t and m>=s. Now, it seems to me that the worst case for rejection is when n=L-1, in which case t=1, s=1, and almost one-half of all initial SK choices will be rejected. Following Eric's reasoning, this would be an effective loss of one bit of key length, from say 1024 to 1023, which is tolerable. (Eric actually suggested that as many as two bits could be lost, but I don't see that happening with this algorithm. It doesn't really matter anyway because both 1 and 2 are so small.) Using this algorithm with the current Stealth PGP would produce a "truly stealthy" version which I think would be indistinguishable from random bytes without access to the receiver's private key. Hal

2 1

Re: Format of PGP ciphered message
by norm＠netcom.com 17 Dec '03

17 Dec '03

Thanks!

1 0

Format of PGP ciphered message
by norm＠netcom.com 17 Dec '03

17 Dec '03

Is there any specification of the format of a PGP enciphered message short of the program itself?

3 2