- cypherpunks-legacy - lists.cpunks.org

Funny bounce
by meyer 26 May '93

26 May '93

My previous message to cypherpunks, the one which had subject heading "AT&T" and which began: "I recently switched my long distance carrier from AT&T to another, since they bribed me to do so with an offer of $35." seemed to be posted OK (it apparently came back to me as expected) but I also got this funny bounce message: >From attmail.com!uucp(a)cactus.org Tue May 25 23:37:59 1993 >Received: by wixer (5.65/1.35) > id AA10857; Wed, 26 May 93 00:16:57 -0500 >From: attmail.com!uucp(a)cactus.org >Received: from att.att.com by cactus.org (4.1/SMI-4.1) > id AA17609; Tue, 25 May 93 23:37:59 CDT >Message-Id: <9305260437.AA17609(a)cactus.org> >Date: 25 May 93 20:30:47 GMT >To: wixer!wixer.bga.com!meyer(a)cactus.org >Report-Version: 2 >Received: by /C=US/AD=ATTMAIL;Wed May 26 04:28:34 -0000 1993 >Received: by /C=US/AD=ATTMAIL/PD=DCA;Tue May 25 20:30:47 GMT 1993 >Confirming-Mts-Message-Id: </C=US/AD=ATTMAIL;internet1460427530> >Confirming-Ua-Content-Id: <ternet1460427530> >Original-Date: Wed May 26 04:27:53 GMT 1993 >Not-Delivered-To: mhs!dca/G=bryan/S=petty/OU=dcaicc due to 01 Invalid Address Specification >Content-Type: message >Status: RO > >Message-Version: 2 >From: internet!cactus.org!wixer!wixer.bga.com!meyer/S=meyer >UA-Content-ID: <internet1460427530> >End-of-Header: >EMail-Version: 2 >Subject: AT&T >UA-Message-ID: <internet1460427530> >To: internet!cactus.org!wixer!wixer.bga.com!internet!toad.com!cypherpunks >End-of-Protocol: >Content-Type: text >Content-Length: 755 > >I recently switched my long distance carrier from AT&T to another, >since they bribed me to do so with an offer of $35. > >[Rest of message deleted - PM.] This seems odd. What's going on? Do all messages with "AT&T" in the subject line get siphoned off somewhere for review? Did this one generate a bounce message because the account of Bryan Petty, AT&T spy, wasn't receiving tonight? OK, I'm just paranoid. (Paranoia - that's your state of mind when you finally realize what's really going on.)

1 0

Re: PGP: Environment protection for UNIX
by stig＠netcom.com 26 May '93

26 May '93

On May 26, 1:07am, J. Michael Diehl wrote: > Well, I like this one. It lets you put little messages in place of argv[0]. > > #include <stdio.h> > > char buff[100]; > int esc = 27; > > void main(int argc, char *argv[]) > { > puts("Enter message.\n"); > scanf("%s", buff); > execl("/nfs/dorado/unsup/bin/ftp", buff, NULL); > } > Yeah, I like that too... 'cept if you need to pass args, it doesn't provide a covert channel. I confess to not having read my PGP manuals yet, but is there an interactive mode to PGP? If there WERE (hint), then it could be run as a subprocess of emacs or a mail program and thus be a) more convenient and b) the whole hub-bub about people snooping your environment would be a non-issue. Stig /* Jonathan Stigelman, Stig(a)netcom.com, PGP public key on request */ /* fingerprint = 32 DF B9 19 AE 28 D1 7A A3 9D 0B 1A 33 13 4D 7F */

1 0

Re: VinCrypt
by Z3KPW＠ttacs1.ttu.edu 26 May '93

26 May '93

Hey, an older version of VinCrypt has been out and freely distributable for months. It's a Video Vindicator release, so you could get it from a VV site like Demon Roach Underground BBS or the cDc ftp site (zero.cypher.com) if you wanted to take a look at an old version.

1 0

Re: VinCrypt
by peb＠PROCASE.COM 26 May '93

26 May '93

I saw their package at Fry's last weekend. It has a double DES mode too. It seems to have only manual encrypt/decrypt. The right way to do it is have a device driver do it for you (say, a Mach user level pager for a crypto disk). Data Encryption Standard or RSA Data Security Inc's standards are not secure because their basic algorithms have been given to the National Security Agency. VinCrypt's source code will not be passed around, Great spin, but not much more than spin. Paul E. Baclace peb(a)procase.com

3 2

Encrypted UNIX "talk" available
by miron＠extropia.wimsey.com 26 May '93

26 May '93

Last revised Tue May 25 21:05:50 PDT 1993. What is YTalk? ============== YTalk is a multi-user drop-in replacement for the UNIX "talk" program. I have added encryption facilities to it, including private key and PGP authentication. Features ======== - Multi user capabilities. - Drop in replacement for /usr/ucb/talk. - Diffie-Hellman exponential key exchange for session keys. - IDEA encryption in CFB mode. - Password authentication. - PGP authentication. - Logging of conversations to a file. Known bugs and misfeatures ========================== - No security the first time you use it, until the random seed file is created (around 300 keystrokes). - Some problems with the talk daemons on Ultrix and SCO-Unix. - Port to Alpha (64bit) incomplete. Availability ============ Version 2.1 Ftp: soda.berkeley.edu:/pub/cypherpunks/applications Bug reporting ============= All bugs to miron(a)extropia.wimsey.com. -- Miron Cuperman <miron(a)extropia.wimsey.com> | NeXTmail/Mime ok Unix/C++/DSP, consulting/contracting | Public key avail AMIX: MCuperman | Laissez faire, laissez passer. Le monde va de lui meme.

1 0

RSA in CMOS?
by L. Detweiler 26 May '93

26 May '93

Many people have been talking about cryptographic applications in hardware on the list. I suspect these will be largely untapped until a chip that does general-purpose RSA encryption comes along. There are many DES implementations that could be integrated with such a chip and then worked into computer cards, telephones, cryptography kits, etc. Does anyone know of the existence of an RSA chip? To the best of my knowledge they do not exist. Are there any plans for an RSA chip? The chip would ideally *not* be constrained to work with DES, or at least the DES encryption would be an option in addition to just pure RSA encryption of arbitrary data, for reasons of potential insecurity in DES and emergence of other superior algorithms (which upon appearance would not automatically make a general-purpose chip obsolete).

2 1

AT&T
by meyer 26 May '93

26 May '93

I recently switched my long distance carrier from AT&T to another, since they bribed me to do so with an offer of $35. Tonight a lady from AT&T called to ask why I switched. "They bribed me," I said. I said that I also had a problem with AT&T's support of the Clipper (or Wiretap) Chip. She had never heard of this, but I said to write this down on her report so that some higher-up in AT&T would get the message. She then offered to pay me $50 to switch back to AT&T. I thought, if I keep switching, and they keep upping the amount, eventually I can pay my rent this way. But no. I said: As long as AT&T supports the Clipper Chip I'll never return to AT&T! Ah, the pleasure of occupying the moral high ground. (Now, if they'd offered $500 ...)

1 0

Re: Steganography
by wcs＠anchor.ho.att.com 26 May '93

26 May '93

> Here is a pitfall to be avoided in Steganography using > low bits of AD converter output. Such converters may be biased > in their low bit. [...] Falling too close to 50% would be a clue that the data That's not too risky for graphics, since many scanned pictures aren't based on raw A/D converter output; they've been processed and squashed down to some smaller number of bits. A more serious concern is compressibility - a real image file is probably more compressible than a file with the low-order bit replaced by a crypto-bit, since the real data has moderate correlation and the crypto-bits are random. I doubt the Feds will immediately start looking to see if you're shipping GIF files that have significantly worse compression than average, but they'd probably find something if they did it. Bill Stewart

2 1

No Subject
by Anonymous 26 May '93

26 May '93

On Tue, 25 May 93 21:26:20 EDT, Bill_Stewart <uunet!anchor.ho.att.com!wcs> wrote - [ ... referring to earlier discussions on TEMPEST, ELINT and COMINT topics] > I'm not arguing about whether the stuff works, I believe that :-) It does, and I can expand further in subsequent paragraphs. > VT100s and Brother electronic typewriters are two other classic > emitters; I hadn't heard that the IBM was loud, but it's > certainly a good target. He used a very simplistic example, one which is electro-mechanical, as another list participant already pointed out. The same ELINT potential eavesdropping techniques exist, which range from keyboard monitoring (passive and active) to synchronic monitoring of "visual displays," which by all rights, parallels the electronic equivalent of monitoring your "visual" data; what is written to your visual display. > The wording *is* relevant when you're discussing whether a proposed > acronym is real or made-up-to-fit, and as I said, > > I never saw TEMPEST expanded as an acronym in any of the > > documents I read. > and the proposed expansions are really stretching credibility, > as were the quoted article's contentions that using TEMPEST protection > was illegal. TEMPEST was/is a specification that was written/developed to safeguard classified communications which were transmitted electronically, and rightly so. Digital Cryptanalysis is easy to record, measure and study; emissions are emissions. Its a well known fact that INT agencies were/are active in monitoring secure communications _recording_ for years, simply on the basis that the keys would be eventually compromised. The technical specifications of TEMPEST implementations on _SECURE_ systems are classified, likewise, the tempest requirements on confidential and FOUO (For Official Use Only) communications are less classified, at least to the level of their traffic. This was/is done in anticipation of secure, captured traffic analysis being eventually compromised. I have reason to believe that this exactly the tactics being mined now by the FBI/NIST/NSA. (whoops, slap my wrist) Traffic analysis is a dangerous concept when used in the wrong context, especially in a big brother capacity. Additionally (no classified information divulged here!), both the US INT agencies and the KGB sponsored intelligence agencies, recorded _all_ intercepted communications regardless of cryptographic tolerance, eventually under the guise that they would be compromised. This idealism alluded to the fact that compromised keys could be used to analyze past communications and provide information on future strategies. > *Clipper is a trademark of Intergraph. Oh, don't be silly. Uncle Sugar has already "officially" re-dubbed the chip the "Key Escrow" Chip. Silly, isn't it? Our Government is cheating us. Something needs to be done. Who's going to do it? Personally, I'm going to take fergp's suggestion and "question the powers that be." If any of you have a conscious, I'd suggest doing the same. To Eric Raymond: Include info on anon remailers and why they are important. Tell 'em "nobody" sent you. ;-) Quis Custodiet Ipsos Custodes?

1 0

PGP-RSAREF rumors
by L. Detweiler 26 May '93

26 May '93

Nothing has appeared on this list on this subject since the initial flurry sparked by PGP-RSAREF negotiations. I thought I would just post a few short comments based on inside sources and speculations for all the cypherpunks waiting on the edge of their consoles to hear some word. In no way should this be construed to be representative of positions on either side. I just hope to give members a little current insight and encouraging glimpse, but also show how the difficulties involved in the negotiations mean this is not as simple as Bidzos and Zimmerman shaking hands without snarling (although that's certainly part of it). A rather serious obstacle to RSAREF integration into PGP is that the RSAREF routines only `ostensibly' allow RSA encryption of DES session keys. For novices on the list, the background for this is that RSA is too slow to use to encode an entire message, so that one uses RSA to encode a randomly generated key for each session (hence the name) that is contained in the transmission. The remainder of the transmission includes the message encrypted under the private-key algorithm (e.g. DES) with the generated session key. Since the key is shorter than the message and the private-key algorithm faster than the public-key approach, this scheme results in a net gain of speed, but with security only `as strong' as the private key algorithm. Because of suspected weaknesses in DES, Zimmerman chose to use the Swiss IDEA algorithm for the session keys, and for obvious reasons prefers to continue to do so. However, the RSAREF routines have a `published interface' that only permits the system using a DES key. There are `low level' routines that do pure unadulterated RSA encryption of arbitrary data, crucial to PGP functions, but by the terms of the license the programmer is *not* allowed to call them! The reason for this restriction is presumably that a high-degree of backward-compatibility is required of the library, so that a strict adherence to use through `official' entry points must be preserved. However, this `hamstring connected' means that by no stretch of the imagination can RSAREF be considered a `general purpose RSA cryptography library' (in fact, it appears to be designed solely for meeting the PEM standard). It also means that the cryptographic security of RSAREF is quite curiously limited to that of DES. Rumor has it that Mark Riordan got permission to put in triple DES into RSAREF for RIPEM but so far it is unclear if Zimmerman and Bidzos can/will/have hammer(d) out something that allows the current PGP IDEA cipher. The backward compatibility of all previous PGP versions, and ultimately the integration of RSAREF into PGP, is at stake. Rumor has it that even Rivest (the R in RSA!) may be helping forge something favorable to everyone. Another complication of RSAREF that most on this list are probably familiar with is that it is not permitted to be used outside the U.S. Hence parallel versions of PGP must be maintained even if RSAREF would allow an IDEA implementation. One other complication is that Mr. Zimmerman, while apparently never directly profiting from PGP use, has before publicly `reserved the right' to attempt to gain some kind of compensation for his Herculean efforts on PGP, for which he has `a life sentence' and finds that it takes major amounts of his time and commitment, although he is also firm in his promise to keep it free. Of course, the position is not wholly compatible with RSA interests. Finally, I hear that negotiations are on pause while currently Mr. Zimmerman is in the middle of his May 19 - Jun 9 `PRZ EuroCrypt Tour' and is meeting PGP fanatics, groupies, and developers all over Europe! In fact, here's an excerpt from a message that made the rounds among some PGP contributors: >From 27 May until maybe 30 May, more or less, I'll be traveling >by train from Bergan, Norway, through Oslo, then on down to Copenhagen, >down to Hamburg, and over to Amsterdam. I'll be stopping along the way to >see some sights, having never been to Europe before. > >From 30(?) May til 6 June, I'll be hanging around Amsterdam and the >surrounding area, to see some things from something other than a train seat. > >From 6 June to 9 June, I'll be in Washington DC, giving a talk at the >7 June CPSR conference in DC. Then I'm going home. > >If any of you want to pass this on to the PGP fans in Europe, who are >fanatical enough to meet me over there in my travels, feel free. If I >play my cards right, I'll never have to buy lunch while I'm in Europe. Maybe with enough encouragement and hospitality he'll make it through the subsequent negotiations without strangling anyone or being strangled :) (You may be able to reach PRZ at prz(a)acm.org.)

1 0