Re: content rather than key?

From: Michiel Buddingh' (michiel@nospam.com)
Date: 03/05/03 

From: "Michiel Buddingh'" <michiel@nospam.com>
Date: Wed, 05 Mar 2003 16:45:48 +0000

On Wed, 05 Mar 2003 17:00:49 +0200, Kai wrote:

> ... let's see, say an intelligent program can associate more
> information with the key than the content. My first example
> was very limited ...
>
> say someone uses
> 'pirate' as a key.
>
> the intelligent program would expand this to something like
>
> 'ship' 'flag' 'island' 'treasure' 'ocean' 'sword' '1600'
>
> now we have a long key
>
> shipflagislandtreasureoceanswordseventeenthcentury
>
> would that not improve entropy?

IANAC (I am not a cryptographer)

I don't think so. For such an algorithm to work, you'd have to
choose those words from a limited set, in a predictable manner.
Furthermore, you'd have to limit the possible input passwords
as well..

So it would be possible for someone to write an algorithm that
would simply loop through all the possible passwords, find its
associated words, and try them.

In short, it would increase the entropy of a string in the same
way that multiplying by 1000 increases the entropy of a number,
namely not.

You _could_ choose the words in a random order, and let the de-
cryption algorithm try all possible combinations of the associated
words.

This would be comparable to adding a few random bits to the end of
a number, so I guess that _would_ increase entropy (since the algorithm
pulls entropy from the (P)RNG used to randomize the sequence, that
doesn't violate Eivind's assertion).

Given a sufficiently large network of words, and given enough randomness,
I think such a function _could_ increase the security of `natural'
passwords, perhaps to a level that brute force attacks become too tedious
for anyone to bother.

However, such a function would be very slow, especially on decryption,
and there are easier ways of throwing randomness into an algorithm.

IANAC
 
> Someone flamed me for the word 'organcially' ... this is what
> I meant. Obviously this is very simple. you can take it extremely
> far. Imagine the possibilities to enhance entropy by linking.
>
> I guess this must be very stupid.

It doesn't seem stupid to me. Then again, I'm not a cryptographer. 

-- 
				-- michiel

Relevant Pages

  • Re: content rather than key?
    ... For such an algorithm to work, ... > would simply loop through all the possible passwords, ... it would increase the entropy of a string in the same ... > and there are easier ways of throwing randomness into an algorithm. ...
    (sci.crypt)
  • Re: real random
    ... Fortuna is, excluding everything they have to say on the matter. ... Are you literally saying that Fortuna is not an algorithm? ... have a source of entropy. ...
    (comp.lang.c)
  • Re: real random
    ... Feel free to post such an algorithm, ... it as a generator of a stream of numbers, ... You need a genuine source of entropy, ... By suggesting Fortuna (which gathers genuine entropy as it goes), ...
    (comp.lang.c)
  • Re: cipher program
    ... > Both the program code and the cipher are, well, atrocious. ... > Determining that 16 bits of entropy is all the passphrase does. ... >> might be achieved with a more complex algorithm, ... > It's periodic XOR with a fixed period of 2^16 bytes. ...
    (sci.crypt)
  • Re: is this double CBC?
    ... i've never once said an algorithm does not work on 128 bits... ... think the best is the claim that your process "Does not consume entropy, ... of is that it violates all the requirements of the CBC proof. ... the cryptographic algorithms, or the chaining mode. ...
    (sci.crypt)