Bill Stewart [EMAIL PROTECTED] writes:
If you've got room for an IV, you _could_ do something like
XORing the IV with the key, not the data stream -
that means that it isn't really using the same algorithm
for the IV as for the rest of the data stream, but you may not care.
With RC4, it's
"Arnold G. Reinhold" [EMAIL PROTECTED] writes:
In any case, as I tried to point out before, perfect compression, what
ever it may be, does not prevent a know-plaintext attack.
Actually it does: if the compression is perfect with respect to the
document model of the attacker, and the plaintext
Peter Fairbrother [EMAIL PROTECTED] writes:
Not so. Perfect compression with encryption works too.
Er, does it? I get a 1k message from you, perfectly compressed and
then encrypted with some strong algorithm and a 128-bit key. As a
godlike being unhindered by constraints of computational
"Perry E. Metzger" [EMAIL PROTECTED] writes:
Getting around the license stuff will always be trivial, however, in
spite of the pipe dreams of fools. If the software can be read by the
user's computer, it can be copied. If it can be copied, automated
tools will be developed to permit it.
Rich Salz [EMAIL PROTECTED] writes:
No word, of course, on how the thing actually works, or whether they
intend to patent it.
Not so. Search your nearest IETF internet-drafts repository for
draft-jutla-ietf-ipsec-esp-iapm-00.txt
Eh? It would be bad if a patented system became
Rick Smith at Secure Computing [EMAIL PROTECTED] writes:
Now, just how do we intend to address such concerns in our memory-based
authentication systems? Our whole technology for using memorized secrets is
built on the belief that people will remember and recite these secrets
perfectly.
Bram Cohen [EMAIL PROTECTED] writes:
Is there a reason not to use AES block cipher in a hashing mode
if you need a secure digest of some data?
Hashing modes of block ciphers require a re-key for every block, and hence
are really, really slow.
Well, Rijndael can re-key faster than it can
Bill Sommerfeld [EMAIL PROTECTED] writes:
Eh? You should *never* need to encrypt information before shoving
it in the pool. If you've got a secret you could use for such
encryption, shove it in the pool and then forget about it - it will do
precisely as much good.
I'm inclined to
Don Davis [EMAIL PROTECTED] writes:
perhaps surprisingly, i disagree with the other
respondents. as long as you encrypt or MAC the
incoming packets ( their interarrival times),
with a closely-guarded secret key, before you
stuff the bits into your entropy pool, then you
should do fine.
[EMAIL PROTECTED] writes:
Why don't you stick a sound card (the noisier, the better) into each
node, and dump /dev/dsp (LSB) input at max amplification into the
randomness pool?
There's no reason to put only the LSBs in the randomness pool, if the
pool is properly designed. Put all the data
Meyer Wolfsheim [EMAIL PROTECTED] writes:
The only reasons I see for having a security system (be it an encryption
product, or a physical access device) with a large discrepancy in the level
of security that the individual components provide is either:
[snip reasons a, b and c]
I'm sure
NIST is running a Modes of Operation workshop on Friday 20th. See
http://csrc.nist.gov/encryption/aes/modes/
It seems likely that NIST will demand the same licensing conditions
from anyone proposing a mode of operation for standardisation that
they did for the AES cipher itself. Does anyone
r of a key to verify the email address, only the
name. I can turn up to a keysigning party with my passport and get my
key signed as "Paul Crowley [EMAIL PROTECTED]", because no-one's
expected to check that part. I think it appears as an ineffective fix
to the problems I'm trying to h
"Fred Hapgood" [EMAIL PROTECTED] writes:
Stick *what* into a standard contract? What would that provision
look like? "Artist agrees not to accept gifts from fans?" "Artist
agrees not to possess or publicize public key or digital signature?"
"Artist shall not in any way participate in
need. I suspect any good solution will have
this property. Still, you only have to keyschedule n times and things
should be pretty fast after that.
Any thoughts on the security or efficiency of this proposal?
--
__
\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley
that any of those three would make excellent winners;
FWIW I agree. It's far from clear that Twofish is ahead of the other
two.
That the three best-regarded ciphers should be the unpatented ones
should be of interest to patent watchers.
--
__
\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS*
oducing output.
Given this, what theory can you use to determine if you're using those
subsequent bits of entropy appropriately?
--
__
\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
would have been made in either the advertising or the documentation.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
very much about
the scheme in use.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
22 matches
Mail list logo
