December 2003 - cypherpunks-legacy

Re: Tamper-Proof Software? No!
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

In your essay, you overlook the use of pseudo-code interpreters and cryptographic code mangling. It is not possible to make software unconditionally tamper proof, but it is possible to make it hard, perhaps as hard as finding a hamiltonian of a graph. I speak as a person with a 3 year cracking/tampering background. Let me pass on an experience I once had: I was trying to crack this game with a dongle. The code had dongle checks spread throughout it. I thought I could merely search for the signature of the dongle check and fix all of them, but the check was different each time, disguised by indirect addressing, illegal instructions, interrupt tricks, and stack tricks. The only solution was a tedious process of tracing the execution of the program and backtracing the failure routine. That wasn't the only problem though. On top of the dongle checks, checks for the dongle check routine and various checksum routines were spread throughout the code. In fact, there were so many of these checks that trying to separate the "useful part" of the program, and the dongle checks was hard because they were virtually everywhere. yes, it cost the game speed, but the game wasn't one that was particulary synced wih the display. Anyway, it took about a week of hacking on and off to find them all. There were about 30. What if there had been 1000? What if the code wasn't pure assembly, but a p-code interpreter which executed not a straight byte-code, but an actual recursive encryption algorithm in the interpreter? In other words, 0x80 might stand for "add a to b" in one instance, but in the next instance, "suicide mode" Perhaps the library i/o for the p-code itself also changes/gets mangled through the process. Furthermore, let us assume that this mangling is in some sense, cryptographically strong. A few things become very hard: 1) writing a decompiler for the general case 2) separating the "application" from the "protection" Why? Because in some sense, you'd have to rewrite the interpreter, or the application to remove all the "suicide" instructions. The p-code could be set up so in fact, most instructions are suicide unless decrypted properly. Thus, if you were to remove one suicide instruction, all of a sudden, a perfectly legimate section of code would become riddled with them. Removing protection would no longer be as simple as "NOPing out" the instruction. The code would be, by the nature of the interpreter, interdependent in a way far deeper than "checking for the presence of the dongle check routine" (note: this scenario is not isomorphic to the usual protection trick of having an interrupt decrypt the next instruction to be executed and encrypting the previously executed instruction. In that scenario, the re-encrypter can be disabled, so that after a complete execution, the code is plaintext for the debugger to save to disk. Here, the problem is that the code is never "decrypted" in the first place. What changes, is the meaning of the instruction set itself.) I suppose, one could attempt to isolate the suicide routine and just make it do nothing. That still doesn't solve the problem that a section of code has been mangled and probably not doing what it is supposed to. While a determined hacker could still break through this, I'd say that it would make the effort not worth it in most cases. Currently, most software protection is so simple that an hour of so in a debugger can isolate a manual check, and remove it. Most of the time, code is only skimmed. My cryptographic p-code proposal forces the hacker to virtually disassemble and understand the function of the entire interpreter, write a decompiler, remove any protection algorithms from the code, and then somehow, fix the interpreter so that the code still works. Imagine the task of having to create a plaintext which will generate a certain MD5 hash. Here, you'd have to remove the protection, but make sure the cryptographic execution flow of the interpreter matched the original. i.e. coming up with *different* code (sans protection) that causes the interpreter to decode the stream in the same manner. (if you want to know how code is p-compiled, I can explain later after I flesh it out more. I suspect I am probably reinventing the wheel for the Nth time, but I haven't read anything on it, so I may as well make a fool of myself.) Instead of picturing my p-code proposal, picture a much simpler idea. A seething morass of code, most of it garbage, protection decoys, all of it interdependent with other checks (chained in various ways), and somewhere in the middle of it all, is the application. I don't care what romantic vision of teenage hackers you have, it is possible to make removing the protection require the effort of rewriting a large chunk of the application. One of the other things I used to do was "NTSC fixing", taking PAL frequency games and fixing them for US computers. In some cases, it was simple (chop off the bottom of the screen, adjust rasters and timing) But sometimes, it required rewriting a portion of the graphics engine. This was no joy and sometimes I just gave up. If crackers had to alter just 10% of an application to get it to work unprotected, I think that would be a sufficient deterrent to most of them. Depending on how much speed you wanted to trade off, you could probably make the code arbitrarily "deep" (or, as Tim likes to talk about, imagine a hacker that has to crack a program encoded as DNA!) digression: Now grant me something more powerful. Imagine in the future that most software is in the form of distributed objects and that many of those objects reside and execute on remote systems. If these remote systems require cryptographic authentication before they allow a remote execution (e.g. Telescript), copy protection can be conditionally secure as RSA. Cracking would require writing a replacement object or buying one, presuming of course, major objects weren't trade secrets and you only had the API to work with. (once again, the function arguments could be permuted crytographically, so that even if you had the API, you still couldn't write a replacement) The result, is that you'd have to pay for software because software would consist of a client + object services, and the objects would require cryptographic cash/authentication to use, and replacements would be hard to write. However, unlike dongles, the system would be totally automatic and convenient, so there would be none of the problems associated with traditional protection (pain of look-up-in-the-manual or dongle). The same system could be extended to hypertext publishing where documents are distributed all over the net in different databases. One could pirate a "snapshot" of a document, but what makes the documents valuable is the dynamic quality of hypertext, being able to lay it out however you choose, and follow links. This means you need constant access to the databases, and therefore you pay for the service. My point in writing all this, is to disagree with Tim's implication in the cryptoanarchist manifesto, that cryptographic technology will eliminate intellectual property. Cryptography doesn't eliminate barbed wire, it is the ultimate fence. While it could provide untracable networks for "information laundering", it can also provide authenticated networks for unpiratable software, or teach us how to compile code in a manner that is "expensive" or as Tim might say "logically deep". (too deep to unravel its full meaning.) (I agree if Tim meant that it would make *legal* protection of iprop impossible, but I consider legal protection irrelevent anyway. If I need something protected, I'll do it myself, not depend on government) Well, I've said my peace. Now Tim can tear my argument to pieces. ;-) -Ray Any and all mistakes the result of lack of sleep...ZzzzT. "Information wants to be free..." "Not if Mathematics has anything to say about it."

1 0

Mass forwards vs. pointers
by Philippe Nave 17 Dec '03

17 Dec '03

On the off chance that someone is actually keeping score, I'll cast a vote for pointers instead of forwards. I don't pay for access (look closely at my address to see why), but my mail setup lumps all my mail in the inbox indiscriminately; to find critical messages from co-workers and automated software processes, I've got to wade through all the mail from the lists I subscribe to. This morning, there were 80+ messages from cypherpunks alone. If this list becomes, in effect, Usenet without Usenet newsgroup mechanisms, I'll have to bail out in order to get anything done for my Real Job (TM). I used to get Cypherpunks mail on a Unix box, and there I had a slick little Perl script sitting in my mail pipe to route Cypherpunks mail into a secondary Elm folder. This was nice, since it routed mailing list traffic away from my standard inbox. Now, though, I'm running through Microsoft Mail - until I figure out a way to separate list traffic from other mail, I'm really touchy about high-volume list traffic. Does anyone have a FAQ (or a brainstorm) on how to route Microsoft Mail messages to appropriate folders based on message content? -Philippe (No .sig, no PGP sig either - damn PC WinDoze mail software ......... )

1 0

Re: Request: Tamper-proof executables
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

re: C128's monitor was soo good... That's nothing! ;-) As early as 1987, you could purchase an "action replay cartridge" or "final cartridge" for the C64. This cartridge could freeze the execution of any progam, save *all* of memory, the state of every hardware register, and the cpu registers and flags, allow you to make changes,. and restart the program where it left off! Even more amazing, it knew the values of *write only registers* and the CIA/Raster latches! Furthermore, you could disassemble sectors directly from disk, capture sprites/graphics, and automatically save the compacted frozen state of the computer in "nova load format", which could be given to anybody (who doesn't have the cartridge), and they could load the frozen game (200+ block file) in less than 3 seconds from the 1541! Anybody could crack games! Simply enter the manual-word, freeze the game after it had been entered, and viola! The best part of the monitor was the ability to run basic programs from the frozen state without corrupting anything. Sort of a primitive cooperative multitasking. The cartridge also had a nibble mode copier in it. The cartridge later came out for the Amiga with even more amazing capabilities (like the ability to know what was in the write only blitter/copper registers) Ahh, the good ole days of 6502, VIC chip tricks, and 1541 programming. ;-) -Ray

1 0

Clipper vs. PGP (fwd)
by Aron Freed 17 Dec '03

17 Dec '03

Since I consider myself new to this whole topic, even though I have read several articles about PGP and CLIPPER, I wanted to get some more info and understanding for my senior seminar next May.... Does anyone have any opinions on what would happen if the Clipper Chip and its associates were all implemented and the general public swallowed on it?? Would we as knowledgeable computer people become outlaws??? Would be it like 1984?? Would our computer illiterate neighbors try and catch us??? And going the complete opposite direction (a full 180). If the public was able to obtain PGP as easily as we are and they would use it for everything, would that lead to the overthrowing of the government and therefore cause anarchy, due to the fact the governmnet would be helpless in knowing what everyone is doing contrary to the CIA, FBI, etc. being able to read everything we write and say through their current illegal wiretaps??? I'm just looking to get a complete picture. At this moment I would go with PGP, but I still see a lot of problems with being on either side. They seem so extreme... Aaron -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=- YABBS - telnet phred.pc.cc.cmu.edu 8888 -=- -=- -=- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

3 2

RE: Why to Care about Others' Security
by Mike Markley 17 Dec '03

17 Dec '03

FutureNerd writes ---------- | From: FutureNerd Steve Witham <fnerd(a)smds.com> | To: <cypherpunks(a)toad.com> | Subject: Why to Care about Others' Security | Date: Monday, July 11, 1994 5:10PM | | Tim May says- | | > Personally, my main interests is in ensuring the Feds don't tell me I | > can't have as much security as I want to buy. I don't share the | > concern quoted above that we have to find ways to give other people | > security. | | I can think of a couple reasons to want other people to be more secure. | | 1) The more people protect their privacy, the less profit there is in | privacy invasion, so that there will be fewer people doing it and | the techniques and infrastructure of spying might develop more | slowly. It seems that the more people protect their privacy the greater the profit will be in finding ways to invade that privacy. When all kinds of information is available in more or less public places there is little, if any, reason to pay people to get this information. On the other hand if your information is closely guarded then it costs a lot more to get that information. | | 2) The more people protect their privacy, the less privacy afficionados | will stand out from the crowd. | | 3) The more people buy privacy, the more developed the market for | privacy techniques and services, and the more private ways of doing | things will be available and easy to use. | Definitely agree with you on these two points. ===================================================== Mike Markley <mmarkley(a)microsoft.com> I'm not a Microsoft spokesperson. All opinions expressed here are mine. =====================================================

2 1

remailer@remba.mn.org offline.
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Where does one find a list of actively running remailers coupled with what runes each one needs if non-standard? (I don't use these things often enough to have kept up with any pointers I'm afraid, sorry. Been watching for a couple of days but haven't seen any recently) G From MAILER-DAEMON Mon Jul 11 19:59:48 1994 Date: Mon, 11 Jul 94 13:53 CDT From: <MAILER-DAEMON(a)kksys.com> To: <@demon-du.an-teallach.com:gtoal@an-teallach.com> Cc: postmaster(a)kksys.com Subject: mail failed, returning to sender Reference: <m0qNQOJ-0006anC(a)kksys.skypoint.net> |------------------------- Message log follows: -------------------------| no valid recipients were found for this message |------------------------- Failed addresses follow: ---------------------| <remailer(a)remba.mn.org> ... unknown host |------------------------- Message text follows: ------------------------| Received: from uum1.mn.org by kksys.skypoint.net with bsmtp (Smail3.1.28.1 #15) id m0qNQOJ-0006anC; Mon, 11 Jul 94 13:47 CDT Received: from gate.demon.co.uk by uum1.mn.org with smtp (Smail3.1.28.1 #3) id m0qNQ81-0000FdC; Mon, 11 Jul 94 13:30 CDT Received: from demon-du.an-teallach.com by gate.demon.co.uk id aa29094; 11 Jul 94 19:30 GMT-60:00 Received: from an-teallach.com by demon-du.an-teallach.com with SMTP id AA129436 ; Mon, 11 Jul 94 19:25:43 GMT Received: from gtoal@localhost by an-teallach.com (8.6.4/1.37) id TAA28615; Mon, 11 Jul 1994 19:26:11 +0100 Date: Mon, 11 Jul 1994 19:26:11 +0100 From: Graham Toal <gtoal(a)an-teallach.com> Message-Id: <199407111826.TAA28615(a)an-teallach.com> To: remailer(a)remba.mn.org X-Phone: +44 31 662 0366 X-Fax: +44 31 662 4678 X-Organisation: An Teallach Limited :: Request-Remailing-To: ... deleted ...

2 1

Request for some C'punx write code.
by usura＠vox.hacktic.nl 17 Dec '03

17 Dec '03

Hi C'punks, Some one intressted in improving my remailer ? [the author of remailer 2.00 is currently unavailable] I have some options I want to have added: _01 -> support for Anon-To: _02 -> support for ## header pasting tokens _03 -> support for Anon-passwords _04 -> support for Anon-Alternate-ID's (Nobody) -> (Random H0Z3R) _05 -> support for Memory Swapping _06 -> support for a "fuzzy" header pasting token search _07 -> support for Cutmarks: The current source is in C/C++, the system runs on MSDos, and the program has to accept Waffle file in/out put, since it is a Waffle based remailer. Send applications and information request to: usura(a)vox.hacktic.nl Thanx. -- Exit! Stage Left. Alex de Joode <usura(a)vox.hacktic.nl>

1 0

Re: Whew! The dangers of posting to Usenet
by lefty＠apple.com 17 Dec '03

17 Dec '03

>That may not have been a legit post. That group is currently >under attack by the alt.syntax.tactical morons. Ha ha big laugh :-( > >(They don't even have detweiler's intelligence as a redeeming grace) No, I've encountered Ms. Yamada before. She posts occasional non sequiturs to the Buddhist Studies list. The, for-lack-of-a-better-word, contribution quoted by Tim is entirely consistent with previous emanations from that direction. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

USACM report, Ch 4
by Carl Ellison 17 Dec '03

17 Dec '03

Has anyone read the USACM report on crypto ftp://Info.acm.org/reports/acm_crypto_study especially Chapter 4? Could it be that I missed the discussion of it?

1 0

Re: using RSA-the-cryptosystem to secure RSA-the-company's patent?
by merriman＠metronet.com 17 Dec '03

17 Dec '03

In article Jef Poskanzer <jef(a)ee.lbl.gov> writes: >Subject: using RSA-the-cryptosystem to secure RSA-the-company's patent? >Date: Sun, 10 Jul 94 20:07:58 PDT >From: Jef Poskanzer <jef(a)ee.lbl.gov> >Apropos the recent thread on tamper-proof programs... >Can anyone think of a way that RSA-the-company could include some sort >of RSA-cryptosystem-secured check in a release of PGP so that it would >only interoperate with other versions that have the same check? I don't >see how it could be done, but it's sure an intriguing idea. >--- Why in the world would we want to give them any kind of solution to something like that - particularly on an 'open line' like this? :-) Dave Merriman

1 0

Why to Care about Others' Security
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Tim May says- > Personally, my main interests is in ensuring the Feds don't tell me I > can't have as much security as I want to buy. I don't share the > concern quoted above that we have to find ways to give other people > security. I can think of a couple reasons to want other people to be more secure. 1) The more people protect their privacy, the less profit there is in privacy invasion, so that there will be fewer people doing it and the techniques and infrastructure of spying might develop more slowly. 2) The more people protect their privacy, the less privacy afficionados will stand out from the crowd. 3) The more people buy privacy, the more developed the market for privacy techniques and services, and the more private ways of doing things will be available and easy to use. -fnerd - - - - - - - - - - - - - - - spam is in the eye of the beholder (splat) -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

1 0

****Customs Goes For Encryption -- And It's Not Clipper 07/11/94 (fwd)
by Stanton McCandlish 17 Dec '03

17 Dec '03

[Copyright 1994 by Newsbytes. Reposted WITH permission from the ClariNet Electronic Newspaper newsgroups clari.nb.govt, clari.nb.top. For more info on ClariNet, write to info(a)clarinet.com or phone 1-800-USE-NETS. May 18, 1994] Posted-Date: Mon, 11 Jul 1994 16:44:31 -0400 Path: netnews.upenn.edu!crabapple.srv.cs.cmu.edu!bb3.andrew.cmu.edu!lll-winken.llnl.gov!looking!newsbytes From: newsbytes(a)clarinet.com (NB-WAS) Newsgroups: clari.nb.govt,clari.nb.top Subject: ****Customs Goes For Encryption -- And It's Not Clipper 07/11/94 Keywords: Bureau-WAS, NEWS Date: 11 Jul 94 19:19:57 GMT Approved: cn(a)clarinet.com Xref: netnews.upenn.edu clari.nb.govt:1073 clari.nb.top:1974 WASHINGTON, D.C., U.S.A., 1994 JUL 11 (NB) -- The US Customs Service has picked Information Resource Engineering (IRE) of Baltimore, Md., to supply encryption technology to protect Drug Enforcement Agency information traveling on telephone and computer networks in the Pacific Rim. But Customs won't be using the Clipper encryption technology the Clinton Administration and the National Security Agency is pushing. "Clipper simply is not available," Anthony Caputo, chief executive officer of IRE told Newsbytes. "Clipper has been approved for government agencies, but there just isn't much equipment out there yet." So the US Customs will be using IRE's technology, which uses its proprietary Atlas encryption algorithm and meets the National Institute of Standards and Technology's Digital Encryption Standard or DES for short. "DES products are the only thing you can buy today," said Caputo. "We expect to see Clipper become fairly widely used and we will have Clipper versions of our systems available when that happens." IRE was founded in 1983 by former crytologists at the National Security Agency who wanted to develop technology to make encryption easy and inexpensive. The company has focused on the banking industry, providing security for corporate wire transfers. Caputo says that Citibank, J.P. Morgan & Co., Chase Manhattan, Bankers Trust and Banc One are using IRE systems, as are AT&T and the US Treasury Department. "The government is far ahead of private industry on electronic commerce," Caputo said. "Banks are just getting around to it. One way people will use the information superhighway is for electronic commerce, and we are the best positioned company in the world for this development." (Kennedy Maize/19940711/Contact: Anthony Caputo 410-931-7500)

4 3

NIST and Micali settle Clipper patent dispute
by Jim Gillogly 17 Dec '03

17 Dec '03

NIST has agreed to license Micali's key escrow patents. I posted their press release in talk.politics.crypto and alt.privacy.clipper. The settlement is evidently open-ended; there's an article in Cyberwire Dispatch (whatever that is -- a copy was forwarded to me) that discusses the ramifications in some detail. Jim Gillogly Mersday, 19 Afterlithe S.R. 1994, 00:00

1 0

Idle question...
by Ian Farquhar 17 Dec '03

17 Dec '03

I was compiling a list of crypto algorithms the other night, trying to produce a library of description documents for the algorithms, and an interesting but idle question hit me: what ever happened to RC1, RC3, MD1, MD3, A1, A2, A4, A6, and A7? Just wondering if anyone knows... Ian.

1 0

RE: Why to Care about Others' Security
by Blanc Weber 17 Dec '03

17 Dec '03

Advocating allowance for personal methods of achieving security establishes acceptance of the idea intellectually, and there can be many philosophical conflicts on that point with the Feds (and others). Because although you may have the tools, if the Feds have their way, no one would be allowed to use them (except surreptitiously). If there is available a good product, which works well, which can be used for the purpose of obtaining personal security (apart from what a government can offer) then individuals will want to use it when they see/feel the need for it. They will seek it because it's there. Making useful products which work will contribute to the end of finding ways to "give" other people security; they can't get it if there is not a way or a means to implement it. Blanc

1 0

Gov't eyes public-key infrastructure
by Anonymous User 17 Dec '03

17 Dec '03

extracted from: Network World volume 11, number 28 July 11, 1994 page 8, page 63 Gov't eyes plans for a public-key infrastructure by Ellen Messmer Federal agencies are mulling how to set up procedures and policy guidelines for linking a user's identity to that person's public-key digital signature, but costs and liability issues in certifying users are presenting obstacles. The U.S. government intends to operate a public-key certification system for government users that will also serve the private sector, as well. But a report just completed by Mitre Corp. for the National Institute of Standards and Technology (NIST) puts the price tag at $1 billion for the start-up of the government alone, with a possible $2 billion annual operational cost for managing certificate-revocation lists. Users can sign and verify electronic documents using unique digital signatures based on a secret cryptography key, but security experts have long recognized that a certification system is needed so keys can be revoked if the key is stolen or a person changes jobs. According to Mitre's report, "The Public Key Infrastructure Study," the role of the Policy Certification Authority (PCA) could be assumed by either the U.S. Postal Service, the Federal Reserve Board, General Services Administration or even private-sector organizations such as telecommunications providers and banks (see sidebar). The Postal Service is eager to step into the role, said sources at NIST, but the high price tag for operating the X.500 directory listing public keys and revocation lists is causing some alarm. The Postal Service declined to comment. For years, the Internet Society has contemplated setting up the same sort of trusted certificate authority. But it got bogged down almost exclusively because of liability concerns, said Steve Kent, chief scientist at Bolt Beranek and Newman, Inc. PCAs nevertheless spring up. Trusted Information Systems, Inc., the Massachusetts Institute of Technology and RSA Data Security, Inc. have all set themselves up as PCAs with different policies. Apple Computer, Inc., which now ships RSA digital signatures as part of its operating system, offers a computerized certification request to register public keys with RSA. But while this type of certification may be fine for use in some commercial purchases, it would not be sufficient at Northen Telecom, Inc. (NTI), which intends to use digital signatures in multimillion- dollar transactions, noted Brian O'Higgins, director of security networks at NTI. O'Higgens said NTI is testing its own system for issuing digital signature certificates to all employees. "It's easy to do within one enterprise," O'Higgins said. "But the interenterprise applications hasn't started to happen, and that's where a government public-key infrastructure would help." A new study on legal issues faced by the government in the effort warns that a federal certificate authority must establish strict equipment and personnel requirements for the certificate-issuance process and accept some liability for improper actions. The study, "Federal Certification Authority Liability and Policy," authored by Michael Baum, principal at Independent Monitoring in Cambridge, Mass., points out that the federal government can claim sovereign status protecting it from lawsuits. But in his report, Baum notes that the commercial sector will not be ready to accept public-key certificates issued by the government for use in electronic commerce unless the government accepts some liability for its actions. "This is the foundation on which electronic commerce will be built," he said. Setting clear security for both the equipment and personnel involved is issuing public-key certificates make sense, added O'Higgins. "We absolutely have to have a security policy in this," he said. (side bar) PKI pyramid lexicon Policy Approving Authority (PAA) Creates overall guidelines for the Public Key Infrastructure and may also certify PCA public keys. Policy Certification Authority (PCA) Establishes policy for all certification authorities and users within its domain, and approves CA public keys. Certification Authority (CA) Certifies public keys for users in a manner consistent with PCA and PAA policies. Organizational Registration Authority Acts as an intermediary between a CA and a user to vouch for the identity and affiliation of the user. ------------ To respond to the sender of this message, send mail to remailer(a)soda.berkeley.edu, starting your message with the following 8 lines: :: Response-Key: ideaclipper ====Encrypted-Sender-Begin==== MI@```%ES^P;+]AB?X9TW6\8WR:2P&2%`$A:^X<=%2MQ&K,"#9W2V4M]H[VQ^ MB5V0!,$C6Y;FGL-L!")=HM/1UHHCI^%&V6:;UA,A]6>#S_D/01M'@Q/1-:(\ $ET'N,P`` ====Encrypted-Sender-End====

3 2

Modems that variate speed
by Aron Freed 17 Dec '03

17 Dec '03

I want a pose something for everyone as a new technology. I have no idea if it has been dreamed up before or if it's possible to do... Here goes: Most people communicate by modems if they're accessing the internet from home unless they're rich or just have the right connections (no pun intended). Anyway, could one create a new line of modems that could effectively and efficiently variate modem speeds to disuade people from trying to pick up any modem transmissions by say a local telephone company inorder to keep them from synchronzing data speeds. I know modems sometimes lose some speed, but for the most part they transmit at stable rates.. Am I completely paranoid about this or am I just going off the wall??? I was just reading this article about Telco Snooping that my friend forwarded to me off the NirvanNet... I'll put it up here if no one has seen it... Aaron -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=- YABBS - telnet phred.pc.cc.cmu.edu 8888 -=- -=- -=- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

1 0

Security for under a buck fifty
by Ben Goren 17 Dec '03

17 Dec '03

The dilemma with the pass phrase issue seems to boil down to the balance between entropy and memorability. The "shocking nonsense" guidelines sound like about the best suggestions I've heard for humans to generate pass phrases, but I would suggest that even shocking nonsense can be broken by somebody--or something--that thinks like Charles Dodgson. If it came from a process that includes any logic at all, that logic will be discovered if economical to an attacker. But who can remember a 132-bit true random number? Take, for example: 0X997D6C32FC8F99104FDCC8BF4B24C7031 I got that number by grabbing handfuls of pennies out of a pile of 132--a true random number generator that cots less than breakfast--though, I will admit that it's somewhat cumbersome. But a number can be represented in many different ways. Create a six-bit character set, filling from 000000 to 111111 with a-z, A-Z, 0-9, . [period], and - [hyphen]. Now, the key becomes: Mx1SmVYpMrbp3mI-sYthaX Not impressed yet? Try using the human brain's wonderful talent for seeing patterns in randomness. If your mind just happened to work exactly like mine, you would get: Mx1 misSiles moVe Yp; Mr. bop of 3m I-s Yt haX. [Yt as in the element.] I would suggest that it would only take the average person a minute or two to memorize such a phrase, especially if she were the one to do the pattern-matching in the first place. So, the end result is a ten-word pass phrase that isn't hard to learn, is only vulnerable to a brute-force attack, and would take about a sextillion years to brute-force at a trillion encrypts per second--and the universe is "only" a hundred billion years old. Can anybody suggest how to implement this? Can a computer program suggest mnemonics that would mean anything to a person? Even if the computer gives the user a screenful of such? Or, how about giving a screenful of "words," and letting the user mix-n-match? Obviously, you would need a real random number generator and a secure terminal for all this. Maybe it's time for me to write some code.... b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): Protect your privacy; oppose Clipper. Voice concern over proposed Internet pricing schemes. Stamp out spamming. Finger ben(a)tux.music.asu.edu for PGP 2.3a public key.

2 1

Re: tamper-proof p-code
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

Ray, Ray->In your essay, you overlook the use of pseudo-code interpreters > and cryptographic code mangling. No I don't. In fact, I specifically mention the latter. Ray->It is not possible to make software > unconditionally tamper proof, but it is possible to make it hard [...] Ray->If crackers had to alter just 10% of an > application to get it to work unprotected, I think that would be a > sufficient deterrent to most of them. I agree! I even said this in the final paragraph: Scott->The attack might not be cheap! But people will do it if the >reward exceeds the cost. Some of the things you mention would make a program very expensive to `crack'. However, as we both said: just expensive, not impossible. It certainly might be expensive enough to stop the particular class of attacks you have in mind. Your notes about remote trusted systems (e.g., Telescript) are accurate. The difference they introduce into the scenario is that execution is no longer under control of the attacker, and in fact the attacker can have a piece of software that `runs', but may only run after being unlocked on the trusted system, with the private key of the trusted system. I specifically mentioned and excluded this class of problems from my argument. However, you also say: Ray->Here, the problem is that the code is never "decrypted" in >the first place. Ray->Imagine the task of having to create a plaintext which will generate > a certain MD5 hash. No. The code is decrypted. It does get to the CPU. The CPU does execute instructions belonging to the `actual functionality' of the software. Comparing this to finding a text with a given hash is not accurate. (Maybe it is accurate if the attacker tries to get between the interpreter and the byte-codes; but not if the attacker just stands behind the CPU.) Either the CPU gets to see the final instructions or it doesn't. If it never sees them it is because the program doesn't or won't run in the first place. I exempted this situation from my argument. The attacker must have at least one working copy of the software. If the CPU _does_ see the instructions, then the secret is out, no matter how difficult it is to capture it ... it's still only difficult, not impossible. My argment is about communication, not about programming. Like the old joke: A: "Would you sleep with me for a million dollars?" B: "...uh, sure. Yeah, I'll sleep with you for a million bucks." A: "Would you sleep with me for twenty dollars?" B: "What do you think I am?!" A: "I know what you are! Now we're just haggling for a price." The quality and effectiveness of `protection code' (under the conditions I gave) can never amount to anything more than `haggling for a price'. I think you already understand and agree with this. The price might actually be as much as $1,000,000.00; which could be sufficient deterrent. To that end, the tamper-proofing will have succeeded. Your p-code (maybe `protected-code') proposal could be a viable product. Don't stop. After all, none of DES, IDEA, and RSA, are unconditionally secure, and they serve us well. Cheers, Scott Collins | "Invention, my dear friends, is 93% perspiration, | 6% electricity, 4% evaporation, and 2% butter- collins(a)acm.org | scotch ripple." -- Willy Wonka ..................|.................................................. Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 408.862.0540 fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com ..................................................................... 408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: ****Customs Goes For Encryption -- And It's Not Clipper 07/11/94 (fwd)
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Isn't that the same information 'Random Hoser' posted last week from some 'PR Newswire' thing? Not like clarinet to be so behind with the news... (I believe the Customs announcement was July 6th) Still, it's nice to hear it again with copyright permission this time. Maybe I'll just run over to my newsspool and delete the other article now that I don't need it any more. G

1 0

Re: Idle question...
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

From: Ian Farquhar <ifarqhar(a)laurel.ocs.mq.edu.au> I was compiling a list of crypto algorithms the other night, trying to produce a library of description documents for the algorithms, and an interesting but idle question hit me: what ever happened to RC1, RC3, MD1, MD3, A1, A2, A4, A6, and A7? Just wondering if anyone knows... Ian. Any reason why you left out A5 above? :-) ... >From gtoal Mon Jun 20 14:35:50 1994 To: cypherpunks(a)toad.com Subject: Didn't anyone note the A5 posting? X-Phone: +44 31 662 0366 X-Fax: +44 31 662 4678 X-Organisation: An Teallach Limited Status: RO Didn't anyone notice that someone posted a putative source code for the secret A5 algorithm as used in GSM phones? (It was on sci.crypt xposted to uk.telecom, on Friday). Seems someone was going to give a talk on ways of hacking the algorithm, at some university, and he got stomped on by CGHQ. So another guy has come out in sympathy and posted his reconstruction of the algorithm in C as reverse engineered from a hardware description he received in a plain brown envelope! This is *significantly* more of a coup on the net that the NSA handbook. Now, all I need is for you guys to explain coherently *why* it's a good coup and what the political implications are, and I'll feed the story to the UK press. (I don't think anyone here has it yet...) G

4 3

RE: Modems that variate speed
by Philippe Nave 17 Dec '03

17 Dec '03

Sorry I can't attribute the quote properly; Microsloth Mail strikes again... > [modems that change speed in mid-transmission proposed as a > defense against wiretap] > > Aaron This would probably thwart someone trying to tap the data stream in real time, assuming that the speed changes caught the snooper by surprise, but I don't think that real-time data traps are the real problem. Someone who went to the effort of listening in on your transmission would probably record the whole session on tape; then, they could map the speed changes and pick up all the data at their leisure later on. I would speculate that a really good DAT deck could record the modem session well enough to give your opponent all the time he needs to figure out the speed shifts and pick up the data. -Philippe

3 2

Validating IDEA
by John Thomas 17 Dec '03

17 Dec '03

Does anyone know if there is a validation suite for the IDEA cipher? I want to be able to verify an implementation on the TMS320 digital-signal processor. The NIST has such a test suite for the DES, but I haven't heard anything about IDEA. John A. Thomas b858jt(a)utarlvm1.uta.edu 75236.3536(a)compuserve.com PGP public key fingerprint: 80 21 D7 35 65 74 C8 9D 23 DB 29 78 8E 31 05 4D

3 2

Who was offering to run mailing lists?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Someone offered recently to host mailing lists... the guys below have hit a real problem and desparately need a new home. I know it's not directly a cypherpunk list (though they might in the future be persuaded to work encryption into their system ;-) ) but it's a good cause and damn good free software. If you're the person who offered, could you mail the guy below directly, or mail me by reply if that's easier. Thanks G PS There are several hundred people on the list, and traffic is heavier than on cypherpunks! PPS It's for a public-domain server that lets you mount lanmanager (DOS, Windows) filing systems on unix - a free alternative to buying a commercial NFS package for DOS. Reply-To: netbios(a)arvidsjaur.anu.edu.au Date: Mon, 11 Jul 94 17:59:55 EST From: Karl Auer <Karl.Auer(a)anu.edu.au> Subject: Mailing list being suspended! I have just spoken with the system administrator for the Samba mailing list. We currently have load problems on the machine hosting the list. Samba mail appears to be dominating all other list processing in terms of volume. The mail systems are needed for real work, so Samba(a)anu.edu.au is being suspended as of 17:00 AEST today, 11/8/94. We may be able to rehost the list, but I'm not counting on it. If there is a site out there that would like to host this list, we would be happy to forward the subscriber list. Regards, K. ================================================================== Karl Auer Microcomputer Support Group Karl.Auer(a)anu.edu.au Computer Services Centre +61-6-2494627 Australian National University

1 0

Re: Idle question...
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Roger Bryner wrote: On Tue, 12 Jul 1994, Graham Toal wrote: > Subject: Didn't anyone note the A5 posting? Does anyone have a copy of this posting? Before I get many more requests for this - I'm sorry, I don't seem to have a copy. I could have sworn I saved it but I've spent all morning grepping my disk and it just ain't there. Coincidence or Conspiracy - you make the call ;-) G PS If anyone has a *big* newsspool, look in uk.telecom or sci.crypt somewhere between 17th and 21st June.

2 1