Cryptography-Digest Digest #376, Volume #12       Mon, 7 Aug 00 22:13:01 EDT

Contents:
  Re: Q: Functions that are slow to invert (Doug Kuhlman)
  Re: Let us have Lattice (wtshaw)
  Re: Special RSA moduli (David A Molnar)
  Re: 2 keys encryption algorithm? (John Savard)
  Re: Cracking RC4-40 in FPGA hardware (David A. Wagner)
  Re: counter as IV? (David A. Wagner)
  Re: Special RSA moduli (David A. Wagner)
  chap authentication scheme? (Bill Unruh)
  Re: Secure Operating Systems (Owen Rees)
  Re: OTP using BBS generator? (Bryan Olson)
  Re: Special RSA moduli (Roger Schlafly)
  IDEA's current security ("David C. Barber")
  Creative Content system, still secure? ("David C. Barber")
  Empathic encryption? (The countdown begins.......)
  Re: Question on security and decription possibilities ("Joseph Ashwood")
  Re: Creative Content system, still secure? ("Joseph Ashwood")
  Re: asymmetric encryption for my keycode generator ("Joseph Ashwood")
  Re: Special RSA moduli (Bob Silverman)
  Re: Special RSA moduli (Bob Silverman)
  Re: OTP using BBS generator? (Benjamin Goldberg)
  Re: Authentication over the internet (MJYoung)

----------------------------------------------------------------------------

From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Q: Functions that are slow to invert
Date: Mon, 07 Aug 2000 15:47:28 -0500

Mok-Kong Shen wrote:
> 
> Are there practically implementable functions that are easy
> to compute but rather expensive (but not comparable to the
> oneway functions) to invert? What is desirable are such that
> the cost factor could be varied to suit one's need by varying,
> say, the size of the function argument. Thanks.
> 
> M. K. Shen

My initial reaction is to use a "broken" system, where the break isn't
completely trivial (i.e. where the DES key is appended to the file). 
Try using ECC with a curve of reasonably smooth order.  Easy to find aP
given a and P and possible (if not trivial) to find a given aP and P.

Doug

------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Let us have Lattice
Date: Mon, 07 Aug 2000 14:39:21 -0600

In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:

> wtshaw wrote:
> > 
> > Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> > >
> > > I conjecture that in one situation concatenation of linear
> > > transformations could be practically useful, namely when these
> > > are applied to different block sizes that are relatively prime.
> > > What do you think? Thanks.
> 
> > 
> > That is an interesting thought, as low primes were disgraced in my recent
> > recursion study.  Already I know that multiple sized stream cipher seeds
> > work to give disproportionate good results.  Since Sinnet demands odd
> > group sizes, are prime odd group sizes meaningful?
> 
> I am yet ignorant of what your 'recursion' and 'Sinnet' exactly
> are. My thought that concatenations of two linear transformations
> could be useful when the block size are different is based on 
> the idea that the result would be a bigger transformation and
> hence better. Evidently, it is most effective to achieve this
> 'bigness' when the two block sizes are relatively prime. So, even
> without knowledge of what you are exactly doing (perhaps you
> would explain that to us in detail later), I would suggest using
> relatively prime sizes (not necessarily prime sizes).
> 
> M. K. Shen

Recursion is running part or all of output data back through as inport
data.  I have posted the details more than one,  the minimal recursion
process I used is s=a+b, a+b=c, a=b, b=c.  Sinnet for groups of three is
recursively x=b+c, y=a+c, z=a+b, then x, y, and z are sustituted according
to keys 1, 2, and 3 to produce a new a, b, and c.
-- 
Free Circus soon to appear in Los Angeles, complete with a
expectation of lots of braying, and noisy clowns in undignified 
costumes performing slight of logic, and, lots of balloons.

------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Special RSA moduli
Date: 7 Aug 2000 21:04:32 GMT

Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>   JCA <[EMAIL PROTECTED]> wrote:
>>
>>     I am looking for discussions on RSA moduli N of the
>> form N= p^r*q, where p, q are odd primes, and r is a
>> positive integer. I am particularly interested in security/
>> speedup tradeoffs for this kind of moduli.

> See the appendix in item #13  of:

> http://www.rsalabs.com/bulletins/index.html

This appendix is an excellent reference for the case of multi-prime RSA
with distinct prime factors. The question makes me wonder if
the original poster had in mind repeated prime factors, however. 
As far as I can tell, the case of a repeated prime factor in an
RSA modulus isn't covered by the appendix. 

The short answer in the repeated prime factor case is "don't do that."

The long answer should begin with a reading of this paper : 

Factoring N=p^rq for large r. 
D. Boneh, G. Durfee, and N. Howgrave-Graham 
CRYPTO '99 , Springer LNCS 1666
http://crypto.stanford.edu/~dabo/abstracts/prq.html

Their algorithm factors numbers of the form p^r q in polynomial time
for r = O(log p). Now, their results are _not_ so directly applicable
to the r = 2 case, so n = p^2 r _might_ be safe, but this needs
further study.  

-David Molnar

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: 2 keys encryption algorithm?
Date: Mon, 07 Aug 2000 21:35:17 GMT

On Mon, 07 Aug 2000 18:41:24 GMT, [EMAIL PROTECTED] wrote, in part:

>Is there a solid 2 keys encryption system out there. What I mean by 2
>keys is the systems requires two keys to encrypt the data and then
>needs only one of the two to decrypt it. An application for such system
>is a conversation recording system where the two parties encrypt the
>system and either of which can hear it later.

>I am not sure whether the concept of public and private keys apply here.

Well, I'm not sure about "requiring" two keys to encrypt, but a simple
technique for what you seem to be discussing is this:

The data is encrypted with a randomly chosen key.

Two copies of that key are attached, each one encrypted with the
secret key of one of the two parties that are to be able to decrypt
the data.

John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: 7 Aug 2000 15:24:24 -0700

Paul Rubin <[EMAIL PROTECTED]> wrote:
> More info: http://www.xilinx.com/products/spartan2/index.htm
> 
> From looking at the specs (and I'm *not* a hardware whiz) it looks to
> me like the FPGA can run RC4 at least as fast as a high-end
> general-purpose CPU (even if not faster), but at much lower cost.
> It's a lot more reasonable to make a board with 50 FPGA's at $10 each,
> than a board with 50 Pentiums and their surrounding support glue.

I haven't looked in detail, but I could believe that.

Certainly -- at the very least -- the numbers in our report are now
out-of-date.  And if, as you suggest, FPGA performance/cost ratios
have been improving more rapidly than general-purpose CPU perf/cost
ratios have, then you'd expect FPGA's to become more attractive than
general-purpose CPU's.

Also, even at the time, we only looked at one family of FPGA's (the
Altera family).  Since writing the report, we've received some information
from others who said other FPGA's were better suited to the task of
RC4-cracking.

So, yes, I agree: our results might be thoroughly obsolete by now.

------------------------------

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: counter as IV?
Date: 7 Aug 2000 15:30:38 -0700

David Hopwood  <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > Sorry for the imprecision.  You are quite right to suggest that using
> > a PRF is just as good.  There is no need for IVs to be truly random;
> > unpredictability suffices.  I apologize for that error.
> 
> They also don't need to be unpredictable, if I understand correctly;
> just uniformly distributed.

No, I don't think that's right.  Consider using a counter, that starts
at a random value, but increments by one each time.  If you sample the
value of the IV at any one point in time, the result is uniformly distributed;
the problem is that successive IV's are not independent (or even close).

Maybe you meant something a little weaker than unpredictability by
stronger than merely uniform at each individual point in time.  If so,
could you elaborate a bit on the property you were thinking of?

------------------------------

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Special RSA moduli
Date: 7 Aug 2000 15:34:30 -0700

Roger Schlafly  <[EMAIL PROTECTED]> wrote:
> > >     I am looking for discussions on RSA moduli N of the
> > > form N= p^r*q, [...]
> 
> As far as anyone knows, a modulus is not easier to factor just
> because it has a repeated factor.

I don't think that's correct.  See
http://crypto.stanford.edu/~dabo/abstracts/prq.html

------------------------------

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: chap authentication scheme?
Date: 7 Aug 2000 23:07:24 GMT


One of the great advantages of the unix password authentication is tht
the attacker cannot figure out the password from the information stored
on the server in any way but brute force. It has the disadvantage that
it requires the cleartext delivery of the password.
The chap ppp authentication goes the other way-- by delivering a hashed
response to a challenge, the attacker cannot figure out the password
from the publically exchanged data. However the passwords need to be
stored in the clear on the server. 

Would the following scheme work to overcome both? (I know srp already
does, but it requires multiple responses which I do not believe fit
within the chap standards.)

The authenticator has a modulus N (prime?) and a generator g. The stuff
stored in the database is
username, salt s, g, N, g^ps modN
The challenge to theuser is 
s,N, g^x modN   where x is a random number
Response is
(g^x modN)^ps modN
which the authenticator can compare with (g^sp modN)^x modN

Does knowing g^x modN  and g^xps modN for multiple (unknown) x help to find ps?

------------------------------

From: [EMAIL PROTECTED] (Owen Rees)
Subject: Re: Secure Operating Systems
Date: Mon, 07 Aug 2000 22:58:01 GMT

On Mon, 07 Aug 2000 04:01:36 GMT, Eric Lee Green <[EMAIL PROTECTED]>
wrote:

>CMan wrote:
>> In 1974 I was working at Honeywell and they were talking about designing a
>> secure multi-user operating system called MULTICS. 
>
>Err, Multics existed already in 1974.

Bell and LaPadula published their "Secure Computer System: Unified
exposition and Multics Interpretation" in 1976, so 1974 sounds right
for when people were working on the idea of a version of Multics with
Multi-Level Security. The systems you can get today with MLS are
mostly Unix-based.

As far as I know, none of the systems with MLS use crypto to enforce
the separation internally, in fact, if you think about it, it does not
make sense to do it that way. If the machine contains the keys it
needs to do the crypto operations, these must be protected by some
other means, and so you already have something else to do the
separation, and don't need the crypto. Cryptography is necessary only
when your bits have to pass through the hands of an unauthorised
party, or may fall into the hands of an unauthorised party (e.g.
comms, or a system that could come under physical control of someone
unauthorised).


-- 
Owen Rees - its just me writing this, see
<http://www.users.waitrose.com/~owenrees/index.html#disclaimer>

------------------------------

From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 07 Aug 2000 23:16:36 GMT

Mok-Kong Shen wrote:
>
> Terry Ritter wrote:
> >
> > I suppose that one of the issues here might be the use of asymptotic
> > proofs of strength, or statistical proofs of strength, to
incorrectly
> > imply strength in every case.  Perhaps a statistical proof can just
> > mean *most* cases, which may mean that some cases which fit under
the
> > guarantee are not really secure.  That would be an interesting
> > definition of "proven strength."
>
> Maybe I am entirely misled by my poor knowledge and low IQ. But
> I have the impression that, excepting OTP, most cases of 'proven
> strength' seem to be just that.

In the sense that it's true, it even applies to the OTP.
Many times on sci.crypt people have objected to the proof of
perfect secrecy for the OTP based on the fact that the zero
vector is one of the possible keys.  The false logic goes
something like: since the OTP is provably secure, and zero
is a legal key, then encrypting with the zero key must be
secure, and since it obviously isn't the proof must be
wrong.

The OTP theorem doesn't say that encrypting with a
particular key will maintain secrecy.  It says choosing a
one-time key uniformly at random and exposing the resulting
ciphertext does not increase the chance of the attacker
determining the plaintext.


--Bryan
--
email: bolson at certicom dot com


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Special RSA moduli
Date: Mon, 07 Aug 2000 16:36:56 -0700

"David A. Wagner" wrote:
> > As far as anyone knows, a modulus is not easier to factor just
> > because it has a repeated factor.
> 
> I don't think that's correct.  See
> http://crypto.stanford.edu/~dabo/abstracts/prq.html

Yes, you are right, if the factor is repeated many times.
But there are cryptosystems based on a modulus of the form p^2 * q,
and these are secure AFAIK.

------------------------------

From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: IDEA's current security
Date: Mon, 7 Aug 2000 17:16:09 -0700

It has been awhile since I've heard the current state of IDEA.  How well is
it holding up in our modern world?

    *David Barber*




------------------------------

From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Creative Content system, still secure?
Date: Mon, 7 Aug 2000 17:21:54 -0700

Creative Content is a system that uses a browser plug-in on PCs and Macs to
display images, but attempts to prevent image downloading or copying.  It
patches system code to stop common screen copy and video buffer dump
attempts among perhaps other avenues.

Has there been any analysis of the security of this approach?  (I would
think that since in order to decode and display an image they have to give
you the lock *and* the keys to inspect at your leisure on your hardware that
it would be hard to make such a system real secure.)

    *David Barber*




------------------------------

From: [EMAIL PROTECTED] (The countdown begins.......)
Subject: Empathic encryption?
Date: Mon, 07 Aug 2000 20:30:31 GMT

May contain proprietary information.  All rights reserved.

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

I had this idea for empathic encryption.  Its based on the principle
of all communication which is basicly two way encrypted traffic of
meaningless (but objectivly structured) data (words/sounds) carrier
followed by a precedent of "telepathic" intent.

Strangly enough a few days after I tryed to think up (I dont do much
on paper anymore... long story) a basic format, a show pops up on tv
with eric estrada.  He gets in a car accident and loses his memory. 
He gets it back later but discovers he's psychic.

Later someone sends him a message on a laptop thats encrypted, but
only he can read it, empathicly.....

That was exactly what I was thinking of.  Anyone else have ideas along
similar lines?

For instance, the reciever would form part of the basis for the
encryption, they, in essence are the key.  Example:  You send a
message to a musician expounding on a proprietary method for
increasing the amount of inorganic elements in a human cell in order
to create a mini power plant who's relevance is in nanotechnology.

But the method is encrypted using music theory terminology and geared
towards the mentality of the reciever (nihilism).  An egghead harvard
grad working for a intel. agency (oxymora) wouldnt know a ta from a
tee tee, let alone a four on one beat.

He cant understand the decrypt because its not in his capacity.  And
if he gets into the musicians head, he risks losing his mind, because
(nihilism) threatens his basic value system.

Whatever that is....

=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2

iQA/AwUBOY8cRE6in12ae3lnEQJsQgCg7Rgfb2sJzBoFxA+CTXHdQUB3Fz4An0Q4
fnqN72o/Em/h8nwxrL2Diyuv
=Qyh2
=====END PGP SIGNATURE=====

Pay for auctions. Send money.  Request money.  Free.
$5 free to join.  $5 for every person you refer
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
https://secure.paypal.com/refer/pal=biu.gung%40writeme.com

------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Question on security and decription possibilities
Date: Mon, 7 Aug 2000 17:28:32 -0700

Well assuming that you mean what I think you mean, which is that the
function you are describing is of the form:
Function(plaintext, key1, key2, key3, key4)
{
    output = plaintext + key1 +key2 -key3 +key4;
}

The answer is rather simple, given 1 known plaintext, you can easily
retrieve the value of key1 +key2 -key3 +key4, which will allow you to map
all values from ciphertext to plaintext, and hence will be completely
broken. Of course if you continually change the keys in some complete true
random way, then you have a One Time Pad of fairly classical construction,
and it is unbreakable. If you vary the keys by some algorithmic method then
you have a stream cipher, and the usual information applies.
                    Joe



------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Creative Content system, still secure?
Date: Mon, 7 Aug 2000 18:08:48 -0700

Please allow me to give you the short and long versions.

The short version:
It does not work, has never worked, will never work, and anybody claiming
otherwise is obviously not educated in the matter.

The long version, specifically how to mount an attack:
run a computer with a slightly altered video driver, that driver instead of
just writing to the screen also enables a screen capture when you press the
pause/break key of your keyboard.
View the picture inside the necessary browsing facility.
press the pause/break key
open you favorite picture editor and remove the screen around the picture.
Congratulations you have created an accurate reproduction of the target
image. Various related attacks apply to ALL attempts at this kind of
security.

                Joe

"David C. Barber" <[EMAIL PROTECTED]> wrote in message
news:8mnk0n$ko5$[EMAIL PROTECTED]...
> Creative Content is a system that uses a browser plug-in on PCs and Macs
to
> display images, but attempts to prevent image downloading or copying.  It
> patches system code to stop common screen copy and video buffer dump
> attempts among perhaps other avenues.
>
> Has there been any analysis of the security of this approach?  (I would
> think that since in order to decode and display an image they have to give
> you the lock *and* the keys to inspect at your leisure on your hardware
that
> it would be hard to make such a system real secure.)
>
>     *David Barber*
>
>
>





------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: asymmetric encryption for my keycode generator
Date: Mon, 7 Aug 2000 18:10:42 -0700

Regardless of the method you choose, the considerations are far broader than
just checking some computation early in the program execution. If you do
that, it doesn't matter what security attempts are made, the crackers will
simply create a patch that changes those instructions to noop and your
security is defeated. What is necessary is to make it so painful for them to
remove the data that they simply give up. For example you could offer
something great if they register, or you could embed a different flavor of
check in every function in your program, but make sure that the checks
actually use the data. Then you'll have something that should be sufficient
to eliminate most attackers, but remember it's only required that 1 attacker
succeed in order to publish the cracked version for the world.
            Joe

"eboy" <[EMAIL PROTECTED]> wrote in message
[snip how do I prevent piracy]



------------------------------

From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Special RSA moduli
Date: Tue, 08 Aug 2000 01:14:02 GMT

In article <8mn890$d2t$[EMAIL PROTECTED]>,
  David A Molnar <[EMAIL PROTECTED]> wrote:
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> >   JCA <[EMAIL PROTECTED]> wrote:
> >>
> >>     I am looking for discussions on RSA moduli N of the
> >> form N= p^r*q, where p, q are odd primes, and r is a
> >> positive integer. I am particularly interested in security/
> >> speedup tradeoffs for this kind of moduli.
>
> > See the appendix in item #13  of:
>
> > http://www.rsalabs.com/bulletins/index.html
>
> This appendix is an excellent reference for the case of multi-prime
RSA
> with distinct prime factors. The question makes me wonder if
> the original poster had in mind repeated prime factors, however.
> As far as I can tell, the case of a repeated prime factor in an
> RSA modulus isn't covered by the appendix.

Huh?  Of course it is.  Factoring  p^2q   with p~q is the same
as factoring pqr with p~q~r.  What matters to ECM is the SIZE of the
factors.  p~q~r  is *slightly* easier because there are 3 primes,
instead of 2, so it is 50% more likely that an EC modulo one of
the primes will be smooth when there are 3.  But 50% increase
doesn't help much. It is only a small constant factor better.

--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Special RSA moduli
Date: Tue, 08 Aug 2000 01:14:15 GMT

In article <8mn890$d2t$[EMAIL PROTECTED]>,
  David A Molnar <[EMAIL PROTECTED]> wrote:
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> >   JCA <[EMAIL PROTECTED]> wrote:
> >>
> >>     I am looking for discussions on RSA moduli N of the
> >> form N= p^r*q, where p, q are odd primes, and r is a
> >> positive integer. I am particularly interested in security/
> >> speedup tradeoffs for this kind of moduli.
>
> > See the appendix in item #13  of:
>
> > http://www.rsalabs.com/bulletins/index.html
>
> This appendix is an excellent reference for the case of multi-prime
RSA
> with distinct prime factors. The question makes me wonder if
> the original poster had in mind repeated prime factors, however.
> As far as I can tell, the case of a repeated prime factor in an
> RSA modulus isn't covered by the appendix.

Huh?  Of course it is.  Factoring  p^2q   with p~q is the same
as factoring pqr with p~q~r.  What matters to ECM is the SIZE of the
factors.  p~q~r  is *slightly* easier because there are 3 primes,
instead of 2, so it is 50% more likely that an EC modulo one of
the primes will be smooth when there are 3.  But 50% increase
doesn't help much. It is only a small constant factor better.

--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Tue, 08 Aug 2000 01:43:46 GMT

Terry Ritter wrote:
[snip]
> 
> From my Cryptologia article:
> 
>    http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4
> 
> 'As an illustration, consider the x^2 mod N system of P = 23, Q = 47
> (N = 1081), a system specifically given as an example "of the
> prescribed form" (p. 378): Starting with x[0] = 46 we get 1035, then
> 1035 repeatedly; a degenerate cycle.  Starting with x[0] = 47, we get
> 47 again; another degenerate cycle.  Starting with x[0] = 48, we get
> 142, 706, 95, 377, 518, 236, 565, 330, 800, and 48; a 10-state cycle.
> And starting with x[0] = 24, we get 576, 990, 714, 645, 921, 737, 507,
> 852, 553, 967, and 24; an 11-state cycle.  Other cycles include
> another 10-state cycle (x[0] = 94), three more 11-state cycles (x[0] =
> 437, 484 and 529), and a couple of much more desirable 110-state
> cycles (x[0] = 2 and 3).'

I think I see...  Perhaps there is some relationship between P and Q we
can test for which will avoid short cycles, which isn't part of the
current parameter choosing process.  I would point out that, in your
particular example, Q = 2P + 1; perhaps this relation is irrelevant, and
short cycles may still hold if it were false, but there might,
nonetheless, be *something* we can test to avoid short cycles without
doing an explicit search.

Also, some of your starting seeds had close relationships to the primes:
Your cycles started with {P+1, 2P, Q, Q+1, 2Q, 19P, 21P+1, 23P} as
values for x[0].  I'm not sure if this is relevant, though.

------------------------------

From: MJYoung <[EMAIL PROTECTED]>
Reply-To: Don't, bother
Subject: Re: Authentication over the internet
Date: Mon, 07 Aug 2000 21:50:09 -0400

If you are only using a Browser, there are many different ways to
authenticate without the use of clinet software. Digital Certificates,
SecureIDs from RSA. Smart cards. I did not say no use of server
software. I work for a PKI vendor, and I'd like to know what other forms
of authentication is out there.

MJY

tomstd wrote:

> MJYoung <[EMAIL PROTECTED]> wrote:
> >Has anyone written a white paper about strong authentication
> over the
> >internet?
> >I'm looking for various ways to authenticate people without
> using any
> >client software.
> >Cost should be minimal and web-based.
>
> Um how do you expect authentication without using a software?
> Ask the user to calculate the product of two 100 digit numbers?
> hmm.. not likely.
>
> At worst you should use a java applet or something.
>
> If you mean cost as in moola, well teach yourself some math and
> you can do it yourself for free.
>
> Web-based?  WTF does that mean?  Wouldn't some web utilization
> device be considered a client application?
>
> Tom
>
> -----------------------------------------------------------
>
> Got questions?  Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com


------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to