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
"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 plainte
Paul Crowley <[EMAIL PROTECTED]> writes:
> 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 algo
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 po
dmolnar <[EMAIL PROTECTED]> writes:
> On Wed, 3 Jan 2001, Ben Laurie wrote:
>
> > > A cipher is Conditionally Computationally Secure
> > > (CCS) if the cipher could be implemented with keys
> > > that are not quite "long enough" or with not quite
> > > "enough" rounds to warrant a CS rating. Exa
"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
Ray Dillinger <[EMAIL PROTECTED]> writes:
> There are times and places where you can use salt, and times and places
> where you can't. In order to use salt with a passphrase, you have to
> store it somewhere. And that means that a person who has only the
> ciphertext and the passphrase cannot
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 tha
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
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 in
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
[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 dat
I was under the impression that UMAC-based hashing was subject to some
patents. Does anyone know if there are such patents, and (if so)
whether any worldwide licenses have been granted on any such?
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
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 kn
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
re's
no burden on the signer 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 ineffe
"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 i
mber of key bits you 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* \
inal submission from the Twofish
authors argues 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.
--
, and (if your
components are secure) your attacker will never be any better off than
they were when you first started producing 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/ /~\
igns that
offered it.
--
__
\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
r AES primary) the only MUST cipher.
--
__
\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
entropy.pdf
I also have a slightly longer summary on
http://www.cluefactory.org.uk/paul/postings/news-619.txt
--
__
\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ /
/\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
ially over intellectual property issues. However, even if you're
unconvinced, I hope that any reply you compose does without hooting
and other sound effects, since I'm not paid to discuss this and you're
not making it any more fun.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
option mandated RC4. I doubt any mention of RC4
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/ /~\
TECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
know very much about
the scheme in use.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
number of collisions is x, the probability of *no*
collisions is I think roughly e^-x.
If I keep generating new members of S from U until I get a collision,
does anyone know the expected size of S when I succeed?
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \
t they are. I agree this is most likely a non-issue, I'm just
wondering what the theoretical possibilities are.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
bias; I'll try and put it on the
Web pages in the next few days.
You might also be interested in hearing about a similar (but *much*
smaller) flaw in RC4:
http://www.hedonism.demon.co.uk/paul/rc4/
hope this helps,
- --
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__
31 matches
Mail list logo
