Cryptography-Digest Digest #890, Volume #12      Tue, 10 Oct 00 15:13:01 EDT

Contents:
  Re: A new paper claiming P=NP ([EMAIL PROTECTED])
  Re: SDMI - Answers to Major Questions (Dido Sevilla)
  Re: A new paper claiming P=NP ("Trevor L. Jackson, III")
  Re: Rijndael implementations ("Brian Gladman")
  Re: FTL Computation ("Paul Lutus")
  Re: FTL Computation ("Paul Lutus")
  Re: MITM attack (Dido Sevilla)
  Re: Error-correcting code ? (Mike Rosing)
  Re: Developer courses in PKI? (Mike Rosing)
  Time complexity -vs- the Real World [was: Re: A new paper claiming P=NP] (Ariel 
Scolnicov)
  Re: WEP ("madcow")
  Re: What is meant by non-Linear... (Tom St Denis)
  Re: Quantized ElGamal (Tom St Denis)
  Re: Need help: considerations for IV and Keysetup ("Joseph Ashwood")
  Re: A new paper claiming P=NP (Jeffrey Williams)
  Re: Looking for paper ("Joseph Ashwood")
  Re: securely returning password info to a server from a client (Eric Lee Green)
  Does Rijndael look Linear or is it just me? (Albert Yang)

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

From: [EMAIL PROTECTED]
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: 10 Oct 2000 16:39:06 GMT

In comp.theory David C. Ullrich <[EMAIL PROTECTED]> wrote:

>       I've seen plenty of actual real-life examples of this
> phenomenon. Probably not with numbers as extreme as
> 100000000 versus 2, but I've seen plenty of programmers
> ask online questions about why doesn't the following work
> for large strings - it works for small strings just fine.

I've often seen O(nlogn) algorithms beat O(n), or O(n^2) beat
O(n^lg(3)), but it would be extremely rare for an O(n^2) algorithm to
beat an O(n) algorithm on moderately large inputs (say, n>=10,000).

  ..... [ some deleted ] .....

> def ReplaceAll1(data: string):
> begin
>   result = CopyOf(data)
>   index = Pos(result, '&') //returns 0 if not found, say
>   while index > 0:
>     data[index] = '+'
>     index = Pos(result, '&')
>   return result
> end

> def ReplaceAll2(data: string):
> begin
>   result:= ''
>   for j:=1 to Length(data):
>     if data[j] = '&' then result:= result + '+'
>     else result = result + data[j]
>   return result
> end

>       Now (assuming a uniform distribution of characters
> in the input) ReplaceAll1 is O(n^2) while ReplaceAll2 is O(n).
> Depending on quirks of the implementation it could well be
> that ReplaceAll1 is nonetheless much faster for small n - there
> are just n/256 function calls and n/256 loop iterations, while
> ReplaceAll2 has n loop iterations.

You have to know when asymptotic analysis makes sense and when it
doesn't.  If you're dealing with strings of 100 or 200 characters,
then it's pretty pointless to talk about O(n) vs. O(n^2) in that
case.  If you're talking about strings with 10,000 or more characters,
than it is very relevant (and I bet that ReplaceAll2 will beat the
pants off ReplaceAll1 for large strings like that).

-- 
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences       | "The box said 'Requires Windows 95, NT, 
University of North Texas        |  or better,' so I installed Linux."
Denton, TX  76201                | 

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

From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: SDMI - Answers to Major Questions
Date: Wed, 11 Oct 2000 01:06:06 +0800


The main problem with SDMI is that it uses cryptography to do something
it wasn't designed to do.  They believe cryptography will give them
absolute control over their information.  It doesn't and it can't. 
Cryptography provides us with a means of controlling information, but
only provides as much control as the intended recipients of the
information want to give us.  What the RIAA doesn't realize is that
their intended recipients--the music-listening community--don't want to
give them the level of control they want to have.  Information wants to
be free, or to put it another way, people want information to be free. 
Well, I don't see how there can be a technological solution for this,
because it requires a trusted client...

--
Rafael R. Sevilla <[EMAIL PROTECTED]>         +63 (2)   4342217
ICSM-F Development Team, UP Diliman             +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481

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

Date: Tue, 10 Oct 2000 13:18:39 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP

Mark William Hopkins wrote:

> In article <[EMAIL PROTECTED]> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> 
>writes:
> >Mark William Hopkins wrote:
> >> Therefore, it should be fairly easy to spot the flaw in the paper.  No
> >> demo programs are needed.
> >
> >Hmmm.  Assuming the conclusion.  Useful technique that.  ;-)
>
> No, actually it's: asserting the 'conclusion' and refuting the assumption.

No.

The argument I commented on assumed that P!=NP.  Read it again.

>
> This is, of course, a valid form of argumentation when the assertion is
> true.

No.

Such assumptions are not a valid form of argumentation.  *And*, the truth value of such
assumptions has even less bearing on the validity of the argument.  The only useful 
purpose
assumptions regarding conclusion can have is as a basis for showing contradiction, 
which is
useful only when the assumption is *not* true.

A *true* assumption that leads to a contradiction leads the the conclusion that the 
proof is
flawed, and thus is not useful.

>  Very few people believe that it's false and that P = NP.

What people believe has nothing to do with the truth value of the proposition.  Using 
people's
beliefs, rare or widespread, to bolster support for an attack is not a valid form of
argumentation under any rational form of discourse.  Beliefs are opinions held in the 
absence of
proof.  Thus they cannot play any role in a proof.




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

From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Tue, 10 Oct 2000 18:35:11 +0100

"lcs Mixmaster Remailer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is the intellectual property status of the Rijndael
> implementations at the NIST web site?
>
> http://csrc.nist.gov/encryption/aes/round2/r2algs-code.html#Rijndael
>
> It is known that the algorithm itself is public domain, but what about
> the implementations (a separate issue)?  Is this source code free for
> commercial use?
>
> Names appearing on the C implementations include Paulo Barreto, Antoon
> Bosselaers & Vincent Rijmen.  There is no IP statement in the source
> files; no claim of copyright, no explicit release to the public domain.
>
> Rijmen is of course one of the creators of Rijndael, and his staements
> may have publicly disclaimed his rights, but what about the others?

You might also like to look at:

http://www.btinternet.com/~brian.gladman/cryptography_technology/rijndael/in
dex.html

where I have just updated my own implementation (in C++).   On the 200MHz
Intel reference platform it offers around 70Mbits/second using large tables
but other options are provided as well.

    Brian Gladman




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

From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Tue, 10 Oct 2000 17:43:58 GMT

David C. Ullrich <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 09 Oct 2000 18:02:40 GMT, "Paul Lutus" <[EMAIL PROTECTED]>
> wrote:
>
> ><[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >
> >> > > If the projection of a spot of light can virtually move FTL
> >> > > then so too can the projected images of a slide rule's slides.
> >> > > The computation 'in effect', takes place FTL.
> >> >
> >> > Not "in effect," not at all. The projection of the light does not
move
> >at
> >> > FTL, not virtually, not really, not at all.
> >>
> >> It does move FTL.
> >
> >Now we have to imitate Bill Clinton and say exactly what we mean by "it."
>
> I've hesitated to ask. But I wonder if anyone can say exactly
> what "faster than light computation" _is_. The speed of light is
> measured in units like meters per second. I don't see how to
> measure the speed of a _computation_ in meters per second...

It is a liberal mixing of terms, but without real physical meaning. If you
establish a rate of computation, say, 1000 operations per second just as a
hypothetical example, based on physical limitations ultimately based on
speed-of-light communications, then you might be able to claim FTL if some
arrangement produced 2000 operations per second as a result of the
exploitation of some physical effect that sped up communication. I am saying
you might make the claim, not that it is true.

That is how it is a mixing of terms. But it can get worse -- the OP made an
argument that relied on smoke, not physics. In a manner of speaking he said
that, if he transmitted the word "dictionary," and if the receiver knew how
to translate that token into an actual dictionary, the result would exceed
the original communication channel's capacity, therefore presto -- FTL!

But none of these examples violates the rule that information may not be
transmitted FTL.

--

Paul Lutus
www.arachnoid.com





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

From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Tue, 10 Oct 2000 10:46:27 -0700

ca314159 <[EMAIL PROTECTED]> wrote in message
news:8rvd97$7io$[EMAIL PROTECTED]...

>    Whether you call this effect lighthouse, waterhose, headlight
>    or scissors... it can be used to do very interesting things.
>    I don't just think so, I know so.

"Interesting" does not equal FTL. That is our topic. You claimed FTL. Here
is what you said:

> If the projection of a spot of light can virtually move FTL
> then so too can the projected images of a slide rule's slides.
> The computation 'in effect', takes place FTL.

This is false. The computation does not in effect take place FTL.

--

Paul Lutus
www.arachnoid.com





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

From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: MITM attack
Date: Wed, 11 Oct 2000 01:43:32 +0800

[EMAIL PROTECTED] wrote:
> 
> Excuse me for the ignorance but could you explain what MITM is?
> 

MITM = Man In The Middle.  It's a network attack in a client-server
system where the attacker pretends to be the server to the client, and
pretends to be the client to the server.  Subtle modifications in
network traffic done this way can have disastrous results...

--
Rafael R. Sevilla <[EMAIL PROTECTED]>         +63 (2)   4342217
ICSM-F Development Team, UP Diliman             +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Error-correcting code ?
Date: Tue, 10 Oct 2000 12:50:58 -0500

[EMAIL PROTECTED] wrote:
> correct the wrong error. I put the check digits after the data; is there
> any advantage to interspersing them in the data digits ?

It depends on your transmission system.  If you lose data due to
fading (as in cell phones) then interspersing is a good idea.  If
people routinely switch digits at some point, then putting the
check digits near that point may help.  If there's any pattern at
all to the errors, then putting the check digits near that pattern
might help too.  The disadvantage is that the check digits are
then susceptable to the same errors.

Patience, persistence, truth,
Dr. mike

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Developer courses in PKI?
Date: Tue, 10 Oct 2000 13:04:28 -0500

[EMAIL PROTECTED] wrote:
> 
> I'm looking into developing my product such that it fits into
> a PKI infrastructure properly.  Obviously, I would like to take
> some courses since I've never even worked with PKI before in
> my life.  I only have a vague notion of certificates and would
> like to learn exactly what this is, with the help of a real-
> life teacher, not a book.
> 
> Does anyone have any suggestions for courses (preferably in
> the Bay Area, or Hawaii :-) ) from companies that would teach
> PKI courses from the perspective of programmers, and NOT
> certificate server admins?

check out www.certicom.com.  They keep sending me ads for their
courses, and I think one was in the bay area.

Patience, persistence, truth,
Dr. mike

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

From: Ariel Scolnicov <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Time complexity -vs- the Real World [was: Re: A new paper claiming P=NP]
Date: 10 Oct 2000 19:10:26 +0200

[EMAIL PROTECTED] (David C. Ullrich) writes:

> On 9 Oct 2000 19:58:57 GMT, [EMAIL PROTECTED] (Jeremy Spinrad)
> wrote:
> 
> >Some people are claiming that big O analyses do not do a good job of
> >reflecting behavior of programs. Although I know of examples of this (e.g.
> >simplex outperforms its worst case analysis in practice), I am
> >curious as to whether saying this is common is at all justified. It certainly
> >goes against my intuition that there are lots of programs out there such
> >that the O(n^2) algorithm is beating up on the O(n) algorithm on inputs
> >of large enough size so that time is a factor, as one poster implied.
> 
>       I didn't _imply_ that, I _stated_ it. When someone talks
> about O(this) and O(that) there's an unspecified constant. Does
> it go against your intuition to imagine two algorithms to solve
> the same problem, one of which takes on average time
> 100000000*n for input of size n while the other takes on
> average time 2*n^2 for the same input? The first is O(n) and
> the second is O(n^2) but the first is much faster until n gets
> very large.

[... "language builtins" example snipped ...]

Even when you're using a "nice" language which gives you the time
complexities you're used to, the "better" algorithm can be the
"slower".  A nice example is Union-Find.  The Tarjan path-compression
algorithm is really really good, possessing a complexity of O(n
beta(n)), when beta(.) grows slower than all inverses of Ack(k,.).
This is for _any_ sequence of n operations (unions and finds).

Of course, many applications don't do "any" sequence of n operations,
they do particular sequences.  In particular, I saw an application
speeded up fairly dramatically by replacing the Tarjan algorithm with
a "dumb" O(n log n) algorithm.  It just happened that the dumb
algorithm had fast constant-time lookups, the Tarjan had much slower
lookups (due to the extra bookkeeping), and there were far more "find" 
operations than "union" operations.

Which (as everyone else here has been remarking) does not mean
complexity isn't important; it's just not the only thing.

In any case, when claiming P=NP, obviously time complexity is the
*only* thing worth mentioning.  Well, that and correctness, of course.

-- 
Ariel Scolnicov        |"GCAAGAATTGAACTGTAG"            | [EMAIL PROTECTED]
Compugen Ltd.          |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.    |Tel: +972-3-7658514 (Main office)`---------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555    http://3w.compugen.co.il/~ariels

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

From: "madcow" <[EMAIL PROTECTED]>
Subject: Re: WEP
Date: Tue, 10 Oct 2000 14:08:11 -0400

Oh.

Well, if you are looking at this description of  IEEE Std 802.11 WEP:

http://comsoc.org.mx/standard/802_11.htm

I think that's a typo.  I believe it should be "RC4 PRNG" . . . Psuedo
Random Number Generator.  That's kind of a way of decribing how it works.

You can see the correct description at:

http://www.networkcomputing.com/709/709work1.html

And an excellent diagram of it at:

http://www.tml.hut.fi/Opinnot/Tik-110.501/1997/wireless_lan.html#IEEE802.11



Ichinin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi.
>
> Nono, i mean "RC4 PRNO" algorithm. I know what RC4 is.
>
> Anyone know what "RC4 PRNO" is ?
>
>
> madcow wrote:
> > RC4 is a proprietory algorithm developed by RSA
> >  http://www.rsasecurity.com/ ), but you should be able to get the source
> > code of a reverse engineered version of it called "arcfour" on the web.
>
> > Some
> > companies will claim that no encryption is required, since they are
using
> > spread-spectrum communications.
>
> IMHO, The Frequence hopping methods are just there to reduce the overall
> ethernet colission rate, even further so by running all hardware in PSP
> mode. I know everything about the limited states of the sequence number
> generators, i know how to exclude up to 16% of the possible values and
> i know that the number of frequencies used are very limited, Frequency
> hopping is a minor nuissance for an intruder - i'd love to go into
> detail, but i have this paper *caugh* that say i cannot talk about
> certain
> things and i better check what it is before i talk about the subject :oP
>
> Anyway, that's my point - Buy an additional security toolkit from us :o)
>
> > Info on wireless networks:
> > http://www.wlana.com/
> > And on breaking RC4 40 in 8 days:
> > http://www8.zdnet.com/pcmag/issues/1508/pcmg0074.htm
> > and
> > http://catless.ncl.ac.uk/Risks/17.65.html
>
> Thanks.
>
> Glenn





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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Date: Tue, 10 Oct 2000 17:59:13 GMT

In article <[EMAIL PROTECTED]>,
  Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
>
> > Aw but in f(x) = ax + b the upper bits can be nonlinear.
>
> Can you give an example to illustrate?

Well in "F(x) = ax" in Z the lsb is given as "y0 = x0 and k0" and the
second bit is given as "y1 = (x1 and k0) xor (x0 and k1)", etc... thus
the as the bit position goes up the linear complexity goes up as well.
The msb is much less linear then the lsb.

Tom


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

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Quantized ElGamal
Date: Tue, 10 Oct 2000 18:00:20 GMT

In article <[EMAIL PROTECTED]>,
  Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> > An immediate way to prevent timing attacks is to make all operations
> > take exactly the same amount of time.
> > I believe that's what's meant by "quantized."
>
> And another way of preventing the attack is to use
> blinding schemes (such as first described by Chaum
> in a different context), this solution was present
> in Kocher's paper.
> So instead of directly computing m^a mod p, where a
> is the secret, you first blind your secret exponent:
> Choose random k, compute k*m mod p and k^(-a) mod p
> then instead of directly computing m^a mod p, compute
> tmp <- (k*m)^a mod p
> then compute tmp*k^(-a) mod p, the final result is
> m^a mod p.  The attacker doesn't know what k is, thus
> doesn't know what k*m is, nor what k^(-a).
> Kocher describes a way to "recycle" k, you can simply
> square the old value of k to obtain the new one (this
> is cheaper than choosing a new random value all the time).
> See the paper from Kocher.

This sounds much like ElGamal anyways...

Tom


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

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Need help: considerations for IV and Keysetup
Date: Tue, 10 Oct 2000 11:14:36 -0700

> > Using psuedorandom bits is never a good idea for a cipher key, unless
> > they're generated by seeding a CSPRNG with the password... in which
> > case, you are, in effect, taking a hash of the password.  Why not just
> > use a purpose built hash function in the first place?
>
> Why is that a bad idea? Take the user key, which could be hashed. The
> user key is then used to decrypt the masterkey (which was prior
> encrypted with the user key); the masterkey itself was generated using
> a PRNG, and is used in all further decryption/encryption processes of
> the tape.

That's still not a highly secure solution. As long as you have a weak link
of the form "take the users password and...." you have designed in an
attackable location. Sometimes this is necessary, other times it is
catastrophic. What is necessary is to take a large user entered secret
(generally called a passphrase), with a relatively known amount of entropy
(you suggested 256-bits), this will most assuredly escape password guessing
attacks. I'd also suggest that you use a cipher that can accept strings of
the size you'll need (the compressed version of about 256-bits), and use it
directly, at least until we have some well analyzed hashes of at least
256-bits, because you will have collisions in that space and it may reduce
the space of your real key. On the other hand it will create more hurdles
for someone given the ciphertext to get the key, it depends on your threat
model.


>
> > I would advise you get two hashes using two structurally different
> > hash algorithms (like SHA1 and RIPEMD), and take the first 256 bits
> > from the concatenation of the results.
>
> I don't think it is a good idea to use two hashes of the same
> passphrase, and then simply concatenate the digests together to 256bit.
> I remember someone explaining once in this forum why that would
> actually reduce the effective bitsize.

I agree that a concatenate structure of that form would likely not be
256-bits strong

>
> > Also, if you're wondering how someone could think up (and remember)
> > 256 bits of entropy, simply suggest that they use some poetry.  Most
> > people already know some poetry (from elementary or high school).  Or
> > a line or two from a play or movie.
>
> Aren't paraphrases from a poem, play, or movie all candidates for a bad-
> chosen-password making dictionary attacks much easier??

Yes they are. But the suggestion is a good one, if you prompt the user to
write a silly (or meaningful) poem for use, then it won't be in any book
(unless the user deliberately violates it).

I think the most important issue here is that to get 256-bits of entropy is
going to take between 128 and 256 characters, something most people don't
deal with unless they absolutely have to, and then they write it on a bunch
of sticky pads and stick it to the monitor. I think you need to find out
more about your target user before making any firm decisions.
                        Joe



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

From: Jeffrey Williams <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: Tue, 10 Oct 2000 13:33:58 -0500

Actually, when I first heard someone ask for the algorithm implemented as a
program, I assumed that the source code was the main interest.  Assuming that the
program actually worked (big assumption :), the source code would provide a
detailed description of the algorithm.  It's awfully hard (but not impossible) to
provide a working program whose source code is incomplete.

Christian Bau wrote:

> In article <8rve0u$8dn$[EMAIL PROTECTED]>, David C. Ullrich
> <[EMAIL PROTECTED]> wrote:
>
> >      Like if you were claiming you could prove Fermat's Last
> > Theorem you'd be willing to define the terms you used, eh?
> > (Sorry, wrong thread.)
>
> Defining the terms just makes it so much harder to claim you have a proof...
>
> Now serious: One problem that remains if you implement the algorithm is this:
>
> You implement the algorithm. You produce a sequence of test cases, run the
> test cases and check the output and the time needed by the algorithm. The
> times indicate that an execution time of O (n^6) might be correct (of
> course you cannot be sure of this, but you could make an educated guess).
>
> Now the problem: If you test the algorithm with a problem that takes 24
> hours to run, and it comes up with what it claims is a minimal set of
> cliques, how could you prove that the algorithm is wrong? If the problem
> is indeed NP-complete, there might be no way that you can ever find a
> smaller set of cliques in a reasonable amount of time, even if one exists.
> If this algorithm takes 24 hours on my computer to find a smallish but not
> minimal set of cliques covering a graph, then there might be no algorithm
> that will find a smaller set in the next thousand years.
>
> Of course you could construct problems where you know the solution to
> start with. But then it would be possible that the algorithm is designed
> so that it will find the solutions for these cases and not for others.
>
> For example, if you take the complement of any planar graph, then the
> algorithm should always find a set of four cliques covering that
> complement, and for some graphs find a set of three or fewer cliques. If
> the algorithm ever ends with five cliques, it is wrong. However, if it
> produces a set of four cliques, proving that this set is not minimal is
> NP-complete.


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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Looking for paper
Date: Tue, 10 Oct 2000 11:29:06 -0700

Let me spoil the ending for you. It's an mono-alphabetic substitution. It is
very weak, the only issue is finding the symbols, which with a huffman tree
is not that difficult.
                    Joe

"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I recall seeing a paper where data was compressed using a static huffman
> tree (with 0 and 1 labels on the branches randomly swapped), and the
> tree hidden... and analysis was done to attempt to recover the tree.  I
> don't, however, recall *where* I saw the paper... I think it was a .ps,
> or .ps.gz, not a .pdf or .html document.
>
> --
> "Mulder, do you remember when I was missing -- that time that you
>  *still* insist I was being held aboard a UFO?"
> "How could I forget?"
> "Well, I'm beginning to wonder if maybe I wouldn't have been
>  better off staying abo-- I mean, wherever it was that I was
>  being held." [from an untitled spamfic by [EMAIL PROTECTED]]
>
>



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

From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: securely returning password info to a server from a client
Date: Tue, 10 Oct 2000 12:01:34 -0700

"William A. McKee" wrote:
> Is there a royalty free library for SSL available?  Does it encrypt both
> from the client to the server and the server to the client?

http://www.openssl.org

The degree of encryption depends upon what degree you'll accept.

But as somebody else mentioned, if you're doing a web applet, use the SSL
built into the web server.

-- 
Eric Lee Green                         [EMAIL PROTECTED]
Software Engineer                      "The BRU Guys"
Enhanced Software Technologies, Inc.   http://www.estinc.com/
(602) 470-1115 voice                   (602) 470-1116 fax

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

From: Albert Yang <[EMAIL PROTECTED]>
Subject: Does Rijndael look Linear or is it just me?
Date: Tue, 10 Oct 2000 19:03:43 GMT

OK, AES is chosen, and so this might be considered by some to be water
under the bridge, but I keep reading about the "Rijndael is just as safe
as Serpent because brute force is still the fastest known method etc.."

Yes, but to me, from the stuff I have read, and certainly N. Fergeson's
article didn't help to deminish the bias...

But informal survey, is it just me or does Rijndael look very linear and
looks to come under some SERIOUS attack from linear crypto attacks in
the not so distant future??  Especially now that almost 100% of the
crypto community has only 1 target...  I think there is a basis for the
paranoia, don't you?

Albert

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


** 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