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 Wassenaar ...
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 often
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 EFF
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 hackers
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:
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
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. At
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
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
generator
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
perhaps 100
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
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
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
13 matches
Mail list logo
