December 2003 - cypherpunks-legacy

re: HTML, OLE
by Dr. Manhattan 17 Dec '03

17 Dec '03

> Has anyone considered OLE compliant PGP encrypter/decrypter objects > that would act on the contents of the document? I've thought about it, and am just starting to climb the OLE learning curve (I am reasonably familiar with Windows programming with MFC). This of course would assume a native windows PGP, a feat that would require substantial rewriting of PGP itself. This is something I will not undertake since PGP itself is apparently going to heavily changed/updated in the future (PEM compliance, dbm files for keyrings, an API, etc.) and I don't want to put effort in an evolutionary dead end. But after that, making PGP an OLE client wouldn't be too much extra work. Then you could link/embed OLE items into a PGP document (such as Word, Excel, Write, Paint, Sound Recorder, any other OLE server items). Actually, embedding would be necessary since a mere link wouldn't survive encryption and decryption on a possibly different machine (i.e. the link would point to meaningless memory). The fancier approach would be to make PGP an OLE server as well, such that you could link/embed a PGP document (encrypted text, signed text, etc.) into other apps. Again, embedding would be necessary. If PGP were an OLE client, you ould embed graphs, pictures, sound, spreadsheets, etc. into a document, and encrypt the document. If PGP were an OLE server, you would embed encrypted pictures, encrypted spreadsheets, encrypted cound, etc. into a document and mail the document. Of course, it would seem easier to just embed OLE items and encrypt the document once. I don't know what the prefered behavior is. I lean towards PGP as an OLE client.

2 1

(Fwd) Re: NSA seems to be lobbying against bank use of triple-DES
by John Young 17 Dec '03

17 Dec '03

Forwarding Cyberia-L mail by: dcain(a)pioneer.uspto.gov (David Cain) on Wed, 23 Nov 7:8 AM ------------------- John Thomas writes: > It's clear that NSA is opposed to triple-DES because it cannot break it. > I'm not supprised the banks are going ahead even if triple-DES cannot be > exported; it will be trivial to develop the hardware overseas, since all > the algorithms are public. Although NSA will neither confirm nor deny <grin> one of the fundamental principles of cryptography is that any encryption system which cannot be broken is also inefficient - like the one-time-pad. NSA may be concerned with allocation of CRAY resources, but I doubt they are concerned about the viability of breaking triple-DES. One of the most important concepts of cryptography is that false security is worse than poor security, for if you are aware of a system's vulnerability, you can guard the weak points. NSA's point that layering encryptions not only doesn't strengthen the security, but may create patterning that is more susceptible to differential analysis than a single DES pass, is an important one. More is frequently less in crypto. Now, I have no more insight into NSA motivations than the next shmoe, but the objections they raise are legitimate from a security standpoint. As for independent creation in Europe, there is a component to "real" hardware DES which is classified. dc Primary Examiner USPTO Cryptography David Cain * Speaking for no one * Escape to find the shining light dcain(a)uspto.gov * Borne within evolving sight dcain(a)osf1.gmu.edu *

2 1

Re: (Fwd) news spoke
by acspring＠knoware.nl 17 Dec '03

17 Dec '03

>Forwarding Design-L mail by: <carr0023(a)GOLD.TC.UMN.EDU> () on (by John Young) >_________________________________________________________________ >___________ UNIX(r) System V Release 4.0 (gold.tc.umn.edu) > >This system is for the use of authorized account holders only. > >Individuals using this computer system without authority, or in >excess of their authority, are subject to having all of their >activities on this system monitored and recorded by system >personnel. > >In the course of monitoring individuals improperly using this >system, or in the course of routine system maintenance, the >activities of authorized account holders may also be >monitored. > >Anyone using this system expressly consents to such monitoring >and is advised that if such monitoring reveals possible >evidence of criminal activity, system personnel may provide >the evidence gathered to law enforcement officials. This text is taken almost verbatim from CERT Advisory CA-92:19. The idea behind it is to protect systems operators from lawsuits if they monitor the keystrokes of a hacker breaking into their system. It's quoted in Cheswick and Bellovin's _Firewalls_and_Internet_Security_ (a totally cool book BTW). They quote from the case _United States_v._Seidlitz_ 589 F.2d 152 (4th Cir. 1978) where the defendant claimed that keystroke monitoring of his attempt to break into OSI's computer constituted an illegal wiretap. The judge blew him off, of course. If you're worried that this boiler plate legalese gives them carte blanche to listen in on your IRC sessions on #bondage, then forget it. It (_probably_) doesn't. -- Man! Woman! Child! All! are up against the WALL of SCIENCE! <acspring(a)knoware.nl> PGP Key print:4C 17 EC 47 A1 6D AF 67 F3 B4 26 24 FE B2 0F 5E

1 0

stego
by shaggy＠phantom.com 17 Dec '03

17 Dec '03

i've written a major upgrade to hideseek, a steganography program i wrote for dos. the guy who was keeping it on his ftp site for me (xenon@netcom) isn't answering my mail so i have no where to put the new version. 1) does anyone want to look at the program? 2) does anyone know of a good ftp site for the program? 3) thanx sh4g| ----- | Coming, i don't enter by the gate shaggy(a)phantom.com | Leaving i don't exit by the door shag(a)gladstone.uoregon.edu | This very body is the land of tranquil light

1 0

Rising from the ashes of Underdog
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Happy Thanksgiving, C'punks ! I was forced to shut down the Underdog remailer on this account the other day, under pressure from my sysadmins. Since I've been concerned about the vulnerability of the remailer anyway, I had already laid plans to start a remailer on another account. I have far too much work to handle over this vacation to establish it now, but I hope to begin operating a Mixmaster remailer within the next several weeks. [Lance, could you send me the code, please ? Thanks.] An interesting dilemma emerges from this project. On the one hand, it would be good for the operator(s) of an anonymous remailer to be anonymous {her,him, them}sel{f,ves}, for {his,her,their} protection. On the other hand, it would be good for the operator(s) to have (a) good reputation(s) so that the remailer will be trusted and hence used. The answer, I suppose, is positive reputation development for a nym. So I'd say this is a good example of a concrete application of the study of positive reputation systems, in case anyone was hunting for justification. I promised to elaborate on the reasons for the shutdown. The gist is that some complaints about the Scythe spam were sent over my head, and the effects finally filtered back down to me yesterday. It appears some people didn't notice (or chose to ignore) the headers giving my complaint address. Some folks here are apparently laboring under the impression that I actually _wrote_ all those articles myself ! Damage control is underway, but my reputation here has probably suffered permanent harm. :< At any rate, operation of a remailer will apparently violate a forthcoming acceptable use policy which was already in the works. I haven't broken any existing rules, but it's been made abundantly clear to me that such actions will not be tolerated. Meanwhile, I need to hack the old remailer script to automatically junk all the remailer mail until it stops flooding my mailbox.... - -L. McCarthy, only halfway through the longest week of my life "I know you won't let me down, `coz I'm already standing on the ground" -Eagles -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLtVDm2f7YYibNzjpAQEgHwP/aYM0mHb/TPput6gb9qHQvCnFNukEH7sx Gh7Z8aM4JSQaHJR2MqXVjnH84b+HauS7vB3oqQ4er1TsUAoIqNJhmCslIhi28GJj ON6xe/4hxIsmMsnZueJX+veZFg/CtanxW6vBrWS3zQKoxFVqutcu8CRa37QmbIV6 h7oe3JWUeCs= =ljAS -----END PGP SIGNATURE-----

1 0

hideseek
by shaggy＠phantom.com 17 Dec '03

17 Dec '03

ok, hideseek is now at io.com in /pub/user/dfloyd somewhere. hideseek is a steganography program for dos. this is version 5.0 and is a serious upgrade from the previous version. sh4g| ----- | Coming, i don't enter by the gate shaggy(a)phantom.com | Leaving i don't exit by the door shag(a)gladstone.uoregon.edu | This very body is the land of tranquil light

1 0

Hide and Seek 5.0 is in my io.com ftp directory
by dfloyd＠io.com 17 Dec '03

17 Dec '03

For now, Hide and Seek 5.0 is in my ftp directory at pentagon.io.com. (/pub/usr/dfloyd/pub Kinda long path, but its there.) If you have anything interesting, stick it in my incoming dir...

1 0

RELEASE: Secure Edit a0.3.1 for Macintosh
by Thomas J. Bryce 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Miyako Software(tm) presents... SECURE EDIT(tm) VERSION ALPHA 0.3 FOR MACINTOSH SECURE EDIT is an editor designed for editing sensitive text buffers. It is designed to prevent plaintext from ever being written to disk, even if only momentarily. You might fail to overwrite or encrypt such plaintext properly, or your opponent might be able to retrieve some of the information even though you wiped it (see docs for details). Word Processors generally create temp and scratch files that leave plaintext on your drive whether you like it or not. Secure edit fixes this problem. Sometimes you need to quit in a hurry and have all your data encrypted and saved. Or you might prefer to have your files encrypted at all times so that you never forget to re-encrypt a file you worked on. Secure edit sports the following features to serve these and your other data security needs: * Plaintext is never written to disk - Secure Edit locks all sensitive buffers in memory so that virtual memory will never swap them to disk. This includes the text you are editing as well as any encryption keys in use. * Secure Edit never creates plaintext temp or scratch files, ever. * Secure Edit offers the option of saving files directly in encrypted format so you never have plaintext on the hard drive. * Your data is compressed and encrypted in RAM with the IDEA algorithm, then written to disk in encrypted format. The key is the MD5 hash of your passphrase. This is the same basic technique used in PGP conventional encryption. The SHA hash and the MD5 hashes are used to create information against which to validate keys without compromising their security. See docs for more details. * Secure Edit can mantain a secure, private clipboard, interconverting with the system clipboard only when you use OPTION-cut,copy, and paste. This prevents the system from getting a copy of your sensitive data and possibly writing it to disk, or leaving it around for another user to see. * Secure Edit can open foreign text files, and DOD wipe them on request when you save the file in encrypted format. * Secure Edit offers a default passphrase option so you only need to enter your passphrase once. It also offers the option of validating your phrase against secure validation information that can be used to check that you have entered your standard pass phrase, but which cannot be used to recover the passphrase by an opponent. This prevents you from saving under a bad passphrase and losing data. * Secure Edit offers a time-out option, whereby it will save all files and quit after a certain idle time period * Secure Edit offers an option-quit feature, whereby it will assume it is okay to save all files, and save and quit as quickly as possible * As far as I am personally aware, Secure Edit does not have any bugs which could cause data loss. However, as I am the only person who has used it until now, I am considering it an ALPHA TEST RELEASE, version a 0.3. Hence, store important information at your own risk. Save regularly! * Secure Edit alpha 0.3 is available to U.S. citizens in the U.S. at an ITAR-compliant site near you. I'm presently uploading it to ripem.msu.edu and others. * The source code is, of course, available for your inspection. * Questions about Secure Edit should be directed to me, at <tjb(a)acpub.duke.edu> Thanks for your attention. Tom Bryce - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCPAy6yQdAAAAEEAOfJ4/XS4J2wm5NCVgiXrWKALKYur+8JWuXjGYv5FBOQ1QBv D4YBODWid1vrtpAKERRTw8E7LFcWbgsArmAbuUmwKcpduEGEgDYiDlRsokCaNo7T 6XUFbsOyOLsLTycKR4jmCHcDU2vnW9cBsdDfyuWESgGdFS2etk8YjrUhOUC5ABEB AAG0Ok1peWFrbyBTb2Z0d2FyZSAvIFNlY3VyZSBFZGl0IFN1cHBvcnQgPHRqYkBh Y3B1Yi5kdWtlLmVkdT6JAJUCBRAuskMzTxiOtSE5QLkBAfwxBADVq8iB8AVSry88 JtW76dqQjDd9ZDn+9piRxFxs3gY3cS7BLwPJooOrfUYvR2hOjfP0d0lt2r2NCpmE 42zS42dRZqdjsWOQFF3H7OeLoeAf7hIxiIGNXY3OQpUkj8OoWmYvkvkL01HYAsxC 8UYGK9WgvldKyZAg5wO5lVwJHjFVd4kAlQIFEC6yQuNbsCQO6C/DvQEBkZAEAMzP WHJLIe6gUSnZHNb9BnvaPTFtJK3x78zPfp4cXHyPe4WEWx1qiDOLkCkOjhqjT5If l3ApFB/SQ2INIA/ZwobiahMrCcCV5pZsNgwcOFF8t5K3FZm8jyObojsCakI4RA2k CTp6wVSXzXPKiU7bgEP4DloRbLw05qzzpOHwyXrkmQCPAi1tElkAAAEEAO6YzP+I YXLF+7sFADICmMid8CwLs5Typz++v6G1K9H6I8bod0PJWhYF+kHe5JemoALFVE8e HOODP+/Uz+/r14zjPSRg3hw+/i88jT5SKmanD8jc1V/Lzyw6/O9miBpFuDMIgAsh bx+OnV+c8FVtCPL1Ew3SktIk4FuwJA7oL8O9ABEBAAG0JFRob21hcyBKLiBCcnlj ZSA8dGpiQGFjcHViLmR1a2UuZWR1PrQlVGhvbWFzIEouIEJyeWNlIDx0amJyeWNl QGFtaGVyc3QuZWR1PokAVQIFEC1t+Kpg1mnda5vvEQEB2rMB/R7N7SPKm0UOSgUO d1kSCzaHhscznc6ql3VB07fNrAWr+wQk/4iJShZf7Ssqa4AGifsVbJXSw7fIIzgo XnvXCOQ= =y3Ve - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLtS2aE8YjrUhOUC5AQFgkwQAnR5U56xDU1rxNSgYYyGKZzyiw+lDtZ9l hVbXuxXcCxSrHJ+aeXtDrfWOr2eRcfaqgBwDm8dOikWn03jpDid7tY/KpR9YbO0M JtjzKNf5uSiTw4o0LLDAEaoBlSJ3PAPPprSWXbaY/RXkEuvCsErz0vo1uJRh2o8B z0/lpULnbTM= =pcoL -----END PGP SIGNATURE----- Please note: the correct version number is now a0.3.1

1 0

Re: Encrypttion API (was: PGP DLL)
by Andrew Brown 17 Dec '03

17 Dec '03

On Wed, 16 Nov 1994, David K. Merriman wrote: > If it helps any, there is a collection of encryption routines in .dll format > on sable.ox.ac.uk - they're in a file called wincrdll.zip. The zip file > includes the .dlls, source code, and brief explanatory text. The routines > are DES, IDEA, MD5, and an MD5 variant the author is calling MDC (?). I got the name MDC from the original posting of the method by Phil Karn to sci.crypt a number of years ago and it seemed sensible to retain it. Just a small point. Regard, - Andy

1 0

UK Hacker sends ex-directory numbers via remailer ?
by devans＠hclb.demon.co.uk 17 Dec '03

17 Dec '03

It looks like the remailer network is going to come under scrutiny from the British government. There is a story breaking on BBC TV news at the moment (24Nov1994, 1300hr) about a hacker who has obtained the ex-directory numbers of various dignitaries, including the Prime Minister and royal family, from the British Telecom Customer Service System computer network. It appears that the hacker sent pages of secret numbers to a reporter on the Independent newspaper via the Internet. The story did not mention 'anonymous remailer' by name, but I presume that a remailer was used. The story also did not mention that the numbers could have been printed out on a second hand, untraceable, dot-matrix printer and sent via anonymous postal mail. How did the hacker obtain the top-secret numbers ? Simply by working as a temporary employee for BT, and reading the top-secret CSS passwords conveniently written on Post-it notes next to the terminals. It has not been a good week for BT. On the Monday BBC TV Watchdog program, they were slammed for invading privacy via the newly introduced CLID system.

1 1