December 2003 - cypherpunks-legacy

Re: Re: Reformated: How secure....
by privsoft＠ix.netcom.com 17 Dec '03

17 Dec '03

Firstly, I would like to thank Cypherpunks members for helping me evaluate and critique my document on PrivaSoft's security. I would like to address several of the issues raised on list list. 1. Alot of question would be answered if you had a copy of PrivaSoft to look at or at least a scrambled page to examine. Both of these are available at our WEB site (http://www.privasoft.com/privasoft) this is not an advertising plug, it really helps to see the thing in action to better understand its capabilities. 2. Re: the 9 digit key. Partially why you misunderstand the strength of the 9 digit key in PrivaSoft is b/c Graphical Encryption is very different form data encryption. Graphic encryption takes an image of your document and scrambles the tiles accross the page in a pseudo-random order based both on the encryption algorithm and the key used, Each key produces a completely different scramble. Further, descrambling entails moving tiles and recognition of readable text. An edge detection machine would not be helpful with PrivaSoft, as far as I know, OCR or human interface, or the PrivaSoft descrambler( with the correct key) are the only methods that can be employed. And all three of these take considerable time. Time is a key factor here (no pun intended). the strength of an encryption relies heavily on the time it takes to bruteforce check different keys. as such, even the addition of 10 miliseconds to the process is a significant increase in security when taken on the large scale of how many keys need to be checked. 3. The key extension is useful when documents are scrambled using the same default key. This feature adds 2 digits to your key, thus, even the same exact document scrambled with the same key but a different key extension would produce a radically diofferent scramble. 4. With regard to the increased font size, this is not necessary but is helpful in that the tiles themselves would contain less recognisable features of letters. 5. As a fax security product, their is nothing comparable to PrivaSoft in ease of use, strength, verstility. I'm sure you have all recieved faxes that have come in skewed, with heavy line noise, a black line running accros the page, or any other combanaiton of fax problems. These do not effect PrivaSoft's capability to descramble the fax, PrivaSoft has several patented features that produce readable text even after moderate damage to the page. Also, if you haven't figured this out yet, PrivaSoft is the only encryption software that provides Hardcopy encryption and decryption, ie. you can print out a hardcopy of the scrambled image, and fax it, store it, even snail mail it and then on the recieving end, fax or scan it back into the pc and decrypt. 6. re: custimization: This refers to our capability, for corperate clients and the like, to produce batch operation or need specific features. Also we can increase the digits of the key if the client requires such, as in gov't agencies etc, however this is not necesary for day to day use as PrivaSoft is strong enough for most transmissions over the Net and via fax regardless of the prevalent comments by many members of this group. I do not take offence at the many slurs on our product. I fully believe that if any of those who believe that PrivaSoft is a fly-by-night or bogus product have not looked at or tried the software and therfore speak from less than a knowledgable position. Please do not take this the wrong way, I do not mean to insult anyones inteligence or ability, I just mean to say that many here are quick to judge, and they have a right to be suspicious of everything and everyone, that is the nature of security, but I do challenge the naysayers to truly check out the software before completely condeming its use and capabilities. I have personnally demonstrated are software to several key individuals in the gov't, military, and corperate arenas both executive and technical persons. All were impressed have taken the software back for further testing. I have recieved positive responces from them and many have recomended / are presently using PrivaSoft. Once again, thank you for your help in editing and restructurin g the How secure document and i will post an updated version when it is ready. Also, if anyone would like a scrambled page E-mailed to them to look at / try to crack please E-mail me as such, I do not wish to post one only b/c many of you might not want to recieve it. If you have further questions or comments, I do appreciate and encourage them, please feel free to E-mail me at privsoft(a)ix.netcom.com or post them here. Steve O. ************************************************* PrivaSoft TM * 1877 Springfield Ave PO BOX 600 * Maplewood NJ 07040-0600 * Tel. 201-378-8865 Fax. 201-762-3742 * Http://www.privasoft.com/privasoft * E-mail: privsoft(a)ix.netcom.com * *************************************************

4 4

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

Welcome to c|net
by postmaster＠cnet.com 17 Dec '03

17 Dec '03

Your verification was successful! You are now a full-fledged member of c|net online. See you on the Net! ---------------

2 1

Re: Verification of Registration
by Raymond Val 17 Dec '03

17 Dec '03

Lynne L. Harrison writes: > Curious. Did anyone else receive this unsolicitated *invitation*? Everybody who receives mail from cypherpunks(a)toad.com received this message becuase the message was addressed to cypherpunks(a)toad.com. Apparently someone may have joined this 'group' or service and used the cypherpunks address as the e-mail address. Mayhap the cypherpunks(a)toad.com / cypherpunks userid/password. This would be my guess, of course. Does anybody know what this service does? Raymond Val x85849i1(a)cadet1.usma.edu ********************************************************* My opinions are my own and are not the goverments or my schools. ********************************************************* **************************************** Raymond Val x85849i1(a)cadet1.usma.edu ****************************************

2 1

(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

A secure cryptosystem with a 40-bit key?
by Scott Brickner 17 Dec '03

17 Dec '03

I've been reading a bit recently on constructed languages like Esperanto. I came across one that developed out of something called "LOGLAN" that was published in Scientific American in the early sixties. The current active project is called "Lojban". It has one really curious property that gave me an idea for an interesting symmetric-key cryptosystem. All "native" Lojban words are of entirely predictable forms. "Root" words are all five characters containing three consonants and two vowels in one of two patters (CCVCV and CVCCV). "Structure" words have four forms (VV, CV, CVV, and CV'V). "Combining forms" have two forms (CVC and CV'C). All other words are not "native" words (being either proper names or borrowed words). The upshot of this is that there is a fixed limit on the size of the Lojban dictionary of 249500 words (given 17 consonants and five vowels). The grammar of the language is *so* regularized that they are able to give a YACC description for it. A message written entirely using native Lojban words can be encrypted in a codebook fashion where the particular codebook to be used is a permutation of the dictionary represented by an 40-bit number (18 bits to permut the "root word" list, 10 bits for the "structure word" list, and 12 bits for the "combining form" list). This system has the interesting property that *any* plaintext with the same grammatical structure is a potential encryption of a given cyphertext. This is similar to some more usual cryptosystems which operate at the lexical level but which are designed to create this effect, but has the curious side effect that it is *very* easy to determine a false-key which makes the transmitted message say nearly anything you want, thus making mandatory key escrow systems irrelevant. When you want to send the message "attack at dawn", you devise a grammatically identical message, "party 'til you puke" (which is grammatically identical in Lojban), generate a random key, as well as the key representing a similar permutation, but with "attack" and "party" exchanged, "puke" and "morning" exchanged, and so forth. Transmit the message with the false key in the LEAF field (or report it to your government-approved escrow agency) and government eavesdroppers get the wrong message. Other eavesdroppers get a grammatically correct, but apparrently nonsensical message ("drink by brick"). There's still the problem of borrowed words and proper names, which remain problems in any codebook approach, but represents a small portion of the language, and the words which represent individual letters are part of the "structure words" category, and could be sent spelled-out. This works well in Lojban because it never changes word forms based on grammatical usage. Most natural language declensions and conjugations would make the encrypted message ungrammatical, and make it *much* more difficult to determine a false key for the LEAF field. The irregularity of word forms makes the dictionary much more complicated, too. Comments?

3 4

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

MD5 concerns, was Re: Netscape Logic Bomb detailed by IETF
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> channel. I think that Netscape uses an MD5 checksum which the members > of this list seem to place unlimited trust in (incorrectly in my view, This is the second time you've implied that an MD5 checksum might not be as secure as we think. Could you share your thinking on this? I had believed from reading the algorithm that it's not possible to predict how a change in the input will affect the checksum. Given a modified version of netscape for example, how would you change some non-critical portion of the code to get the same checksum that the original should have. I suppose that give n bits of non-critical space in the code, (non-critical meaning that changing them will have no effect on the execution of the code, and assuming that you don't want to change the length of the code), that you could try all possible combinations of those bits, or 2^n trials and see if you get the correct MD5 checksum. If you do, then on average you'd actually only have to try 2^(n-1) trials. What if you don't? What would you do then? MD5 produces a 128 bit output, and it would seem likely that this would be hard. As far as I know there are no known attacks for any MDx algorithms in spite of Ron's worries about MD4. It's a subject of on-going research though, and it is only "conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any messages having a given prespecified target message digest." (RFC 1321) So, if you have newer information, or pointers to any papers, (other than the ben Boer and Bosselaers papers), could you let me know? Thanks, 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

USA Today Against ITAR & GAK
by futplex＠pseudonym.com 17 Dec '03

17 Dec '03

I'm pleased to report that USA Today editorializes today (Tuesday, Oct. 24, 1995) against both ITAR and GAK. They get the chronology of the SSL brute-forcing and PRNG seed prediction attacks on Netscape Navigator backwards, but they get many other things right in a fairly short editorial. I am certainly encouraged by this development. Someone at USA Today definitely got the message that the ITAR are a large obstacle to net security in the U.S. Some particularly apropos quotations (from pg. 12A): On ITAR: "[After the Netscape hacks] the perception of the Internet as insecure was indelible. That needn't be. Encryption software available right now is exponentially more powerful and could make code breaking virtually impossible. Its use is blocked by government export regulations that make the programs difficult if not impossible to market, even for domestic purposes." On GAK: "[...] key escrow [...] may sound reasonable, but apply that reasoning to more mundane areas of life. What the government is saying is yes, you can put bars on your windows, locks on your doors and put your jewelry in a safe, but you have to give us the keys and the combination because you might be a crook." That phrasing sounds rather familiar.... "The [GAK] system -- which the FBI and the Commerce Department declined to defend in an opposing view to this editorial [...]" Now I find that surprising. Since when does the FBI not even try to justify Clipper and its descendants in the newspapers ? For foreign readers, I'll note that USA Today has easily the largest national circulation of any daily newspaper in the U.S. [Letters to the editor can be emailed to usatoday(a)clark.net; they want you to give your snail-mail address and home and work phone numbers so they can check your identity.] -Futplex <futplex(a)pseudonym.com>

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