Re: names to say in late september

How about RISHAD? It's pronounceable, captures all three inventors in the same order and equal proportions, and is already a name, with relevant connotations. The similar "Rashad" is listed as meaning "integrity of conduct", which seems particularly appropriate.

Re: names to say in late september -- Rishad?

About "Rishad", someone privately wrote: > ... naming an algorithm designed by three jewish guys after > an arabic word doesn't actually seem right to me... Ha! I thought about that ... for a minute or so. But great ideas like RSA must rise above irrelevant cultural boundaries. But now that y

Re: Non-Repudiation in the Digital Environment (was Re: First Monday August 2000)

"Anti-repudiation" sounds good to me. ... even if does remind me of "antidisestablishmentarianism". Come to think of it, now even that term sounds appropriate here -- as our belief in the value of methods that deter key "dis-establishment". Pretty scary. -- dpj At 09:08 AM 10/11/00 -0400, Arnol

Re: Update on the CW

Andrew, At 06:16 PM 12/25/98 -0500, you wrote: >It's been about 8 months since I did any reading on the state of >cryptography. I have two questions. Any info is appreciated. > >1. Anybody heard anything bad about MD5 or Diffie-Hellman? Ask Dobbertin about MD5. You might want to use SHA1 instea

Re: MD5

Andrew Maslar asked: >I'm toying around with various protocols for key exchange, and I wonder, >if an attacker intercepted the result of the following operation: >md5(x) + md5(x + y + z) >Could s/he compute y? [knowing x and z] At 10:57 PM 12/27/98 -0800, Bill Stewart wrote: >If y is a wimpy pass

Re: Strengthening the Passphrase Model

At 01:03 AM 3/18/99 GMT, Ian Goldberg wrote: > In article , > Arnold G. Reinhold <[EMAIL PROTECTED]> wrote: 2. PGP should burn computer time hashing the passphrase. While you cannot increase the entropy of a passphrase with an algorithm, ... But, y

Re: ICSA certifies weak crypto as secure

is selling cryptographic >products has a good story for why the holes in their product really do not >matter. Make sure the system you deploy is reviewed by independent experts. I'm also amused that the one place where you slipped up a tiny bit is in your own "sales pitch" for diceware. A curious thing. :-) Best regards, David Jablon [EMAIL PROTECTED] www.IntegritySciences.com

ZK password proofs [Re: ICSA certifies weak crypto as secure]

As ??? correctly wrote: >>You can't use a hashed password for challenge/response, >>The fundamental problem is that users pick bad passwords and passphrases ... Bill Stewart responded: >Yup. I like S/Key better than the annoying Se[***]ID card I use to >log in to work, or public-key challen

Re: Could Open Source Software Help Prevent Sabotage? (fwd)

At 02:59 AM 6/22/99, Peter Gutmann wrote: >Zombie Cow <[EMAIL PROTECTED]> writes: >>http://linuxtoday.com/stories/6876.html >> >>Could Open Source Software Help Prevent Sabotage? >> >>Imagine a Chinese agent working at Microsoft. How difficult do you think it >>would be to insert a little "backdoo

Re: Bridge

s. Even with random systems, life can be unfair. -- dpj --- David Jablon [EMAIL PROTECTED] www.IntegritySciences.com

Re: Proposed bill for tax credit to develop encryption with covert access

At 05:44 PM 8/2/99 -0400, Radia Perlman - Boston Center for Networking wrote: >http://thomas.loc.gov/cgi-bin/bdquery/z?d106:h.r.02617: > >I'm sure you'll all be enthusiastic about the chance to save your >company tax money. Amazing! Despite the title, this seems to be a retro-active tax break fo

Re: Ecash without a mint

A slight correction is noted, which isn't very relevant to the ZK proofs in the proposed payment system. At 11:41 AM 9/20/99 -0700, bram wrote: > Interactive ZK proofs can be made non-interactive by generating an > encoding of the information offered by the prover, and using the bits of > the sec

RE: Is SSL dead? (was Re: ECARM NEWS for October 06,1999 Second Ed.)

At 07:35 PM 10/6/99 -0400, Phillip Hallam-Baker wrote: >This is a problem with SSL 2.0 first discovered by Simon Spero then at >EIT. >It was fixed in SSL 3.0, that must be almost three years ago. That's not the big issue here. Server-spoofing is not fully prevented by any version of SSL. The pr

Re: Smartcard anonymity patents

At 10:44 PM 2/24/00 +, Ben Laurie wrote: >lcs Mixmaster Remailer wrote: >> What are the prospects for smartcard based systems within the U.S.? Such >> cards are essentially nonexistent in commerce. Apparently in Europe and >> Asia they are widely used, though, instead of the credit cards pre

Re: Perfect Forward Security def wanted

I recall a P1363 meeting which discussed the issue of confusion over multiple interpretations (or misinterpretations) of "perfect forward secrecy". I and others suggested dropping the word "perfect" for the reason you discuss. PFS was defined in

Re: Automatic passphrase generation

For all those interested in EKE, A-EKE, and related methods, the next P1363 meeting (May 31, Boston) will discuss the creation of a new standard for Password-based Authenticated Key Exchange. The P1363 home page is . The joint kick-off document for this effort

Re: NSA back doors in encryption products

At 03:48 PM 5/23/00 -0700, John Gilmore wrote: >... I have a well-founded rumor that a major Silicon Valley company was >approached by NSA in the '90s with a proposal to insert a deliberate >security bug into their products. They declined when they realized >that an allegation of the bug NSA want

Multi-server Password Authentication

A recent announcement by Verisign describes a system for strong network password authentication, with the added twist of using two or more servers, such that no individual server keeps any crackable password verifiers. The basic idea seems to be a key-splitting trick, such that when using N serve

Re: Multi-server Password Authentication

At 04:58 PM 6/12/00 -0500, Rick Smith wrote: > ... They [Verisign] haven't figured out how to embed it in a > product yet. Without more information it's impossible for me to tell if > they've actually constructed something useful. I'd be surprised if they didn't have some kind of product figured

Re: random seed

About NT CryptGenRandom ... I once noticed a curious thing that made me question it's robustness. The generated numbers on NT were always the same for the same registry settings of RandSeed. This implied that all other seed material was static on that system. In normal cases, RandSeed changes

Re: Weak user keys, strong servers.

This is a solved problem, under slightly different assumptions. At 07:34 AM 7/20/00 -0700, James A. Donald wrote: > -- >Weak user keys. > >Suppose the user's key p, may be weak and easily guessed from G^p > >Suppose the key server constructs for each user a strong supplementary >key, q. whic

Re: Weak user keys, strong servers.

James, The approach of splitting the key into low and high entropy parts is obvious, but you're solution is probably not obvious to very many people. At least it wasn't to me. Can you elaborate on the points below? At 09:50 PM 7/21/00 -0700, James A. Donald wrote: >On reflection, the obvious so

Re: Weak user keys, strong servers.

At 09:48 AM 7/23/00 -0700, James A. Donald wrote: ... > > > The public key is G^(p+q). > > > The secret key is p+q, and the user never seeks to find out q. > > > The server establishes the user's identity by verifying that he > > > knows p corresponding to the shared secret G^p. It then, on a > >