> Ernest Hua wrote:
>
> Can someone point me to the argument where
> either Judge Kaplan or some motion picture
> industry person claims publication of DeCSS
> code results in imminent or irreparable
> harm?
Most or all the arguments on both sides are archived at:
http://www.eff.org/cafe/
The
Kevin Blanchard wrote:
>
> In fact I think spreading the DeCSS is a GREAT idea. If they are trying to
> stop people from posting it, I think an email circulation is also in order.
>
> I do not believe it should be down as a rebellion but history has shown the
> technology advances happen more oft
Back in mid-1999, I sent this to the list:
> The Canadian Dep't of Foreign Affairs & International Trade (DFAIT) has an export law
> page at:
>
> http://www.dfait-maeci.gc.ca/~eicb/notices/ser113-e.htm
>
> It includes this text:
>
> | PROPOSED EXPORT CONTROL LIST CHANGES:
> |
> | 12. The Was
tchley Park became the center of Allied code-breaking. Enigma
was a major target, though they also worked on other ciphers.
They built two generations of cracking engine specifically for Enigma.
Flowers was the main designer of Collosus, the second one.
--
Sandy Harris[EMA
Forwarded from another list
Original Message
Subject: Update on PGP-export restrictions from Denmark
Date: Tue, 15 Dec 1998 15:41:17 +0100
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Reply-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi
This is an update
Enzo Michelangeli wrote:
> Sure, I did not intend to belittle the theoretic significance of those
> papers, which are surely very interesting. I just meant that:
>
> 1. Converting a generic codebreaking problem into an NP-complete one with a
> transformation of polynomial complexity, while prob
Russell Nelson wrote:
> Plus, the source of the entropy and algorithm used to create the
> bridge hands merely need to be auditable. As long as the hands are
> based on some public source of entropy (e.g. the day's stock market)
> plus a letter publicly chosen by each of the participants (that's
I'm thinking about getting enough random numbers for a server that
does a lot of crypto, e.g. an IPSEC gateway, a web server doing
SSL, perhaps a PKI server.
On a heavily loaded server running FreeS/WAN IPSEC
http://www.xs4all.nl/~freeswan
you might have something of the order of an IPSEC conne
bram wrote:
> > > Most of the fancy reseedable PRNG schemes people have come up with are
> > > based on using secure hashes.
> >
> > They are sure validated, but are they the best we can do? MD5, the
> > nonplusultra, really?
>
> The main reason for secure hashes being the primary primitive us
Enzo Michelangeli wrote:
> Sorry folks, but I can't understand where the problem is supposed to be. The
> entropy of a pool is a measure of the information about its internal state
> that we don't know: which is why in thermodynamics the same name is given to
> the logarithm of the number of (in
John Kelsey wrote:
Quoting me:
> >Proposal:
> >
> >Could we do a large part of this with a fairly simple chip,
> >all digital, without diodes etc.? A system bus has typically
> >at least 32 data and 32 address lines plus a bunch of
> >control signals. Perhaps 80 bits that can be sampled at
> >pe
This is an attempt to summarize a wide-ranging discussion
and see if we have a consensus.
There's been much discussion on at least three lists:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
of design of random number generators in general and
Linux /dev/random in particular.
In an ealier message I wrote:
> Conclusions I've reached that I hope there's agreement on:
>
> More analysis is needed, especially in the area of how
> to estimate input entropy.
>
[SNIP]
>
> Yarrow's two-stage design, where the output from
> hashing the pool seeds a pseudo-random number
> gen
The Canadian Dep't of Foreign Affairs & International Trade (DFAIT) has an export law
page at:
http://www.dfait-maeci.gc.ca/~eicb/notices/ser113-e.htm
It includes this text:
| PROPOSED EXPORT CONTROL LIST CHANGES:
|
| 12. The Wassenaar ... States agreed to ... a Cryptography Note
| app
"Steven M. Bellovin" wrote:
>
> In message <[EMAIL PROTECTED]>, Declan McCullagh wr
> ites:
> > What I found most interesting was what Attorney General Reno said about the
> > government's cryptanalysis abilities. When asked if she can break strong,
> > >64 bit equivalent crypto, she said, "We ha
This was sent to several individuals and five mailing lists. Is that necessary?
I've cut reply down to two lists.
Marc Horowitz wrote:
>
> For most attackers and most secrets, more traditional techniques like
> blackmail and torture are likely to be cheaper and easier than the
> attacks below.
Andrew Cooke wrote:
> I expect a PRNG with an internal state of n bits to produce output
> that is predictable given n consecutive bits of output. Is that
> correct?
I don't think it is so necessarily, but two weaker constraints are.
If the internal state is n bits, then a brute force attack t
"Perry E. Metzger" wrote:
>
> Anyone know anything about this?
It was a Certicom elliptic curve challenge. For details:
http://www.certicom.com/
> --
> Perry Metzger [EMAIL PROTECTED]
> --
> "Ask not what your country can force other people to do for you..."
> --- Start of forwar
The definition in the glossary for the FreeS/WAN Linux IPSEC project is:
A property of systems such as Diffie-Hellman key exchange which use a
long-term key (the shared secret in IKE) and generate short-term keys
as required. If an attacker who acquires the long-term key provably can
neithe
Lisa Guernsey wrote:
>
> Hello,
>
> I'm working on a story that mentions several encryption systems, and I've
> heard that many companies often claim they have good products when in fact
> they have the equivalent of snake oil.
"Snake oil" is so common that there's a FAQ on recognising it:
htt
Paul Kierstead wrote:
>
> > Frankly, I can't understand why the IPsec protocol still
> > allows DES. It
> > should require strong encryption. Having DES in a product
> > these days makes
> > about as much sense as mandating the usage of ROT13.
>
> OK, so I want to prevent some regular, every-day
21 matches
Mail list logo
