December 2003 - cypherpunks-legacy

Satellite Gone (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Hi all, I just got this a few minutes ago and thought it migh be interesting. For obvious reasons I am not going to identify the source. Forwarded message: > Date: Sat, 11 Jan 1997 11:46:51 +0000 > To: Ravage(a)einstein.ssz.com > Subject: Satellite Gone > > dunoo if this might interest you > Last night at apx 10:00 satellite T1 (Telstar 401) went away... > > Fox and ABC News one channel are now over on T2 (Telstar 402) located at > 89 degrees west... > Fox is on transponders 1,2,7,10,13,17,20,23 > ABC has feeds on 8,21,22 > > I haven't yet found where the UPN feeds are going to be.... > > ATT Satellite Enginering support has said that it is gone with no hope > of recovery... > > Some ugly roumors are starting to float about alleged threats to FOX to > do this by unnamed Gov agencys due to the negetive views that FOX had > been reporting to the public about them.... > > Have you heard anything?? Jim Choate CyberTects ravage(a)ssz.com

2 1

Re: What!
by Murple 17 Dec '03

17 Dec '03

> Excuse me? > > What is faulty about IMDMP? > > - Jeremy > The only people who can answer that question are you and the good people at DataET Research, the reason being that you are the only people who know what IMDMP is. A more appropriate question would be 'What is faulty about UDCM?' The problem is that to us, UDCM is like a 'black box' - we put data in, and data comes out, but we have no understanding of what goes on to produce the data which comes out. IMDMP could well be more secure than all the cryptographic algorithms in use today, but it could just as easily have huge security holes which we may never know about, or at least not until it is too late. The difference between this and public algorithms such as IDEA, is that we can obtain source code, descriptions, comments, and often detailed analyses of these algorithms, and we can decide for ourselves whether we want to entrust our privacy to them. With UDCM, and hence IMDMP, this is simply not possible, and this is where I believe you have gone wrong. Brian Herlihy

1 0

RE: encryption program
by Mullen Patrick 17 Dec '03

17 Dec '03

I'm looking for ciphertext analysis tools -- What analysis tools did you use? Where can I get a publicly available copy? Thanks! PM

3 4

New Win95 PGP Program
by CVHD 17 Dec '03

17 Dec '03

Has anyone taken a look at the "Lock and Key" program for Win95/PGP? It can be found at : http://www.voicenet.com/~wheindl/lock&key.htm I was wondering if there were any inherent problems using a program like this inside Win95 what with the swap-virtual memory files. TIA for any comments Regards from the, Computer Virus Help Desk http://www.indyweb.net/~cvhd

1 0

Re: Private Idaho source code now available
by jim bell 17 Dec '03

17 Dec '03

At 11:35 PM 1/11/97 -0500, Anonymous wrote: >Joel McNamara says: >> Private Idaho 2.8b3, a bug fix version of the popular Windows freeware PGP >> and remailer utility, is now available. This will be my last official >> release of PI for the foreseeable future. >> >> Due to other projects and new directions, I haven't been able to spend as >> much time as I'd like coding and supporting Private Idaho. Instead of >> seeing it die on the vine, I've decided to release the source code under >> the GNU General Public License (export disclaimer - the sources do not >> include, or have ever contained, cryptographic algorithms). > > My understanding is that Private Idaho uses PGP internally >and provides the same functionality as premail, with an >easier to use GUI. > > Given that, it would still be export controlled, since it >enables cryptography. That is why Raph doesn't allow export of premail. The "enables cryptography" thing just doesn't cut it. A computer "enables cryptography" to a person without a computer. The MSDOS operating system "enables cryptography" to a person with a computer but without an OS. A hard disk with a filesystem "enables cryptography" by providing an intermediate data storage location (and format) for encrypted and unencrypted data, as well as the encryption program. Even a modem program or mail program "enables cryptography", or at least enables the transmission of encrypted data, etc. Apparently, the phrase "enable cryptography" is either just about meaningless, or is so broad as to be not usable to determine which items are exportable and which aren't. How about narrowing it down a bit? Jim Bell jimbell(a)pacifier.com

2 1

Re: Free money, 3
by winsock＠rigel.cyberpass.net 17 Dec '03

17 Dec '03

Dear Mr. Anonymous, Thank you very much for the free money. You are a gentleman and a scholar. Yours Truly, The Shadow

1 0

Re: IMDMP 8192 PKCS and IMDMP Summary
by proff＠suburbia.net 17 Dec '03

17 Dec '03

Ok. I admit it. It is beneath me, but how could I resist such temptation? > Hi, > [..] > cryptosystem method. The future versions will also support multi-party key > integration features, four platform independent random number generator ^^^^^^^^^^^^^^^^^^^^^^^^^(1) > algorithms, as well as 1024 (8192 bit) keys. Note that the current version of ^^^^^^^^^^^^^^^(2) > IMDMP only allows 256 byte (1024) bit keys. The current shareware version and ^^^^^^^^^^^^^^^^^^^(3) > the future shareware version of UDCM will still only allow 5 byte (40 bit) ^^^^^^^^^^^^^^(4) > keys so as to comply with ITAR unless a key recovery infrastructure is ^^^^^^^^^^^^^^^(5) [..] > partially detailed summary of the IMDMP is now included in VENDOR.DOC file of > the UDCM V2.0 software package / archive. UDCM V2.0 was modified to restrict > keys to 50 bits so as to comply with the latest ITAR details. The extensively ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(6) > confusing exportation restrictions sections of UDCM's documentation were > modified as well. > > methods are not too comparable to PKCS methods. What I was referring to when > I said IMDMP is more advanced than RSA, etc. is the actual encryption ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(7) > procedure itself, not the way keys are secured. Again, irrashional claims ^^^^^^^^^^^(8) [..] > AND-ing algorithm without trying it first. I find it extremely hard to > believe that the celebrated creator(s) of Blowfish, IDEA, etc. had to go > through all of this ritualistic screening complexity too. (Please do correct > me if I am wrong.) ^^^^^^^^^^^^^^^^^^^^(9) > > (For the record: DataET Research's promotional agent has been fired.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(10) > Thank you very much for your time. > > Jeremy K. Yu-Ramos > President > DataET Research > Data Engineering Technologies > Eww. (1) Not possible, you need real-world entropy. Sadly, there is yet there is no platform independent way to efficiently collect it. (2) For symmetric ciphers, keylengths over 128 bits do not gain you anything - unless the cipher is poorly written and does not use all of its keyspace or leaks bits of the keyspace into the ciphertext. 2^128 is such an immense number that short of a fundamental change in complexity theory, exhaustive keysearching a 2^128 keyspace will never be a possible attack scenario, regardless of increases in computation speed. (3) "256 byte (1024) bit keys". Hmm. 256 x 8 = 2048 (4) "5 byte (40 bit) keys". 5 x 8 = 40 and (5) Says (4) is to comply with ITAR. But... (6) "50 bits so as to comply with the latest ITAR details." (7) Find the oxymoron. (8) You're wrong. (9) That "irrashional" spelling, at it again. (10) Then why is he still writing? -J

1 0

apology
by Barry Shultz 17 Dec '03

17 Dec '03

You have received a message from this mailbox in error. I am sorry for the error, you are NOT ON A MAILING LIST. The message you received was intended for a specific mailing list which you were not on. We all have to learn new software and mistakes sometimes are made. Again, we are sorry you were subjected to our learning curves. Barry Shultz

1 0

IMDMP 8192 PKCS and IMDMP Summary
by DataETRsch＠aol.com 17 Dec '03

17 Dec '03

Hi, You have probably read a few of my past messages about UDCM and IMDMP. The variation of IMDMP implemented within UDCM V2.0 and UDCM V3.0 does not include a public key cryptosystem. However, on March 1st, 1997, new versions of UDCM and IMDMP will be released that do support the public key cryptosystem method. The future versions will also support multi-party key integration features, four platform independent random number generator algorithms, as well as 1024 (8192 bit) keys. Note that the current version of IMDMP only allows 256 byte (1024) bit keys. The current shareware version and the future shareware version of UDCM will still only allow 5 byte (40 bit) keys so as to comply with ITAR unless a key recovery infrastructure is established. A public key directory infrastructure is being considered for development as well. Also note that versions of UDCM are being planned for the UNIX, DOS, and Macintosh System platforms. There are a few major mistakes in a couple of my previous delegated messages. An end-user application that supports IMDMP will not be released until March 1st, 1997. A detailed description of IMDMP will not be released as planned, but, instead, the undocumented primary source code of UDCM (containing the IMDMP encryption algorithm) will be released on February 1st, 1997. A partially detailed summary of the IMDMP is now included in VENDOR.DOC file of the UDCM V2.0 software package / archive. UDCM V2.0 was modified to restrict keys to 50 bits so as to comply with the latest ITAR details. The extensively confusing exportation restrictions sections of UDCM's documentation were modified as well. I am extremely sorry about the apparently extraneous information that is present in a few of my first messages to this mailing list. Such a negative level feedback was not anticipated. I do admit that single key encryption methods are not too comparable to PKCS methods. What I was referring to when I said IMDMP is more advanced than RSA, etc. is the actual encryption procedure itself, not the way keys are secured. Again, irrashional claims were not intended at all. The amount of analytical research invested in IMDMP was thought to be sufficient. By the way, has anyone out there even tried using UDCM to encrypt a file or two? I do not know how some of you can say that IMDMP is a simple XOR-ing and AND-ing algorithm without trying it first. I find it extremely hard to believe that the celebrated creator(s) of Blowfish, IDEA, etc. had to go through all of this ritualistic screening complexity too. (Please do correct me if I am wrong.) (For the record: DataET Research's promotional agent has been fired.) Again, the web site address of UDCM is: http://members.aol.com/dataetrsch/udcm.html. The web site includes has a link to the VENDOR.DOC file which includes the aforesaid updated information. UDCMV20.ZIP is currently unavailable on the web site as the software is undergoing additional security modifications. By the way, the web page's ugly background his been removed. The IMDMP encryption algorithm itself combines various simple and complex methods to secure digital data: standard randomized and fixed substitution, standard randomized and fixed AND and XOR logic, integrated and interlaced randomized XOR logic, NOT logic, randomized and fixed bit shifting, randomized transposition scrambling, linear sequential bit incrementation and decrementation, integrated and interlaced randomized and fixed byte dependency structuring, sequential byte pyramid structuring, asymmetric non-linear chaos and complexity based binary selection equation key integration, anomalous key bit factoring, and continuous key bit modification structuring. Sub-algorithms of IMDMP are basically additional applications of one or more of the aforesaid techniques. Questions, queries, or comments ("gulp")? E-Mail: DataETRsch(a)aol.com, JKYuRamos(a)aol.com, or DataETResearch(a)geocities.com. Note: From now on, any messages to DataET Research that do not contain the text "NO FLAME" somewhere in the subject heading will be ignored completely. If a message is a indeed flame, the associated server's administrator will be contacted, and a complaint will be filed accordingly. Thank you very much for your time. Jeremy K. Yu-Ramos President DataET Research Data Engineering Technologies

4 5

Private Idaho source code now available
by Joel McNamara 17 Dec '03

17 Dec '03

Private Idaho 2.8b3, a bug fix version of the popular Windows freeware PGP and remailer utility, is now available. This will be my last official release of PI for the foreseeable future. Due to other projects and new directions, I haven't been able to spend as much time as I'd like coding and supporting Private Idaho. Instead of seeing it die on the vine, I've decided to release the source code under the GNU General Public License (export disclaimer - the sources do not include, or have ever contained, cryptographic algorithms). I'm hoping one or more, like-minded, privacy-oriented developer(s) will step forward to continue with PI's evolution. There's a lot of functionality in the application right now, but there are still some enhancements to be made (localized and 32-bit versions, some more minor bug fixs, etc.). I'll still be maintaining the Private Idaho Web page, and if new versions do appear, they'll be distributed there. See http://www.eskimo.com/~joelm/pi.html for complete details on getting the sources. Thanks for all the support and feedback you've provided over the past several years. Joel

3 2