December 2003 - cypherpunks-legacy

RE: Stego-Rants ?
by Peter Trei 17 Dec '03

17 Dec '03

> Which of the following is the cleartext? > 1. Bit and byte dropout can significantly impede communication. > 2. Flower and shrub planting can greatly enhance landscaping. > 3. Word and phrase substitution can hopelessly disguise meaning. > 4. UFO and space-alien belief can seriously damage credibility. > If you *presume* my context, you easily identify (3). If only the wordlists > that translate between (1), (2) and (4) were available for your inspection, > you would be up the creek but you wouldn't know it. > Yes, this is aba's "exxon" at work again, and yes, it seems to me that > deniability through other-plausible-meaning is viable as a form of stego. > Grammatical correctness is easy to maintain, and care in choosing words can > preserve much apparent meaning. > Bolivar This class of code is fairly old. In 'The Codebreakers' an incident is recounted (I think from WW2). A suspected spy in the US was sent a cable from overseas, reading 'Our father is dead'. This was intercepted, and the censors, suspecting a stego'd message, substituted 'Our father is deceased'. The suspected spy immediatly sent back 'Is father dead or deceased?', and was arrested. The book contains many fascinating stories of stego and attempted stego, including mailed knitting patterns, crossword puzzles, drawings, sports statistics, etc. On the eve of Pearl Harbour, the wife of a Japanese diplomat in Oahu sent a long message to Japan describing in detail the many kinds of flowers blooming at that time in Hawaii. It was sent through non-diplomatic channels, and authorities suspecting it contained stego, failed to deliver it. After the war it came out that she did regular gardening columns for a Japanese magazine, and the message was entirely innocent. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

1 0

Re: RE: Stego-Rants ?
by Rich Salz 17 Dec '03

17 Dec '03

> From: "Peter Trei" <trei(a)toad.com> > The book contains many fascinating stories of stego and attempted > stego, including mailed knitting patterns ... It was the best of times, it was the worst of times. /r$

1 0

Re: Commercenet document on cryptography
by Rich Salz 17 Dec '03

17 Dec '03

> http://www.commerce.net/information/position/position.062695.html Thanks to Steven for mentioning this -- it's a great paper. Send it to your gov't representatives. /r$

1 0

Secure Courier and Amex Card
by nobody＠valhalla.phoenix.net 17 Dec '03

17 Dec '03

Mountain View, Ca., July 18 -- With the support of Intuit and MasterCard International, Netscape Communications has announced Secure Courier, an open, cross-platform digital envelope. The new protocol allows secure transfer of credit card, debit card and micro-transactions across the Internet. Secure Courier is an open, cross-platform protocol, meaning it will operate in Macintosh, Windows, and Unix operating environments common to Internet traffic. Specifications for this new protocol are currently available from Netscape's World Wide Web site at http://home.netscape.com/newsref/std/credit.html . _________________________________________________________ New York, NY, July 18 -- American Express' Travel Related Services Company said it is establishing relationships with four technology companies for secure Internet credit card transactions using the American Express card and the Optima card. The four companies involved, CyberCash, First Virtual Holdings, Netscape Communications Corporation, and Open Market, have different ways of securing transactions over The Internet's World Wide Web.

1 0

RE: Stego-Rants ?
by Bolivar Shagnasty 17 Dec '03

17 Dec '03

Peter Trei wrote: >> Which of the following is the cleartext? >> 1. Bit and byte dropout can significantly impede communication. >> 2. Flower and shrub planting can greatly enhance landscaping. >> 3. Word and phrase substitution can hopelessly disguise meaning. >> 4. UFO and space-alien belief can seriously damage credibility. >> (deletia) >> Bolivar > >This class of code is fairly old. Thank you. I would never have suspected. I grew up in Heinlein's barrel, fed through a hole in the side, until I was 18. >(deletia> >The suspected spy immediatly sent back 'Is father dead or deceased?', >and was arrested. > >The book contains many fascinating stories of stego and attempted >stego, including mailed knitting patterns, crossword puzzles, >drawings, sports statistics, etc. >(deletia) (shrug). The point is not whether people have used this before, or how cute the anecdotes of wartime failures or detections. The point is that everyone uses language in innumerable explainable contexts, and that we have computers with which to effortlessly transform text into other text. There is no need to knit, or invent crossword matrices, concoct drawings, or fabricate verifiable sports statistics. With word substitution, anything can mean anything. I never suggested it take the place of encryption, or that I thought it a new form of stego. The implications may be new in the context of ubiquitous high-speed computers and electronic communication, in that the evidentiary value of written language can be shown to be so malleable as to be useless. For example, how would you like to have to ascribe particular meaning to the accumulated notes and files of someone who collects "exxon" wordlists? Virtually anything you process against any of the wordlists will change into something equally as interesting (or uninteresting) as the original. The presence in a system of wordlists tends to reduce the content of natural language files in that system to examples of sentence structure. As an example of just how malleable sentence structure templates can be, the defense in such a case might convert the prosecution's charging document into a glowing commendation of the defendant, suitably introduced through an expert witness. Bolivar (who hopes to retire when he finishes school)

1 0

Government Mandated Keys
by hoz＠univel.telescan.com 17 Dec '03

17 Dec '03

I want to register the 1-bit key of "1". I expect to send about half my message bits encrypted, the rest will be clear-text. Rick F. Hoselton (who doesn't claim to present opinions for others)

1 0

"Hey Phil! Stop telling people *not* to use PGP!" (plus: "help me with my PGP problems!")
by Bryce Wilcox 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [I posted the following to alt.security.pgp and sci.crypt. -Bryce] (If you don't want to help with my problems, skip to "Zimmermann needs to change pgpdoc1.txt" at the end.) First, I am trying to communicate with a fellow who refuses to upgrade to PGP2.6 because if RSA (as opposed to RSAREF) was good enough for Phil then it's good enough for him! Assuming for the moment that convincing him to upgrade is not feasible, isn't there a hack by which I can interoperate with him? He's using 2.3a and I'm using 2.6ui, 2.6.2, 2.6.1 and 2.6. (More on that later...) I can hack the C code if that is what is necessary to interoperate. Second, I am using several public keys and several different versions of PGP because I work from various computers with various levels of security. That is: when I am in the University's computer lab I use one key <617C6DB9> and the University's 2.6.2 but when I am on my home computer I use another <148A11E5> and my linux PGP 2.6.1 (I'm going to upgrade it any day now...). I also have a couple of other keys with "Bryce Wilcox" in the User ID field for other uses. The problem/gripe is that whenever I try to manipulate public keys on my keyring, PGP grabs the first one with User ID "Bryce". How do I extract, edit, sign, etc. the *other* "Bryce" keys on my public keyring. I tried giving PGP the Key ID, which seemed like the most reasonable user interface to me, but that didn't work. Third, how do I set those "PGP-Note" strings that appear in some people's PGP Signature Blocks? And lastly, a gripe. Zimmermann's "pgpdoc1.txt" needs to be changed. Let me explain: I am in the (long, drawn-out) process of trying to convince my friends and family members to use PGP. The first hurdle is that it is a pain in the butt to use, and they are not going to use it if it means they have to learn a handful of Unix commands and spend 30 seconds screwing with it every time they want to send mail. But that isn't the subject of this gripe. The second hurdle manifests when I send them a copy of "pgpdoc1.txt". They start browsing through it and come upon "NEVER EVER use PGP on a remote, multi-user system. It wouldn't have maximum security in that situation." They say "Oh, well I guess I can't use it then because damned if I'm going to upload and download all of my mail at 1200 baud just so Bryce will quit bugging me about this PGP thing." So I say "No no no, using it on a remote system is still better than nothing. Just be aware that it is easier to crack your secret key when you use it there than if you kept it on your home computer." So they go back to reading "pgpdoc1.txt" and it says "NEVER EVER use a public key which was sent to you through the Net. It could be tampered with." So they say, "What, I have to make a long-distance phone call to Cousin Joe in Israel before I can send him a 'Happy Birthday' message using PGP? Why bother?" And I say "No no no, using a key which you got through the Net is better than using no key at all, just be aware that if someone *really* wanted to spy on you that they could have tampered with it. When you see Cousin Joe next Christmas you can compare keys with him and make sure you have the right one." In short, pgpdoc1.txt needs to quit saying "NEVER EVER use PGP in other than MAXIMAL SECURITY situations" and start saying "If you want MAXIMAL security, do it this way, and if you are satisfied with lesser security, here are other options." I am fond of saying that we PGP enthusiasts have two choices ahead of us within a couple of years: either 5,000 enthusiasts using PGP with MAXIMAL SECURITY at all times, or 5,000 enthusiasts with MAXIMAL SECURITY and 10,000,000 computer-illiterate e-mail users using PGP with push-button interfaces and multi-user remote systems. The important thing, of course, is the easy-to-use, e-mail-integrated software (version 3.0, I hope?), but it would also help if Zimmermann's PGP Doc didn't tell those computer-illiterates to either "become enthusiasts or don't use it." Bryce signatures follow /=============------------ URL of the Day: DigiCash bv Bryce Wilcox, Programmer The currency of the future! Give me a bryce.wilcox(a)colorado.edu cyberbuck because I gave you this URL: ------------=============/ http://www.digicash.com/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMA1EKPWZSllhfG25AQHzPAP+MB/JLhN+Un9yVXRv5fejb297YONynlPF EXxN6L7OwcD4q9XE23XdlutlQbAoK2tKbBLjTYat7s/t53W+jpCyKOChN7zn4V+I bdAu8TKE4IG9a7fzxK0jqcpHBWqU2SaRxpaPEKl7HXbtFJxdKqn1n/M7INPJxF2w /JsyZom8gmk= =Tzje -----END PGP SIGNATURE-----

2 1

ANNOUNCE: bruteRC4, 40 bits all swept
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Well we have demonstrated that 40 bit RC4 can be brute forced in around a weeks compute time. (We've also learned a list of thinks to fix for the next attempt as no key was forthcoming :-|, details on why not and what is being fixed to ensure this doesn't happen with a future RC4-40 or with the coming 40+88 SSL brute forceing are given below) The problems are logistic, human error, etc, from a compute time point of view it *really* was a full sweep of a 40 bit keyspace. And on average you would expect to sweep in half this time. The bulk of the work was done in under one weeks compute time, but problems with people forgetting to acknowledge what they swept, meant that 3 or 4 people swept the remaining key space over, which slowed down this announce. Here's the hall of fame, for bits/percentage swept per identifiable contributer (this is tallied by acknowledgement, if you swept but did not acknoweldge quickly enough or at all, that work won't show as the last keyspace was re-swept to hurry things up. The first acknowledgement to be recieved counts, the rest get ignored). bits/40 percent contributer ---------------------------------------------------------------------- 37.2 bits (14.063%) Jon Shekter <jshekter(a)alias.com> 36.4 bits (8.081%) Alvin Brattli <alvin(a)phys.uit.no> 36.1 bits (6.909%) anonymous 36.1 bits (6.836%) Dan Bailey <merzbow(a)ibm.net> 36.1 bits (6.812%) Piete Brooks <Piete.Brooks(a)cl.cam.ac.uk> 35.6 bits (4.688%) Loren Rittle <rittle(a)comm.mot.com> 35.6 bits (4.663%) Adam Back <aba(a)dcs.ex.ac.uk> 35.4 bits (4.102%) Eric Young <eay(a)mincom.oz.au> 35.4 bits (4.004%) Fred <admin(a)dcwill.com> 35.3 bits (3.809%) Martin Hamilton <martin(a)mrrl.lut.ac.uk> 35.2 bits (3.711%) Kevin Wang <kwang(a)blackbox.punk.net> 35.0 bits (3.125%) Richard Martin <rmartin(a)alias.com> 34.7 bits (2.490%) Dan Oelke <droelke(a)aud.alcatel.com> 34.3 bits (1.978%) Branko Lankester 34.0 bits (1.611%) Simon McAuliffe <sai(a)comp.vuw.ac.nz> 34.0 bits (1.562%) Mike Gebis <m-gebis(a)uiuc.edu> 33.8 bits (1.392%) Pat Finerty <zinc(a)zifi.genetics.utah.edu> 33.8 bits (1.367%) <hodgeman(a)csd.uwm.edu> 33.5 bits (1.123%) Panu Rissanen <Panu.Rissanen(a)lut.fi> 33.4 bits (1.001%) Paul Bell <pjb(a)23kgroup.com> 33.3 bits (0.977%) Matt Thomlinson <phantom(a)u.washington.edu> 33.3 bits (0.952%) Will Kinney <kinney(a)colorado.edu> 33.2 bits (0.903%) T J Hardin <hardin(a)cyberspace.com> 33.2 bits (0.879%) Patrick May <pjm(a)ionia.engr.sgi.com> 32.8 bits (0.684%) Stephane Bortzmeyer <bortzmeyer(a)cnam.fr> 32.7 bits (0.635%) anonner 32.5 bits (0.537%) Matt Pauker <mpauker(a)peganet.com> 32.5 bits (0.537%) Ed Kern <ejk(a)digex.net> 32.5 bits (0.537%) Andrew Kuchling <andrewk(a)cst.ca> 32.5 bits (0.537%) <rmtodd(a)mailhost.ecn.uoknor.edu> 32.4 bits (0.513%) <somogyi(a)digmedia.com> 32.3 bits (0.488%) Jon Baber <jbaber(a)mi.leeds.ac.uk> 32.2 bits (0.439%) Bryce Boland <bryce(a)cybernet.co.nz> 32.0 bits (0.391%) Thad Beier <thad(a)thresher.uucp.netcom.com> 32.0 bits (0.391%) Per Stoltze <stoltze(a)fysik.dtu.dk> 32.0 bits (0.391%) Glenn Powers <gpowers(a)bradley.edu> 32.0 bits (0.391%) <janzen(a)idacom.hp.com> 31.8 bits (0.342%) Mike Bailey <bailey(a)computek.net> 31.7 bits (0.317%) Robert Hayden <hayden(a)krypton.mankato.msus.edu> 31.7 bits (0.317%) John Limpert <johnl(a)radix.net> 31.6 bits (0.293%) Opus 31.6 bits (0.293%) Mark Rogaski <rogaski(a)phobos.lib.iup.edu> 31.6 bits (0.293%) <josh(a)silicon.net> 31.5 bits (0.269%) Michael Bacon <mbacon(a)dfw.net> 31.3 bits (0.244%) Jim Gillogly <jim(a)acm.org> 31.3 bits (0.244%) David Zuhn <zoo(a)armadillo.com> 31.2 bits (0.220%) Russell Ross <rross(a)sci.dixie.edu> 31.2 bits (0.220%) Don Kitchen <don(a)cs.byu.edu> 31.0 bits (0.195%) Scott Renfro <csylvix!srenfro(a)cuok.cameron.edu> 31.0 bits (0.195%) Planar <Damien.Doligez(a)inria.fr> 30.8 bits (0.171%) Matt <panzer(a)dhp.com> 30.8 bits (0.171%) Joe Thomas <jthomas(a)access.digex.net> 30.8 bits (0.171%) Adrian Thomson <a.thomson(a)nexor.co.uk> 30.6 bits (0.146%) Michael Axelrod <mja(a)cacs.usl.edu> 30.6 bits (0.146%) Mark Eichin <mark(a)kitten.gen.ma.us> 30.6 bits (0.146%) Jason Burrell <jburrell(a)crl.com> 30.3 bits (0.122%) Will Ware <wware(a)world.std.com> 30.3 bits (0.122%) Kevin Maher <kmaher(a)ucsd.edu> 30.3 bits (0.122%) Josh Sled <jsled(a)cello.gina.calstate.edu> 30.3 bits (0.122%) Checkered Daemon <cdaemon(a)goblin.punk.net> 30.3 bits (0.122%) Andrew Roos <andrewr(a)realtime.co.za> 30.0 bits (0.098%) Jason Weisberger <jweis(a)primenet.com> 30.0 bits (0.098%) <pdlamb(a)iquest.com> 30.0 bits (0.098%) <matt(a)comp.vuw.ac.nz> 29.6 bits (0.073%) Mark Grant <mark(a)unicorn.com> 29.6 bits (0.073%) Lou Poppler <lwp(a)mail.msen.com> 29.6 bits (0.073%) Edwin de Graaf <graaf(a)iaehv.nl> 29.6 bits (0.073%) David Conrad <conrad(a)detroit.freenet.org> 29.6 bits (0.073%) Dan Tauber <dat(a)netcom.com> 29.6 bits (0.073%) Alexandra Griffin <acg(a)kzin.cen.ufl.edu> 29.6 bits (0.073%) <pkronenw(a)erc.cat.syr.edu> 29.6 bits (0.073%) <ghazelwo(a)cs.oberlin.edu> 29.0 bits (0.049%) Stuart <stu(a)nemesis.wimsey.com> 29.0 bits (0.049%) Pekka Riiali <Pekka.Riiali(a)lut.fi> 29.0 bits (0.049%) Jeffrey Ollie <jeffo(a)noc.netins.net> 29.0 bits (0.049%) James Hightower <jamesh(a)netcom.com> 29.0 bits (0.049%) Hadmut Danisch <danisch(a)ira.uka.de> 29.0 bits (0.049%) Bob Snyder <rsnyder(a)janet.advsys.com> 29.0 bits (0.049%) <stevet(a)smeg.net4.io.org> 28.0 bits (0.024%) Sang Hahn <sghahn(a)math1.kaist.ac.kr> 28.0 bits (0.024%) Roy Silvernail <roy(a)cybrspc.mn.org> 28.0 bits (0.024%) Ollivier Robert <roberto(a)keltia.freenix.fr> 28.0 bits (0.024%) Lucky Green <shamrock(a)netcom.com> 28.0 bits (0.024%) L Futplex McCarthy <futplex(a)pseudonym.com> 28.0 bits (0.024%) Jeff Licquia <jalicqui(a)prairienet.org> 28.0 bits (0.024%) J Francois <frenchie(a)magus.dgsys.com> 28.0 bits (0.024%) Brian LaMacchia <bal(a)mit.edu> 28.0 bits (0.024%) Andy Brown <a.brown(a)nexor.co.uk> 28.0 bits (0.024%) Adam Morrison <adam(a)math.tau.ac.il> 28.0 bits (0.024%) <mikew(a)nersc.gov> ---------------------------------------------------------------------- 40.0 bits (100.000%) 89 cpunks + x * anonners in 1 weeks compute Report is on the brute-rc4.html page also: http://dcs.ex.ac.uk/~aba/brute-rc4.html Problems. --------- But, briefly these are the things which may be responsible for the failure to find a key: a) We weren't sure if we had a known plaintext / ciphertext pair This due to lack of Microsoft Access specs, this was known from the begining, but we thought we'd try it and see. b) Eeek! There was a bug in bruterc4.c for some time which affected Alphas, and possibly other BSD machines. This meant keyspace wasn't being searched when the -v option was used. c) Some people reported that their browser / uuencode software combination meant that cutting and pasting of the uuencode plain text and cipher text files was silently failing due to extra spaces inserted by a flawed pasting operation. d) Human error - it is possible that some keys were unswept - by accident. e) Malicious humans - we don't know, but think this was not a problem. Solutions. ---------- Proposed solutions for future brute forcing efforts (such as the upcoming SSL effort), for respective points above: a) Need better spec of MA, or more experimentation / reverse engineering. For SSL this is not a problem as the SSL specs are openly available and very detailed. b) Write bug free software :-) Test more rigourously on multiple unixs and architectures with a brief test run. c) Use hex numbers in a config file. Ie don't use uuencode on web page. d) We're going to have the programs (bruteRC4.c and bruteSSL.c) produce a checksum on completion. Acknowledgements of swept keyspace must be with checksum. Crude check to reduce chances of mistyped big hex nums. Represent the key space as a 4 digit hex number like this: 1a23, in terms of 24 bit keyspaces, and represent keyspace to sweep in terms of numbers of those, lots of people had difficulty reasoning in log base2 for bits. e) Do nothing yet. If we get lots of compute and it proves to be a problem perhaps implement some redundancy into the system. Coming soon brute force attempt on Hal Finney's brute of 40+88bit SSL. Watch this space, several cypherpunks are hard at work optimising their bruteSSL.c code, and also writing farming software via a system of servers connected via sockets. The WWW page doler will still be available for those with out direct IP. Hal Finney's SSL challenge is here: http://www.portal.com/~hfinney/sslchal.html More on SSL later, but we hoped to give the SSL one a wider announce in sci.crypt, and see how *fast* we can brute 40 bit keyspace. Hope to see your compute in the brute SSL effort when it is announced, Adam -- HAVE *YOU* EXPORTED A CRYPTO SYSTEM TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ --rsa--------------------------------8<------------------------------------- #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL ($k,$n)=(a)ARGV;$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2% Sa2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*' ,$_)while read(STDIN,$m,($w=2*$d-1+length($n||die"$0 [-d] k n\n")&~1)/2) -------------------------------------8<------------------------------------- TRY: echo squeamish ossifrage | rsa -e 3 7537d365 | rsa -d 4e243e33 7537d365

1 0

Re: Government Mandated Keys
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 11:02 AM 7/19/95 PDT, rick hoselton wrote: >I want to register the 1-bit key of "1". I expect to >send about half my message bits encrypted, the rest will be clear-text. Oh, go ahead, register 0 also. You'll probably want to switch keys occasionally during sessions. # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com

1 0

Re: cypherpunk "Zen" victories
by Doug Hughes 17 Dec '03

17 Dec '03

Vladimir Z. Nuri scribbled: > >I was recently marvelling at how much the "cypherpunk agenda" >is being advanced even in light of what would seem to be setbacks. >Particularly in the area of anonymous remailers. We now have a very >major article on remailers and Julf's setup in the NYT that portrays >them in an unbiased, unhysteria-stricken mode. Also in the article, >it quotes the police as regretting their falling victim to >Scientology manipulation and investigating the remailer "without >cause". A major officer is quoted as saying, roughly, "we are >going to need a crime before we investigate in the future". > Could you provide a page, date, and title for this article? I would like to read it but don't get a daily subscription. Muchas gracias Doug Hughes Engineering Network Services doug(a)eng.auburn.edu Auburn University

1 0