authentication protocols
Hi I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Most of the stuff in _Applied_Crypto_ requires that third party. It may be an impossible task, nothing seems obvious to me. Pointers, suggestions, or aphorisms all welcome. -- \js innovate scalable infomediaries - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ciphersaber-2 human memorable test vectors
A while ago I wrote some code to search for human readable test vectors for Arnold Reinhold's ciphersaber-2 (http://ciphersaber.gurus.com). Ciphersaber-2 is designed to be simple enough to be implemented from memory, to avoid the risk of being caught with crypto software on your computer for use in regimes which have outlawed encryption. But the only available test vectors are a big string of hex digits which probably the implementor will find difficult to remember, and it is quite easy to make implementation mistakes implementing ciphers -- and the risks of accidentally using a incorrectly implemented and weak variant of ciphersaber-2 are significant. It would be useful therefore for the stated purpose of ciphersaber-2 to have human readable and memorable test vectors. The software for exploring for human readable test vector phrases and information on using it is here: http://www.cypherspace.org/adam/csvec/ I have not myself spent much time looking for satisfyingly witty, topical and memorable phrases. I'll appoint Arnold as the judge and let you the reader see what you can come up with using the software. The winning test-vector phrases will go on that page. Perhaps Arnold will make some honorary 2nd level Cipher Knighthood and certificate for producing the coolest phrase which is also a ciphersaber-2 test vector. By way of example the following is a ciphertext plaintext pair: % csvec -c2 db 3 4 3 5 3 spook.lines selected 155 words of length [3-5] k=AMME,iv=spy fraud : bce DES which is interpreted as: ciphertext = spy fraud DES plaintext = bce key = AMME (the iv is prepended to the ciphertext) and can be checked as: % echo -n spy fraud DES | cs2.pl -d -k=AMME bce and so on. Anton Stiglic and I were also thinking that there would be other ciphers which you could make human memorable test vectors for. For example DES and other 64-bit block ciphers seem plausible though the searching would be slower as the plaintext would have to be 8 chars which are slower due to the rate of the English language. Anton had a number of ideas about how you could make test vectors for other ciphers like SHA using a partial hash collision as the validity test as computing a full collision would be impossibly expensive. In general purely human readable test vectors are not ideal as they are 7 bit, and there have been cases where implementation errors or related to the 7th bit (for example one blowfish implementation had problems with signd / unsigned chars), but it is kind of an interesting though experiment. Also if done by the cipher designer, he may choose any magic constants for the cipher / hash function specifically to allow an human memorable test vector, though this may weaken the usual kosherized random number or generators and use of constants such as PI to assure the reader that there is no ulterior motives for the vectors. I suppose the general approach of trying lots of human readable strings for one which has a desired property also calls into slight doubt the use of purely text phrases as a kosherizing method (eg magic constants are repeated SHA1 hash of some phrase) -- if in fact the algorithm designers could try lots of phrases to arrive at a subtly weakened set of magic numbers. Adam -- http://www.cypherspace.org/adam/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
One for the snakeoil file.
[Note: I'm just passing on posts from sci.crypt. I've not confirmed this independently It appears that not every product which uses smart cards is secure - pt] From: [EMAIL PROTECTED] (Philippe Mestral) Newsgroups: sci.crypt Subject: I've tested the encryption system that comes with Acer laptops, and it's not pretty. Date: 26 Mar 2002 05:48:36 -0800 Message-ID: [EMAIL PROTECTED] Some Acer laptops comes with a built-in smartcard reader and a file encryption program called Platinum Secure. My company recently acquired two of them. I spent some time playing around with that encryption system and came to the following conclusions: - they use a basic XOR stream cipher. - the keystream is always the same for any file, encrypted by any user on any of the two laptops I have. - I was able to generate that keystream with a long enough binary file containing only 0 and encrypting it. - I am now able to decrypt any file encrypted on either laptop without the smartcard. I am no crypto expert. It is surprising to me that a manufacturer would release such a badly designed product. It's even worse that providing no security at all, because with this product the users *think* their files are secure while they obviously aren't. any thoughts/comments? also, has anyone here already had this product in their hands? could someone who has installed that program possibly create a text file, put the string test in it, encrypt the file and send it to me at [EMAIL PROTECTED] so that I can see whether the encrypted file looks like mine or not? (they wouldn't use the same keystream for ALL their laptops would they?) thanks in advance. -- From: Scott Fluhrer [EMAIL PROTECTED] Date: Tue, 26 Mar 2002 07:33:28 -0800 Message-ID: a7q4ni$r77$[EMAIL PROTECTED] Joël Bourquard [EMAIL PROTECTED] wrote in message news:3ca091af$[EMAIL PROTECTED]... Philippe Mestral [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Some Acer laptops comes with a built-in smartcard reader and a file encryption program called Platinum Secure. [...] - they use a basic XOR stream cipher. - the keystream is always the same for any file, encrypted by any user on any of the two laptops I have. [...] - I am now able to decrypt any file encrypted on either laptop without the smartcard. Hi, I'm completely astonished by what you said. What I can't understand, is why they're using a smartcard.. unless they want people to BELIEVE that's secure. Well, the keystreams might be different for different smartcards (not that that would make it any more secure). Alternatively, they might put the keystream generation program on the smartcard, in the vain hope that if people can't look at it, they have a harder time cryptanalyzing it. -- poncho -- From: Philippe Mestral [EMAIL PROTECTED] References: [EMAIL PROTECTED] 3ca091af$[EMAIL PROTECTED] a7q4ni$r77$[EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tue, 26 Mar 2002 18:48:49 +0100 Well, the keystreams might be different for different smartcards (not that that would make it any more secure). Alternatively, they might put the keystream generation program on the smartcard, in the vain hope that if people can't look at it, they have a harder time cryptanalyzing it. Oh yes, I assumed he did use two different smartcards with the two laptops.. and that the keys were the same. Maybe he didn't. I did. - From: Philippe Mestral [EMAIL PROTECTED] Date: Tue, 26 Mar 2002 19:19:28 +0100 Message-ID: 3ca0ba42$0$24006$[EMAIL PROTECTED] Joël Bourquard [EMAIL PROTECTED] wrote in message news:3ca091af$[EMAIL PROTECTED]... Hi, I'm completely astonished by what you said. What I can't understand, is why they're using a smartcard.. unless they want people to BELIEVE that's secure. apparently the card is used to store a unique ID which authenticates the card owner. As several card owners can use the same pc and the encrypting method and key are always the same, they had to find some sort of way to tell what file was encrypted by what user. A registry key contains information regarding encrypted files. For each encrypted file, a string is added to the registry. Its name is the current date concatenated to the encrypted file name, and its value corresponds to the unique ID of the user who encrypted the file (plus the original file extension, go figure). When a request to decrypt an encrypted file is made, the program browses the list of encrypted files in the registry. If it founds a file whose date time and name correpond, it then checks that the user who encrypted that file corresponds to the one whose card is inserted in the reader. If it does, the file is decrypted. Incidentally, modifying the date and/or name of an encrypted file
Re: 40 teraflops (fwd)
Unfortunately, the article that Bob Hettinga excerpted from the South China Morning Post is a pay-only article. http://www.es.jamstec.go.jp/ - Japanese government site. http://www.es.jamstec.go.jp/esc/eng/ - Good page http://www.es.jamstec.go.jp/esrdc/eng/menu.html - The ES center http://www.es.jamstec.go.jp/esc/gallary/index_e.html - Pictures. (This sucker appears to be *big*. Some pictures want Flash.) Here are a couple of articles from 2000 about how cool the machine will be: http://www.nec.co.jp/press/en/0005/3001.html - NEC press release http://www.ess.nec.de/hpc/HPCwire/17830.htm - Some technical detail Cool lecture by Jack Dongarra (a name you should know) overview of high-performance computing. Spring 2002 CS594 UTenn. http://www.cs.utk.edu/~dongarra/WEB-PAGES/SPRING-2002/lect01.pdf Most Important Slide is the pointer to http://www.netlib.org The other reference site for this stuff: http://www.top500.org Article about Google doing work on parallel projects http://www.cosmiverse.com/tech03250202.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 1024-bit RSA keys in danger of compromise
At 05:38 PM 03/23/2002 -0800, Lucky Green wrote: While the latter doesn't warrant comment, one question to ask spokespersons pitching the former is what key size is the majority of your customers using with your security product? Having worked in this industry for over a decade, I can state without qualification that anybody other than perhaps some of the HSM vendors would be misinformed if they claimed that the majority - or even a sizable minority - of their customers have deployed key sizes larger than 1024-bits through their organization. Which is not surprising, since many vendor offerings fail to support larger keys. While SSL implementations are mostly 1024 bits these days, aren't PGP Diffie-Hellman keys usually 1536 bits? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
distributed.net looking for a new ISP.
Distributed.net, which has won several of the RSA Secret Key challenges, and is currently 73% of the way through the RC5-64 contest, has lost it's ISP. Peter Trei From their front page: - start quote We need your help! URGENT: We have recently learned that our long-standing arrangement with Texas.Net (formerly Insync) would end at noon, Friday, March 22. Through an agreement with Insync, we were hosted at no charge for many years. Though we have tried to make other arrangements with them or to continue our current service until we can make other arrangements, in the end we had no choice but to move. Several of the Austin cows made a road trip Friday morning to retrieve our equipment from their colocation facility. We have no reason to complain about Texas.Net or their current decision. As a business, they chose to donate to us for a long time, and have now decided that they must stop. In dbaker's words in a letter to Texas.Net: Our experience with Insync has been excellent; I've never been happier with an Internet provider. I've recommended them (and indirectly, Texas.Net) to everyone and even this [situation] won't change that. Though United Devices has kindly offered to colocate our primary servers for a short time at no expense, we find ourselves in the market for a new ISP. If any of our participants work for a major ISP in Texas (preferably within a few hours of Austin, but we're not picky), and would be willing to donate colocation space and connectivity, we would eagerly like to speak with you. Our typical bandwidth usage is 3Mb/s, and reliable uptime is of course essential. Please e-mail [EMAIL PROTECTED] if you think you may be able to help us in this area. - end quote - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 1024-bit RSA keys in danger of compromise
Here's the distribution of RSA key sizes in SSL servers, as recorded by my SSL server survey in June 2000 and June 2001 RSA Server Key size Key bits2000 2001 2048 .2% .2% 1024 70% 80% = 1000 2% .7% = 768 2% 1% 512 - 0% = 512 25% 17% Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
