December 2003 - cypherpunks-legacy

Re: Clinton's fake apologies (fwd)
by Anonymous 17 Dec '03

17 Dec '03

Jim Choate wrote: > > nobody(a)remailer.ch wrote: > > Subject: Re: Clinton's fake apologies (fwd) > > > Presumably he should lie to protect the state. > > Then don't take the oath: > > To tell the truth, the whole truth, and nothing but the truth. > ... > > So lieing per se isn't the problem. > > No, it's the fact that he took an oath to tell the truth and didn't. > > > Murky water > > for impeachment, methinks. > > Then you don't think very well. > What? To tell a lie is one thing, but if you preface it with "I'm telling the truth", then that is really really bad? I still think you're drawing a very fine line. I'm honoured to draw an ad hominem before revealing that I'm on AOL. -- an anonymous aol32 user.

2 1

Re: A question from Seattle
by Anonymous 17 Dec '03

17 Dec '03

On Sat, 19 Sep 1998, Thompson, Christopher W NWS <Christopher.W.Thompson(a)NWS02.usace.army.mil> sent to the Cypherpunks list, a haven for the freedom loving, alot of cryptographers, and those of non-Freeh thinking: > > hey, I'm a 28 year old living in Seattle and I've been having quite the > fantasy of watching and or participating in father/son activities...or big > brother and little brother interaction. Do you have any suggestions > where/who I might contact in the Seattle metro area? > > Thanks > > You can start with your CO and the FBI. I'm forwarding this to them for your convenience. It's all part of the service.

1 0

Toto knows how to make a 0xdeadbeef attack?
by Adam Back 17 Dec '03

17 Dec '03

As a result of my trawl through my cypherpunks archive last week looking for publically posted private keys by Toto et al, I grepped out a selection of encrypted messages sent to the list. I thought I'd have a go at decrypting these with the selection of passphrases John Young posted earlier today, in case any were encrypted with the publically posted keys, or with a conventional encryption key. I came across this post [1] posted in 5 Sep 97 which contains this encrypted message, and "challenge" to decrypt it. Now if you try to decrypt it, it says you need key 0xE6A9C799, the public key for which is on the key servers. However keyids are actually stored as 64 bits, internally to PGP messages, but only the least significant 32 bits are displayed by PGP normally. I use pgpacket to look at things and it gives you all 64 bits, the message has keyid: 0xAA33463CE6A9C799 however the key I got off the keyserver [2] has keyid: 0xAA33063CE6A9C799 which differs by 0x400000000000 or one bit. That would require knowing how to create a 0xdeadbeef key or at least use software to do this, if it is available. Unless the bit flip is part of the "challenge". Who knows. Toto did allude to hacking skills, though largely claimed ignorance. I wonder if this was feigned, or if there are other Totos who are doing the key hacks etc. eg this challenge out of bureau42.ml.org remailer. Toto is a one man computer crypto forensics persons full-employment insurance! -- the amount of stuff posted to the list with various passwords, keys, etc. The IRS guys must be either hiring some one who knows crypto, or are going to be seriously confused at this point. Then there's the use of S-Tools, they must be going boggle eyed guessing passphrases for S-Tools for all the images ever posted anonymously, or pseudonymously to the list. One wonders almost if this was his aim. Any hints Toto(s)? Firstly I haven't got the private key(s) for 0xAA33[0|4]63CE6A9C799, and secondly, what's the deal with the bit flips/0xdeadbeef attacks? My september forward secret key is below [3]. It is authenticated by my high security key, and 12 days time or so, the private key gets wiped. Adam [1] ====================================================================== Date: Fri, 5 Sep 1997 17:31:53 GMT From: bureau42 Anonymous Remailer <remailer(a)bureau42.ml.org> Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <remailer-admin(a)bureau42.ml.org>. Subject: EFF $10,000,0000 Challenge To: cypherpunks(a)toad.com Sender: owner-cypherpunks(a)Algebra.COM Precedence: bulk X-Mailing-List: cypherpunks(a)algebra.com X-List-Admin: ichudov(a)algebra.com X-Loop: cypherpunks(a)algebra.com The Electronic Forgery Foundation is proud to announce a major breakthrough in encryption technology -- Forged Encryption. We are offering a prize of $10,000,000.00 for anyone who can correctly decipher the following Forged Encryption message. -----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.0 MessageID: od2CIT3fELE7K6bkIkKGJBj0MPUJ2TT8 hQCMA6ozRjzmqceZAQQAh02x0Dxer5vzZiSJ+v7bnMZQdgp425z5OH0NF/f/mXXc vInw+UsuTXqWNEV5rEQKYjU3qHoe6suCz5f9hEEnOIBacsD28pYU4ahkGOCTuTY6 N3xKrtDRqLPInB8PY7Kfd56jjQsVVRKmJBwXqHbPax4YyUB6ZbKKvSPiuUsAAQSl BAH3CFNKcmYjf+VtpjAVOpDNM/PMm1e6m33rZ01Sq6pXC0TTabCf7hkWscet0PCL VX0l1Zw5IKaFqo+pZ3EICRMF6HQrc30G7L9TFeKr//3YsO3/bC4VBgNQHA0qf2nD ldxAsTGPlRthBTxrzE0LjeOKi/pQOLXQMPQUwEIaL9rncjFgniplFoL6Nj0guJvW VvS+gxth8hpeWss7WlFFioV0vShsS/lahA+eg/9nVy8ken8pr4m484w2vwoiSdce CarVigVaRh6tCgh0jub7CHuDFg== =Q9+G -----END PGP MESSAGE----- The EFF doesn't have a copy of the correct answer locked away in a secret underground cave in Tibet, for verification, because the above Forged Encryption message is just a bunch of crap we typed in pretty much at random. Does the government want to keep your private key in escrow? Give them a copy of your EFF private key. Hell, give them _two_ copies, in case one is corrupted.{;>) Smile when you give them to the government agent. Ask him how his day has been. Offer him some coffe, and ask about his family. Tell him you will send him a Christmas card with another copy of your EFF private key, just in case the government misplaces the copies you gave them. Put your hand over your heart, salute the flag, and sing "God Bless America" as the government agent leaves. Then fart. Use the EFF Forged Encryption sofware regularly, to send messages with Subject:'s like "The Plot Against the PREZ," "Confirmation of the date of our armed assault," "The Nuke has arrived." Keep a copy of your EFF Forged Encryption secret key in a directory named "Off the Pigs." Most importantly, never reveal in your private email to others that you are a deaf, dumb and blind quadraplegic who has been homebound since birth. That way, the outrageous claims that government agents make against you in their secret deposition for a warrant to kick in your door and terrorize you will look all the more foolish during your trial. We at the Electronic Forgery Foundation realize that some of you wise guys are thinking that, for $10 million, it is well worth your while to write a program that will decipher the above message into something meaningful. Well, knock yourself out, dudes, but if you think that known forgers couldn't possibly be lying about the $10 million, then go directly to http://www.clueserver/fucking_idiot, do not pass GO and do not collect $200. --------------------------------------------------------------------- This message is copyrighted under the auspices of the Electronic Forgery Foundation. Any misquoting, misrepresentation, or other abuse of this message would be greatly appreciated. Hell, you can tell people you wrote it, if you want to. We don't really care. --------------------------------------------------------------------- [2] (long)keyid 0xAA33063CE6A9C799 (Toto <toto(a)sk.sympatico.ca>) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 5.0 Comment: PGP Key Server 0.9.3-db2test mQCNAzMs140AAAEEAL1CAoB5pd97hIOoT6L0v05Ov8nw0unf0db6NXZ91EJAyq9p DoPGJl7Z6m5McIsNI2DrCEEt7KYdt0ZIGcqqK2gmCePYI0oQOFj+jznI3jKXg1k2 R+ngk+cUn21EfrNXFGPk1Tuc1/3Qib6cX6BZRJvvz1FNYNt/zqozBjzmqceZAAUR tBtUb3RvIDx0b3RvQHNrLnN5bXBhdGljby5jYT6JAJUDBRAzgrFaG9qyus40wB0B AeagA/47sR2GW3y/e3z63ZHqvZwsrNZabNtVsLU6QoEfomfOc0ViI+RY3w5dAjQI 62zCSj/DXaLEwYGNbqVcwjlos5STdoxFqRHpHf6hLCZSNjUaIqY19n0U0qTs6Hw4 WuRURrbMLJYVEgiZpRynmMPnwQ+1USQ1MV6MevboXeJ08lHoDYkAlQIFEDM9HqMi iRpDQSB+5QEBHJYD/0/VRUy8EAZdjjzx/82+zUJmen9rRI3EQtd+kzInP9V13ZG5 qFFihznQJukXX9A53g9l4RbZo1P+yHF+bdD3OnEbPIWDL/+0Rd3DZp53N1Pigw6A MGoyvNzYt83zNaoXlxYksBIirBusiSbJlHotQLGYTv1aaBGVAYAd8zDALdYtiQA/ AwUQM4KBc4I3FG4quJ9UEQLr0QCdFQDsbIKVKU6f5olwRSACnq/YtJoAnig/jD9Q c8CVTPsw++ok1kWZeqXViQCVAwUQM4J+6pfboLn8NWjNAQGTigQAnrFZ8OiAguWq i1LsClKo0t9y+Ly98EPnpBt2FgQN9/Z8PSZjPqEn9AJk7Z5TBhGJNXBmkULiuNA9 zvGTsRM0S7Oi6/WFUcL9rio6gMsxTnDythGaFa5YDQXgXtFxqcjsojGhe922KFnV i4xxatO9vm9Zo3JaNAK8zvg2rIrd7VSJAJUDBRAzgn8PsF+MkGb7jGUBAYbmBACV tqTdmo9Zu/e9hpEL1FQXnp1qzKilzchxf+9/mBmbCy6O/QKVkdUTptkYMVyUHh0q 1KJV4caZIx3vQyeRsK7Fe5vex38LzN9lcP99lOE9Y8nns1bwaiUONe1McWEtkEkG SMi3FaIxRCb4f5ENjRV8EzydQbHD5+Pyp0+gw9LuXIkBFQMFEDOC1g34yQH5HnUh EwEBoHAH/RDpelRJCSEtRC7upHwGbfuZL3RhlgXomiOL5plSn2i2El7hm1k1UKcG UHvcz1ni2deWRK/qLle9xN8wXIjZMATWJLfeSoSpZoq8yFKdN+r2fkpwyN4h6hmb SI0DBm73eiO7cIRgxszpQDnI5uhTp083JUX/dtFlBMtr/XsIBfg6PN6pYYIAZ1cn pqkKHHFpdJe3+/AIHzw53nJUKm8EX+Bui1EOfljB63U6oP+Q1F3Wo0C1PaN/9Hbo 3IkVSLC1i3JUQwjh0moFuB+ZeLUFTxBwp+F2Y1AcvQT6JJW529WPTXOvfT2/+wU7 uVaynaHMum8snzPWMr5v0dQbq+6+OPU= =leOK -----END PGP PUBLIC KEY BLOCK----- [3] Type Bits/KeyID Date User ID pub 2048/86B519BD 1998/09/10 Adam Back <aba(a)dcs.ex.ac.uk> (FS key, Sep 98) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzX3ILwAAAEIAL368F4iaAlWFsXFUXdgSttJaHpjcLXmqZP93FlhQRyhSco6 6wyTWEa0UQ25ynf/r/sh4Z7/xjD+HSUUCnpLDJnN9143JUO1UbDIGTq3vC+uKJjr 1OnZQMI0SOrpdUUvbz9zyC2Zsj+CACGbX+sFpecT/XxMpSeEbfoNoy5+AWjB7eIa 27qloHFGRZrDfFvewaSybck21PGVEwkTrpBQ4Yf1RGDod+Xe079jq79uZNNDgnTN UaFXFS0BmH0nJmjWE5/QkNsgy0aPuFcR65TKn54Fj7e82g1ScEYlwS3iRBuebpAU pH81flyI4qr9dvBatcpQXut+PxXT+mQxbIa1Gb0ABRO0LUFkYW0gQmFjayA8YWJh QGRjcy5leC5hYy51az4gKEZTIGtleSwgU2VwIDk4KYkBFQMFEDX3IQ0+e8qoKLJF UQEBhH4H/3u1USAlPwbGPMfMwZwBU4uCm6EPf03LKgtGa/elSn8nvrSbRrvLVdnQ aQWJBQpLegUkDlrd0LG9guGdaEJxJ3pZteeaDuC9WeHJWBuUbiyrNooTk7QGeVM1 9yTAW9zaHW/NpXSYL45XfHYuYrKiX50gAY+CSc3rE4Ei++R0gTAwRnS9JkKqsdzP CJThyy+ppteG5d7aw8L26AQQGUvcZKR3wTvGpGAfU6bZo1gmvnloSYelbxvUfkq2 ybHBZWXj7iBRPwTT6przBVp3DaCm8/gOzUBxvJZkoDsbf/iVBX/Qf8sVGq/86ksB /JmE7cAVNveJ+a9wx4kTNVmjP7Aciao= =vpQX -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Going Cashless: Bank ends ECash trial period
by Thomas Junker 17 Dec '03

17 Dec '03

Paul Gillin Editor in Chief Computerworld Dear Paul: The Computerworld article in Online News, 09/17/98 12:16 PM, Bank ends electronic cash trial By Mary Lisbeth D'Amico http://www.computerworld.com/home/news.nsf/all/9809174ecash is a good example of today's low standards in journalistic accuracy. Ms. D'Amico failed utterly to comprehend what Mark Twain Bank's Digicash program was. She wrote: Customers gave the bank their credit-card information only once, then created electronic "coins" at the bank, allowing them to make small purchases -- or micropayments -- of goods over the Internet without having to enter a credit-card number each time. Ms. D'Amico evidently confused the Digicash program with other, dissimilar Internet transaction mechanisms that are substitutes for passing credit card information over the public Internet. In fact, the Digicash program HAS NOTHING TO DO WITH CREDIT CARDS OR CREDIT PURCHASES. Is that clear enough? Digicash provided the means to move money on deposit with Mark Twain Bank into an electronic "purse," from which it could be spent with merchants equipped with Digicash software. No credit. No credit cards. No necessarily "small" purchases. Ms. D'Amico's profound leap of misunderstanding misinforms and misleads readers. It also rather completely vacates the presumably explanatory comment she attributes to the Bank's new owner's representative, Beth Fagen: Fagen also cited the changing climate in the U.S. for Internet payments. When the trial was started in 1995, she said, "people were more fearful of using credit cards to pay for things over the Internet. Now that seems to have disappeared." Had Ms. D'Amico understood the nature of Digicash, she may have questioned Ms. Fagen about the apparent non sequitur. If Digicash had nothing to do with making credit transactions "safer," why would decreasing public fear of using credit cards on the Internet have anything to do with Mercantile's decision to abruptly discontinue the Digicash program? The key fact completely overlooked, the one thing that distinguished the Digicash program from all the look-alike credit-card protection schemes, was the anonymity of the purchaser. Ms. D'Amico mentions it in passing as if it were merely a curiosity. In this increasingly fishbowl world, online purchases, particularly of intangibles such as information, are subject to tracking and record keeping that is clearly, demonstrably, becoming a danger to the privacy and well- being of the online public. It is to be expected that products and services such as offered by Digicash will find an increasingly enthusiastic market as the private and governmental abuses of information gathered on line become more widespread and more widely known. Digicash, by the way, was never considered a true "micropayment" system. Micropayment refers to the facility of trivially making and accepting payments as small as 1/100th, even 1/1,000th of one cent. No such systems have yet been fielded, and no credit card system can come anywhere close to the low transaction cost required to permit micropayments for access to Web pages, articles, or the use of minor online services such as HTML verifiers, graphic button builders, etc. It is only a matter of time before such systems become available, and they will likely be both anonymous and unrelated to credit cards. Ms. D'Amico will no doubt report the advent of such systems as yet another advance in the use of credit cards on the Internet. But then, Computerworld is the outfit that used to heavily promote the idea of trade unions for programmers and data entry clerks, the "Certified Data Processor" program, and trumpeted the release of virtual memory by IBM some ten years after it had been fielded by Burroughs Corp. Mitigating that last, the same issue of Computerworld carried a small, back-pages article about Burroughs' virtual memory, with a picture of staff at a B-5000 site celebrating the anniversary with a birthday cake bearing ten candles. Regards, Thomas Junker tjunker(a)phoenix.net http://www.phoenix.net/~tjunker/wang.html The Unofficial Wang VS Information Center

1 0

IDEA(tm) weakness?
by Anonymous 17 Dec '03

17 Dec '03

Title: Privacy Page Privacy How private is your electronic communication ? [taken from the PGP FAQ] You should encrypt your e-mail for the same reason that you don't write all of your correspondence on the back of a post card. E-mail is actually far less secure than the postal system. With the post office, you at least put your letter inside an envelope to hide it from casual snooping. Take a look at the header area of any e-mail message that you receive and you will see that it has passed through a number of nodes on its way to you. Every one of these nodes presents the opportunity for snooping. Encryption in no way should imply illegal activity. It is simply intended to keep personal thoughts personal. Do you trust your mail servers/gateways/virtual redirects ? With the increasing use of virtual email accounts which allow you to keep the same email address no matter if you change jobs, ISPs, etc, the opportunity for snooping increases. Is PGP secure ? PGP uses acombination of IDEA, RSA and MD5. RSA is used to allow the transfer of session keys and MD5 is used to generate a unique message digest from the passphrase for generating the IDEA key and signatures. IDEA is the core algorithm used to encrypt the actual message. Thus the security of IDEA is also means the security of PGP <read the section 'is IDEA secure'>. Is IDEA secure ? The IDEA algorithm (patented by ASCOM) is the core algorithmm used in PGP. It is based on a rotating 128 bit key split into 16 bit segments. The algorthm converts 64 bits of data at a time using the following operations '+', '^' (exclusive-or) and '*'. The formulas are : 64 bit data => D1, D2, D3 and D4 (all 16 bits) => K1,K2,K3....rotating extra 25 bits after all 128 bits are used There are 2 phases in each round and 8 rounds in total + 1 final round of just phase 1. Phase 1: R1 = D1 * K1 R2 = D2 + K2 R3 = D3 + K3 R4 = D4 * K4 Phase 2: E1 = R1 xor (((R2 xor R4) + ((R3 xor R1) * K5)) * K6) E2 = R3 xor (((R2 xor R4) + ((R3 xor R1) * K5)) * K6) E3 = R2 xor ((((R2 xor R4) + ((R3 xor R1) * K5)) * K6) + ((R3 xor R1) * K5)) E4 = R4 xor ((((R2 xor R4) + ((R3 xor R1) * K5)) * K6) + ((R3 xor R1) * K5)) Given a large random data message (ie 1000 samples - 64*1000 = 8Kb file). The distribution of the above operations can be used to break the key. ie both the '+' and the '^' operations give an even distribution but the '*' operator gives a biased distribution towards '0'. Distribution (where '*' has a bias towards 1 of a) R1 = a R2 = even R3 = even R4 = a (a5 & a6 are the bias for K5 and K6) E1 = (bias a5) * (bias a6) E2 = (bias a5) * (bias a6) E3 = (bias a5) - (2 * (bias a5) * (bias a5) * (bias a6)) + ((bias a5) * (bias a6)) = (bias a5) * (1 + (bias a6) - (2*(bias a5)*(bias a6))) E4 = (bias a5) - (2 * (bias a5) * (bias a5) * (bias a6)) + ((bias a5) * (bias a6)) = (bias a5) * (1 + (bias a6) - (2*(bias a5)*(bias a6))) Also as the '*' operator is biased towards its own bit for the result '1' - approx (60% to 100% depending on bit position). [Working from the low bit upwards will provide an even greater approximation as then you would have the relevant Key bits against a random data. ie for 1st bit, it is 100% dependant on the bit for a '1',...] eg using a simple 3x3 matrix on second bit, gives (only demonstrating the ratio): if K bit is 1 => bias a ~ (2/8), if K bit is 0 => bias a ~(1/8) ==> We can determine when : K5=0 and K6=0 as (bias a5) and (bias a6) will be at their highest ==> E1 & E2 are highest K5=1 and K6=1 as (bias a5) and (bias a6) are at their lowest ==> E1 & E2 are Lowest To determine between K5=0,K6=1 and K5=1,K6=0. K5 can be determined by check with E3 & E4 as they are both equal to : (bias a5) * (1 + (bias a6) - (2*(bias a5)*(bias a6))) => directly relate to (bias a5) => K5 =>When K5=0, both E3 & E4 will be low. => When K5=1, both E3 & E4 will be high. The Key rotation start bits are : Phase K1 K2 K3 K4 K5 K6 1 0 16 32 48 64 80 2 96 112 25 41 57 73 3 89 105 121 9 50 66 4 82 98 114 2 18 34 5 75 91 107 123 11 27 6 43 59 100 116 4 20 7 36 52 68 84 125 13 8 29 45 61 77 93 109 final 22 38 54 70 n/a n/a Working backwards with these distributions you can deduce the key. ie work out K5 (93..108) and K6 (109..124) from its distribution pattern [using just the distributions for E2 & E3, as E1 & E4 have had the '*' operation applied in the final phase], then with K5 and K6 work out K1..K4 (22..85). You now have the key values for K1 to K6 !!!. Modify the Samples such they are back a phase and repeat (ie for each sample work backwards using known K1..K6 to find the E1..4 values). MAJOR ASSUMPTION : Assume that a large random sample provides a close to even distribution at the end of each phase (For E2 & E3) such that the bias (ie a5 & a6) used to determine E2 and E3 are the only significant factors. Reasoning : If the distribution is not even, then it is very much easier to break (ie only the key values can cause the change in distribution pattern => know the pattern, know the key). I have developed a program which does just this (NOTE: not tested with real PGP data, as I have not had the time to investigate how the PGP file is structured, ie where the IDEA code starts and ends). It is available under a copyleft license similar to GNU. The Java Source code can be found at : [Application will not be released until beginning of 1999 when enough people are aware of the potential problem, and solutions are widely available - thus the threat to the general users privacy is kept to a minimal. Software houses which would like a delay in the release of this application so as to provide a solution should email: SGOSHA33(a)mailexcite.com with their request] What can we do ? The above crack works because there is a large sample involved. If however you pre-encrypted the file such that you got your pre-encrypted file and a key file, where this key file is small and contains only the key required to open the pre-encrypt file. You then PGP the two files, this would make it much harder to break as the key file cannot be broken from the sampling technique descibed above. I have developed an application which does just that. It is available under a copyleft license similar to GNU. The Java source code can be found here : kiss.zip To run the application you will need Java installed on your machine. Place the files in a directory named KISS. The command line is : java KISS.kiss e <filename> - encrypt java KISS.kiss d <filename> - decrypt (do not add the kiss extension to the filename) After encryption you will get 2 files. The '.kiss' file is the encrypted file and the '.lips' file contains the key used to encrypt the file. You should then encrypt both files with PGP. What is in the pipeline for the future ? Task 1 The above 'kiss' pre-encryption is not 100% safe from non-bruteforce cracking !! As the majority of files encrypted are text messages which are based mainly on the characters 'a' to 'z' thus the Ascii codes of the characters are of the form 011xxxxx. From this you can see that the rotating distribution as used above will tend toward '1'. Thus with enough samples they can deduce the key with the simple equation. KeyValue xor 1 = CommonValue ==> KeyValue = !CommonValue To prevent this my next application (codename Stable) will be a stabiliser program which will ensure that the distribution of the data has an even distribution. Target Release Date : 30/9/98. Task 2 The integration of both 'kiss' and 'stable'. Target Release Date : 15/10/98. Task 3 Port of both kiss and stable to C/C++ (for speed and also for Task 4). [Wrote Kiss and Stable in Java to test the speed of Java and also how it handled bit manipulation operations]. Target Release Date : 31/10/98. Task 4 Integration with PGP to provide uses with a much easier encryption method. Target Release Date : 31/11/98. Author : SGOSHA33 Return to Albert's Home Page.

1 0

Re: CHALLENGE? Toto/signature attack w. unpublished public key
by Adam Back 17 Dec '03

17 Dec '03

Anonymous writes: > > So next we would like to solve: > > > > s ^ e mod n = m > > > > or in other words find e, k and n st: > > > > s ^ e - m = k * n > > In addition it has to be that n is the right length based on the "s" > padding. This limits it to an 8 bit range, in this case 1024-1031 > bits. The constraint I gave was that log(n) = 1024. Bear in mind that the msbyte of s = 0x08, so we know that n > s, and I think we know that n < 2^1024 also based on the s padding from the signature. So based on this n would be in the range 1020 - 1024 bits, right? > If you make n be a product of a bunch of small primes, so that you > can make signatures with it, then a third party can detect this and > know it is bogus. He has to factor your n to determine that it is bogus though? This would imply that he had more compute than you do. (Not unreasonable threat model mind). > Also, this approach won't match the keyid of the original signature. Agree. Weak counterpoint is that the keyid is not authenticated, though if IRS have a key, they know it's keyid, and if that keyid is the one posted (unauthenticated inside the armor 0xCE56A4072541C535), this tips the probability of authorship towards the key they have. This though is perhaps not incontroverible proof, if one posits that Toto or unknown others were trying to create a complicated mess for people to confuse themselves analysing. Evidence suggests that this was/is the case: there are other messages, for example one with a signature with what is perhaps a 0xdeadbeef attack against a key on the keyservers, with the same 32 bit keyid, but a 64 bit key id differing by 1 bit. Another key which almost but not quite makes sense to PGP (a few bits twiddled). Plus lots of still undecrypted encrypted messages posted to the list, plus possibly stegoed images posted (one image was posted together with a password which was also publically posted together with instructions for recovering using S-TOOLS4.ZIP (a stego package for windows), and lots of other anonymously and pseudonymously posted images.) (One of the encrypted keys which passphrases were forwarded to the list for just today had been posted to the list over a year ago -- Carl Johnson couldn't have posted the passphrase because he is incarcerated). > Another approach is to generate an n such that the discrete logarithm > is solvable mod n. Then you can solve for e in s^e = m mod n, with > the base of the discrete log being s. Doing this you can match the > keyid and size of n without too much difficulty. Yes! Excellent. This construct (discrete logs over composite modulus to allow the same operation) is used by the identity based crypto people. The trap door is not that good, because 512 bit discrete logs are as you suggest rather expensive to compute. > Unfortunately e will not be small; it will be about the same size as n. > There are one or two keys on the public keyring which have large e's, > apparently generated by hacked versions of pgp. Some people feel > safer with random e than a small e. So this could perhaps be accepted. It's not a hacked version of PGP, I've generated such keys myself also: it is just a lesser documented feature of pgp2.x, (pgp -kg 1024 768) would give you a 1024 bit n and a 768 bit e). > (OTOH given two keys that both sign the same message, one with a small > e and one with a large one, it is obvious that the first is the legit > one and the second is the cloned one.) Not so obvious with the other key tinkering which has been going on here. It seems likely that Toto et al were purposefully trying to sow confusion, and seem to delight in leaving little clues to people trying to understand it looks like this strategy has been operational for over a year now (some of the encrypted messages which passphrases were forwarded to the list for just today had been posted to the list over a year ago -- Carl Johnson couldn't have posted the passphrase because he is incarcerated). > Unfortunately with a 1024 bit RSA modulus it is not going to be > feasible to solve 512 bit discrete logs using a reasonable amount > of effort. However by using more factors in the RSA modulus it should > become practical. The number of factors needed will depend on how much > resources you have to work on the discrete log. Resources available: one low end pentium based linux PC? :-) Just that the attack is clearly feasible is interesting though a demonstration would be perhaps more convincing to less technically aware IRS people. The biggest resource overhead is implementing that lot though, unless there exist packages or libraries which already do most of it for you. > Once you have your n and e you can sign other messages with the key. > The n looks OK from outside because the fact that it has more than two > factors is not detectable, as long as its factors are not too small. > Actually there may be a way of distinguishing n's with two factors from > n's with more, check into this. > > Also check into whether n's of this form can be factored via a p-1 > factoring attack. It may be that making the discrete log easy also makes > the modulus factorable. I think the answer to that is yes. In connection with previous discussions of implementing forward secrecy using identity based crypto (search archives for cypherpunks / coderpunks /cryptography for posts with Subject: non-interactive forward secrecy / identity based crypto ) another Anonymous describes some of the identity based crypto papers on this topic, which suggests another method of being able to compute discrete logs mod composite n. : Maurer describes an alternative set of parameters as well. Rather than : choosing small primes for the discrete logs, larger primes with a : special form are used which make the problem easy. This is based on the : Pohlig-Hellman discrete log algorithm, which applies when p-1 has all small : factors. The problem is that there also exists a p-1 factoring algorithm : which works when p-1 has all small factors. However the former algorithm : costs the square root of the size of the factors, while the later takes : work proportional to the size of the factors themselves. This gives a : window where the discrete log can be done but the factoring will fail. : : For this embodiment, Maurer suggests a modulus which is the product of : two primes, each 100 digits (333 bits) in length. This will produce : a 666 bit modulus. Have each of the primes be such that (p-1)/2 is a : product of several 13-15 digit (43-50 bit) primes. So it could be done, I think, and in such a way that you have lower cpu overhead than the attacker trying to prove one key more likely than the other. Adam

1 0

Questions for Magaziner? // taxing crypto
by Ron Rivest 17 Dec '03

17 Dec '03

Hi Bob -- I feel mis-quoted and/or mis-represented in your note (below) stating that "Magaziner mirrored Rivest's offer to tax encryption products to pay for increased law enforcement technology support". While I do feel that some measure of appropriate balance may be accomplished by increasing the budget of the FBI and other law-enforcement to help them compensate for whatever increased difficulties they encounter because of the widespread use of encryption, I do not recall ever suggesting that the revenues for such increased budgets be raised by specifically taxing encryption products, and I don't really think that is a sensible approach. We don't tax glove manufacturers to raise funds for the FBI fingerprint lab! Any such funding should come out of general revenues, not by further complicating the tax code. Cheers, Ron ------- Start of forwarded message ------- Return-Path: <cryptography-owner(a)c2.net> X-Sender: rah(a)pop.sneaker.net In-Reply-To: <v03130304b227b7401a3a(a)[24.128.118.53]> Date: Fri, 18 Sep 1998 16:44:07 -0400 To: "Arnold G. Reinhold" <reinhold(a)world.std.com>, cypherpunks(a)cyberpass.net, cryptography(a)c2.net, dcsb(a)ai.mit.edu From: Robert Hettinga <rah(a)shipwright.com> Subject: Re: Questions for Magaziner? Sender: owner-cryptography(a)c2.net Okay, so the short precis on Magaziner's answer to my question about encryption controls, foriegn or domestic, is he's agin it. He says that controlling foriegn encryption is impossible, and controlling domestic encryption is, at the very least, unconstitutional. He says that the reason the administration's encryption policy is so convoluted is that the law enforcement and the "economic" encryption camps, anti, and pro, evidently, is that the two sides are at loggerheads. Magaziner mirrored Rivest's offer to tax encryption products to pay for increased law enforcement technology support, but, hey, he's a liberal democrat, he's supposed to tax us to death without thinking about the economic, and, of course privacy consequences of raising the price of encryption. So, all in all, he got a round of foot-stomping applause from this bunch on his pro-encryption stance, because, evidently, being a payments technology forum, he was preaching to the choir. Something I found out when I was doing my own speech yesterday. I should realize that anyone building a payment system knows that digital commerce is financial cryptography, after all. :-) Cheers, Bob Hettinga - ----------------- Robert A. Hettinga <mailto: rah(a)philodox.com> Philodox Financial Technology Evangelism <http://www.philodox.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' ------- End of forwarded message -------

1 0

A personal response to your email to sixdegrees
by Mixmaster 17 Dec '03

17 Dec '03

BW1015 DEC 05,1997 4:06 PACIFIC 07:06 EASTERN ( BW)(PROFILE/MACROVIEW-COMM) Corporate Profile for Macroview Communications Corp., dated Dec. 5, 1997 Business Editors NEW YORK--(BUSINESS WIRE)--Dec. 5, 1997--The following Corporate Profile is available for inclusion in your files. News releases for this client are distributed by Business Wire and also become part of the leading databases and online services, including all of the leading Internet-based services. Published Date: December 5, 1997 Company Name: MacroView Communications Corp/sixdegrees Address: 90 William Street, 3rd Floor New York, N.Y. 10038 Main Telephone Number: 212-583-1234 Internet Home Page Address (URL): www.sixdegrees.com Chief Executive Officer: Andrew Weinreich Investor Relations Contact: Shoshana Zilberberg Business number: 212-583-1234 X628 Public Relations Contact: Shoshana Zilberberg Business number: 212-583-1234 X628 Industry: Internet/WWW Company description: MacroView Communications Corp., developer of sixdegrees, is in the business of creating Web-based products which help individuals build their own virtual communities based on their personal and professional relationships. sixdegrees, located on the Web at http://www.sixdegrees.com, allows members to uncover the power of their greatest natural resource - the people they know. Inspired by the theory that every person in the world is connected to every other person through a path of no more than six relationships, sixdegrees offers several proprietary applications, all of which help members leverage their own trusted network of contacts. Since its launch in January of 1997, sixdegrees members have been able to make new contacts quickly and easily, gain valuable help and information and communicate directly with their own growing virtual community, all within the confines of the sixdegrees property. As of December 1997, there were over 250,000 sixdegrees members who had listed over 930,000 contacts in the sixdegrees database. --30--cvw/ny* CONTACT: Macroview Communications Corp. Shoshana Zilberberg Director of Marketing & Communciations shoshana(a)sixdegrees.com KEYWORD: NEW YORK INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS COMED INTERACTIVE/MULTIMEDIA/INTERNET PROFILE: YES URL: http://www.sixdegrees.com <http://www.businesswire.com/webbox/bw.120597/550028.htm>

1 0

Re: Clinton's fake apologies (fwd)
by Anonymous 17 Dec '03

17 Dec '03

On 19 Sep 1998, Anonymous wrote: > > nobody(a)remailer.ch wrote: > > > Subject: Re: Clinton's fake apologies (fwd) > > > > > Presumably he should lie to protect the state. > > > > Then don't take the oath: > > > > To tell the truth, the whole truth, and nothing but the truth. > > > ... > > > > So lieing per se isn't the problem. > > > > No, it's the fact that he took an oath to tell the truth and didn't. > > > > > Murky water > > > for impeachment, methinks. > > > > Then you don't think very well. > > > > What? To tell a lie is one thing, but if you preface it with "I'm telling the truth", > then that is really really bad? I still think you're drawing a very fine line. Well, kind of. If some public figure comes up before the nation and says quietly "I did not have sex with Brenda the Barber," that's one thing. If the same public figure goes under oath and then lies, it's another. In the first case, he's exercising freedom of speech, though there could be some argument as to whether somebody in a public office has the right to lie like that. In the second case, he's trying to throw a wrench in the justice system. It wouldn't be as bad if somebody like Jim or I lied under oath, but this guy is the chief executive of the United States. He's basically Top Cop, and his administration doesn't hesitate to press charges against people who commit all sorts of victimless crimes. > I'm honoured to draw an ad hominem before revealing that I'm on AOL. > > -- an anonymous aol32 user. Actually, the amazing thing is that you're from AOL. You're coherent, you quote, and you know how to use a remailer. One in a million. ;)

1 0

Re: Clinton's fake apologies (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > From adam(a)rpini.com Sat Sep 19 16:40:18 1998 > Date: 19 Sep 1998 21:21:26 -0000 > Message-ID: <19980919212126.20210.qmail(a)hades.rpini.com> > From: Anonymous <nobody(a)remailer.ch> > Subject: Re: Clinton's fake apologies (fwd) > > Then don't take the oath: > > > > To tell the truth, the whole truth, and nothing but the truth. > What? To tell a lie is one thing, but if you preface it with "I'm telling the truth", > then that is really really bad? I still think you're drawing a very fine line. Of course it's different if you preface your lie with "I swear to tell the truth, the whole truth, and nothing but the truth". The oath is voluntary and therefore if broken no claim for duress, only intentional misdirection, can explain such actions. ____________________________________________________________________ The seeker is a finder. Ancient Persian Proverb The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0