- cypherpunks-legacy - lists.cpunks.org

[NOISE] Re: Hack DigiCash: Payee Anonymity
by David E. Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- ObCrypto: Slim to None, peripheral at best. At 07:55 PM 10/24/95 +0100, some annoying nym wrote: >Now all we need is to do is get some specs on how DigiCash's software works >so that we can code this. I expect that this method will become quite >popular. To withdraw DigiCash, one must come up with $250 to start, sign a >bunch of forms, etc. I suspect that most people would rather change money >in lesser amounts, probably under $50. This opens up a huge market for >Blacknet money exchangers. I would gladly pay Tim's Internet Cash Exchange >a commission to exchange $50 worth of greenbacks for Digicash instead of >dealing with Mark Twain and shelling out $250 to start.. Irrelevant point: To open an account as a consumer, not a merchant, and solely for DigiCash use, only $11 (!) is required. Although I'll agree with the bunch of forms part. Damn, I wish I understood legalese... Dave - ----- David E. Smith, "dsmith(a)midwest.net", PGP ID 0x92732139 http://www.midwest.net/scribers/dsmith/ Sorry, the full signature is on strike pending DigiCash salary negotiations -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMI1uAgwyfvCScyE5AQHvpAP+MrQ0vflUe6q7uyXa0PHlyMttf50StEdX eYsXOlN9wLWH9yF6Wkvx8kXQS9sOE7anMYEk42VvwETq3y1EduP3dYAvSW2h7EG2 X4z0wsUT1l3drcq5ieeakA1nwGmHuQdMgPNaPZ8pvIGluTGobKAvta4Ea0MHy8HY YdvbDA4w0x0= =69WP -----END PGP SIGNATURE-----

1 0

Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF]
by Steve Bryan 17 Dec '03

17 Dec '03

Dr. Frederick B. Cohen writes: >In the case of the trust being placed in MD5 by Netscape, the assumption >being made (without adequate support as far as I can tell) is that an >MD5 checksum cannot be forced, through a chosen plaintext attack, to >yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to >allow the known plaintext attack that gets the RSA private key used to >authenticate messages. As far as I am aware (and I may not be aware of >everything) there is no reference work to support this assumption. If >the assumption is wrong, then the whole SSL can fall to a selected >plaintext attack launchable (presumably) through those general purpose >Java aplets we have heard so much about. With a mailing list this large and diverse one can reasonably assume a range of interests and expertise. What I don't understand is your agnostic stance on something as apparently basic as MD5. If computer security is your purported area of expertise why have you not reached any firm conclusions about it? I understand that rigid conclusions are unsafe (eg they'll never prove Fermat's last theorem) but it is not like every question is equally open. Do you have a realistic attack on MD5 or is this sophomoric claptrap? How do you propose to generate messages with specific message digests? Assuming you could somehow, how do you proceed to use that information to your advantage? So let's say I have a message digest and I'm retrieving the allegedly corresponding message which you have the opportunity to alter to your heart's content. How would you proceed, even in principle, to defeat MD5? I realize I might be assuming too much when I posit that I have the true MD5 for the message but my understanding is that you feel that MD5 might be vulnerable. I've given you all the known plaintexts. Is there a next step? +---------------------------------------------------------------------- |Steve Bryan Internet: sbryan(a)gofast.net |Sexton Software CompuServe: 76545,527 |Minneapolis, MN Fax: (612) 929-1799 |PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D E1 8C A6 9B A9 BE 96 CB +----------------------------------------------------------------------

1 0

(fwd) Chaum vs. Stein
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text To: www-buyinfo <www-buyinfo.allegra..att..com(a)mail.checkfree.com> From: Andrew Barrett/CheckFree Corporation <Andrew_Barrett(a)checkfree.com> Date: 24 Oct 95 13:38:40 EDT Subject: Chaum vs. Stein Mime-Version: 1.0 Wanted to save my 'me too' until a time I could piggy-back it onto something a little more pithy (and I DO mean 'little'). Robert, thanks for taking the time and energy for filtering cpx and forwarding the best. David, thanks for providing the forum. Now that _that's_ out of the way ... I've just been handed a registration booklet for The Bank Administration Institute's Retail Delivery '95 conference December 2-6 in Atlanta. Notable speakers include The Bill, MasterCard CEO Eugene Lockhart, Visa International CEO Edmund Jensen, Intuit CEO Scott Cook and Checkfree CEO Pete Kight (among others). Featured on page 6 is a "Fireside Chat: The Financial Marketplace of the Future" moderated by Lou Dobbs... How warm and fuzzy. What really caught my eye was a panel discussion on Internet Security scheduled for that Wednesday. The panelists are David Chaum, Cybercash CEO William Melton, and FV CEO Lee Stein. If anyone goes, tell us all how it went! Kicker - the postal frank is of the "non-profit organization" variety. BIA's site is at http://www.bai.org --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

No Subject
by mixmaster＠obscura.com 17 Dec '03

17 Dec '03

To All, A theme I have been thinking about lately is a virtual data haven using a m from n secret splitting scheme via a DC Net for access and hosting the entire process via HTML and W3. The salient feature would be database objects split in such a way that participating sites would possess no more than 1 encrypted slice of any particular encrypted object. Some redundancy of storage is built into the design and participating site give up local storage to store other slices of the datahaven. At no time is the site hosting able to make correlations of slices to plaintext traffic because the split is done on the users workstation and the placement of the slice on the individual slice on the member datahaven site is accomplished with encrypted remailer tech(probably Mixmaster 2) and CGI or java scripts. The idea here is to be able to store ANY information on the net not just what the local bluenoses approve of. anon

1 0

Elementrix's so-called "Power One Time Pad"
by Flame Remailer 17 Dec '03

17 Dec '03

Essentially what these guys are selling is a secret key algorithm in which the key for any given message is a function of some initial seed value, and of hashes of all previous messages transmitted between the two parties. So in theory, to break the code, one would need to know not only their initial key, but also all of the messages trasmitted between them so far. A similar result can be achieved by encrypting with PCBC, or other feedback mode involving plaintext, and carrying the IV from the end of one session to the beginning of the next. This is not, of course, a one-time pad, and hardly "groundbreaking" or "revolutionary". While such a system could be designed securely in theory, the folks at Elementrix appear to have little experience at designing secure cryptographic systems. Cryptographic systems designed by such novices frequently have bugs in the implementation which weaken the security offered, or have statistical weaknesses which allow cryptanalytic attack. Elementrix has offered no assurances that they have tested their system for either. Beware of snake oil.

1 0

80 bits from 40 bits -- NOT
by baldwin 17 Dec '03

17 Dec '03

Well, let me eat my words. Unless all layers turn on encryption at the same time, and there is not predictable text that passes from one layer to the next, adding encryption at each layer cannot substantially improve the size of the key space. Consider two layers each of which has a verifiable header and a body of encrypted text. By "verifyable", I mean that it contains enough redundancy to recognize a correct decryption of the cipher added by the lower layer. For example, a header that included a content type field and a length field could be examined to see if it looked reasonable, and thus confirm a guess at the lower level's cipher. Plaintext-Body-1 | Layer-1-cipher | Header-1, Encrypted-Body-1 | Layer-2-cipher | Header-2, Encrypted-Body-2 To crack this system, an attacker does brute force search of the keyspace for the layer-2-cipher, for each key check the decrypted Header-1 value to see if it looks OK, if not, continue, otherwise start searching the keyspace for the Layer-1-cipher given the candidate for the Encrypted-Body-1 produced by the guess at the Layer-2-cipher key. Clearly, if you have several layer 2 blocks and they all have good looking values for the Header-1, then the Layer-2-cipher key is correct. The summary is that two layers of 40 bit ciphers with the first layer adding some verifiable information, has the effect of adding at most one bit to the effective keysize (doubling the amount of work). It DOES NOT increase the keysize to 80 bits. --Bob Baldwin ______________________________ Reply Separator _________________________________ Subject: 80 bit security from 40 bit exportable products Author: "baldwin" <baldwin(a)RSA.COM (Robert W. Baldwin)> at INTERNET Date: 10/24/95 10:52 AM Long ago vendors should have put encryption into network layer products, but for a variety of reasons that effort was delayed or discouraged. One effect of this lack is that almost every layer of the network stack is adding its own encryption. For example, the HTTP session layer added S-HTTP and the TCP transport layer added SSL. Soon we will have network layer encryption with IPsec. The vendors for each layer can export a product that uses ciphers with 40 bit keys. A user can then combine multiple products to get more than 40 bits worth of security. For example, a web client might fetch an S-HTTP page over an SSL protected link via a firewall that supports IPsec tunnels. That's three 40 bit keys protecting the data over the internet link (of course, this may not be equivalent to a 120 bit cipher, that depends on the details of the cipher systems and independence of the key setups). Interesting possibilities. --Bob Baldwin

1 0

Hack DigiCash: Payee Anonymity
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

Well, Sameer is offering a "Hack DigiCash" promotion, in the same spirit as the hack Netscape and Microsoft offer. However, Chaum is a fairly experienced cryptographer, and I doubt that there are any major security flaws in the system. The trial version used RSAREF, so that code at least was open for your inspection. There is still the possibility of bugs creeping in when porting to different platforms tho... I think the most interesting hack to pursue is to eliminate the payee-nonanonymity problem. The current software uses the following protocol: The <--(blinding)--- Client Bank --(unblinding)-> Client --> Merchant(non-anonymous) --> deposit in bank The client is anonymous to the bank because of the blinding. What we want is for the client to be able to pay someone money, and have the recipient be able to spend the money anonymously. That is, there must be blinding between the payer and the payee: The <--(blinding)--- payer <--(blinding)--- payee Bank --(unblinding)-> payer --(unblinding)-> payee --> payee spends money The payee generates some digital coins, blinds them, and sends them to the payer. The payer then makes a withdrawl from his bank account, blinds the coins again (or not, it really doesn't matter) and sends them to the bank. The bank signs them, and returns them to the payer. The payer removes his blinding (if any) and sends them to the payee. The payee unblinds the coins and spends them at his leisure. Privacy for all involved.

5 4

Re: [NOISE] Re: Hack DigiCash: Payee Anonymity
by User A. 17 Dec '03

17 Dec '03

Dave sez: : >Now all we need is to do is get some specs on how DigiCash's software works : >so that we can code this. I expect that this method will become quite : >popular. To withdraw DigiCash, one must come up with $250 to start, sign a : >bunch of forms, etc. I suspect that most people would rather change money : >in lesser amounts, probably under $50. This opens up a huge market for : >Blacknet money exchangers. I would gladly pay Tim's Internet Cash Exchange : >a commission to exchange $50 worth of greenbacks for Digicash instead of : >dealing with Mark Twain and shelling out $250 to start.. : Irrelevant point: To open an account as a consumer, not a merchant, and : solely for DigiCash use, only $11 (!) is required. Although I'll agree : with the bunch of forms part. Damn, I wish I understood legalese... Hmm their webpage states clearly: --begin quote-- How Does This All Work? There are two essential components to this test of the Ecash system. Both are necessary to make this work. 1.You must open a WorldCurrency Access(tm) account with Mark Twain Bank (USA). This is a traditional banking account where you can choose between 25 different currencies for your deposits. 2.You will obtain and install the Ecash software by DigiCash. This is subject to a separat license agreement. In conjunction with your banking account from Mark Twain Bank, you can now move money to your own hard drive from the Ecash Mint, for spending when you choose. --end quote-- Now, to open an WorldCurrency Access(tm) account you have to deposit $2500, if the account balance falls below $250 you need to pay a $10 fee. I surely hope that someone could shed some light on this. -AJ-

1 0

Re: textbooks
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > The quick proof of why the initial and final permutations add nothing to > > the security of DES is presented in an informal and quite obvious sidebar. > > Actually, I found the proof not completely convincing. It's really a > proof that it doesn't strengthen the DES against a *known plaintext* > attack, but there are other weaker attacks it may make marginally more > difficult (or easier..); for instance, partially-known plaintext or > some forms of verifiable plaintext. > I'm afraid I'm not quite following you here, could you expound a bit? Ah:) Isn't it great to be talking about encryptions again?:) Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

re: Remailer-in-a-Box, Everyone a Remailer
by P.J. Ponder 17 Dec '03

17 Dec '03

I think someone claiming to be Jay Campbell wrote: >Rather, a single physical machine site can and should be able to run many >remailers, out of user accounts. (Accounts on systems like Sameer's C2. Or >Hal's remailer running on Portal. Or maybe some of the Mixmaster clients.) >This also brings up the idea of 'opportunistic remailers' again (somebody >gimme a snazzy name for that) - a PC/Mac-based SMTPish server that isn't how about pop-ups? This has a real future, I think. It would be easy enough to leave one's pc logged in for a while (maybe even earn a little ebread with it?) and forward some mail around, after checking with the server to see if there were any new messages for the cypherpunks password screen saver or any anon posts to be remailed. -- pj p.s. seems like the list is gettign a little hard-edged as TCMay pointed out recently. Everybody jumping on everyone else, and on their products, too. I want secure and powerful tools, too. But it seems liek a feeding frenzy. And as soon as someone posts on something a little askew, right back come the replies to cut the shit and get back on the topic. I say lighten up. <EOF>

1 0