Here's something by Ron Rivest about RC4 security that will give you a
simple overview before delving into the articles that Steve Bellovin
cited in his message. Note that Steve Bellovin's link includes the two
papers on RC4 weaknesses that Rivest references.
http://www.rsasecurity.com/rsalabs/te
In message <[EMAIL PROTECTED]>, Damien
Miller writes:
>The common wisdom when using (A)RC4 as a PRNG seems to be to discard
>the first few bytes of keystream it generates as it may be correlated
>to the keying material.
>
>Does anyone have a reference that describes this in more detail? Or
>am I
The common wisdom when using (A)RC4 as a PRNG seems to be to discard
the first few bytes of keystream it generates as it may be correlated
to the keying material.
Does anyone have a reference that describes this in more detail? Or
am I confused :)
-d
--
| By convention there is color, \\
It seems to me that a very similar argument can be made regarding the
need (or lack there of) for a national identity card. Organizations
that require biometric identity can simply record that information in
their own databases. The business most widely cited as needing
national ID cards, the
First, many thanks to you John and cryptome for archiving this
article.
While the report doesn't appear to falsify any information it uses
shady english to wet your imagination into assuming things which
are indeed false. So, I just want to cover and clear a few things
from the article:
(btw
I would tend to make the statement even stronger.
large, complex legacy systems tend to have slow technology uptake. most of
the certification authorities can be deployed in simple demos w/o impacting
the legacy systems and business process (possibly as a front-end process
that is pealed off bef
Nelson Minar <[EMAIL PROTECTED]> writes:
>The thing that makes me the most sad is that the PKI situation only seems to
>be getting worse, not better.
The reason for this is that as we work on PKI deployment, we discover more and
more (previously unknown) problems which need to be solved. If you
>As I never tire of saying, "PKI is the ATM of security."
Naah, it's the monorail/videophone/SST of security. Looks great at the World
Fair, but a bit difficult to turn into a reality outside the fairgrounds.
Peter (who would like to say that observation was original, but it was actually
it isn't that you move it to a central authority you move it to an
authority that typically is already established in association with
authorization ... aka in normal business operation, a business relationship
is established that typically consists of creating an account record that
has var
Nelson Minar wrote:
> >Of course, client side certificates barely even exist, although
> >people made substantial preparation for them early on in the history
> >of all of this.
>
> I used to be puzzled by this. Then a couple of years ago I went
> through the process of getting a client-side cert
The ABA Information Security Committee has a mailing list where some
great discussion of this is taking place. It's a closed mailing list;
ABA members only, but the archives are public.
I recommend looking at some of the articles there; this one is a great
starting point:
http://mail.abanet.
The following is the preliminary list of accepted papers for
Financial Cryptography 2002. For information on the conference,
including registration, see
http://fc02.ai
Paper: 017
Authors: Markus Jakobsson
Title: Low-Cost Hash Sequence Traversal
-
Paper: 020
Authors: Markus
for the most part HTTPS SSL is certificate manufactoring (a term we coined
a couple years ago) "infrastructure" typically implies the
administrative and management which would require (at a minimum) CRLs
for a certificate-based PKI.
the interesting thing about the use of SSL domain nam
13 matches
Mail list logo
