Cryptography-Digest Digest #898, Volume #10 Thu, 13 Jan 00 16:13:01 EST
Contents:
Re: Truly random bistream (Guy Macon)
Re: AES & satellite example (John Savard)
Re: AES & satellite example (John Savard)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Re: Need some design suggestions for mass encryption ("Trevor Jackson, III")
Re: AES & satellite example (John Savard)
Re: AES & satellite example ("Trevor Jackson, III")
Re: "1:1 adaptive huffman compression" doesn't work ("Trevor Jackson, III")
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (Anne & Lynn Wheeler)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
Re: "1:1 adaptive huffman compression" doesn't work (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Truly random bistream
Date: 13 Jan 2000 14:36:29 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>Nobody can measure resistance with the accuracy required. It takes
>time to measure resistance. The more accurate you want to be, the
>longer you have to observe for. Without measurement, you can't
>confirm the resistance of the entity in question to the satisfaction of
>anyone else.
Would a superconducting ring with a current going round and round
for months or years be good enough for you? Got that. Would a
magnetic field measurement an one day equalling one at six months
being as close as we can measure help? Got that too.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES & satellite example
Date: Thu, 13 Jan 2000 12:36:27 GMT
[EMAIL PROTECTED] (David Wagner) wrote, in part:
>Remember, one-time pad keys can be pre-arranged, many years before
>the communication takes place. So your argument misses the point:
>yes, the new cipher might be small enough that we could have fit it
>in ROM if it were available when the satellite was launched, but in
>some cases, we might want to change to a cipher that was not available
>(or adequately trusted) at launch time.
That does make sense: instead of simply including a bunch of
conventional ciphers, include a one-time-pad, which we can be sure is
safe, and then when the old cipher is compromised, one can upload a
cipher based on our improved knowledge at that future time.
It is an even better solution to the problem.
However, because the length of a one-time-pad is limited, perhaps that
should be kept for when it is _really_ needed - and so having multiple
ciphers from those known at launch time is also not a bad idea, for
use in less serious circumstances.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES & satellite example
Date: Thu, 13 Jan 2000 12:40:37 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>Note that the satellite designer might settle for a single, reprogrammable
>cipher, but AES must consist of multiple selections so the satellite manager can
>quickly adjust to the news of a weakness. The alternative is for the satellite
>manager to wait for a new super AES to be selected before secure communication
>can be re-established.
If people are so helpless that, upon discovering that the "official
standard" cipher is no good, they cannot switch to another cipher
unless it, too, has become an "official standard", they have little
hope of achieving secure communications in any event.
One assumes that, even in the absence of "multiple AES winners", there
will be new cipher designs and continued cryptographic research in the
forthcoming years just as there has been in the past.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Thu, 13 Jan 2000 20:48:22 +0100
Tim Tyler wrote:
> :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> :> : My 'No' was intended to negate your 'no longer portable', not
> :> : 'non-deterministic'. Tell me in what sense the software is not
> :> : portable?
> :>
> :> If you have no convenient source of genuine randomness, it won't work.
> :> Not every system comes with a good hardware source of random numbers.
> :> If you use something pat all redictable, you introduce possible problems.
>
> : I don't understand what 'possible problems' you would have.
>
> The attacker knows something about the data in the compressed file,
> information which he need not be supplied with. He knows it is likely
> to have certain non-random stuff at its end. This is less than ideal.
Are you going to argue like those who unconditionally want 'absolute'
security? Note that one never gets 100.00% pure gold in this world,
there is always some foreign atoms in there. Returning to the present
case, we are discussing about the (practical) problem raised by Scott.
Do you think that my proposed scheme has 'practically' solved the
problem or not? How does one proceed to exploit the 'certain
non-random stuff'? Suppose he finds that with a certain key K1 (that
he tries to decrypt) the resulting compressed file has 2 filling bits.
With another key K2 it happens that there are also 2 filling bits.
Let's say there are one hundred thousand keys that he has found to
lead to 2 filling bits. Some of these filling bits are 00, others
are 01, 10 and 11. Please tell me a 'concrete' way to get some
'information' out of these that is 'actually' sensible to his task,
namely to decrypt to obtain the information in the bit sequences
'preceeding' these 2 filling bits. In case of the simple-minded method
of filling that I described, he finds that the distribution of
the bit patterns is uniform. But that's the 'only' statistical
information he can get, isn't it? Is that data going to be useful
to him in any way?? Note that by construction the filling bits are
'not related' to the (presumed) 'plaintext' that is compressed
and therefore the bunch of bits in the compressed file before
the filling bits are also not related to the filling bits.
>
> : In fact, I don't need 'true randomness', nor even
> : 'pseudo-randomness', only 'non-constancy'.
>
> This won't do at all, IMO.
Please explain. Don't just put up a claim without any supporting
material, for nobody would be able to know what you have in mind.
>
> : In particular, periodicity will do perfectly well for my proposal.
> : Let's take the case where the plaintext (true one, or the wrong
> : one because of wrong decrypting key) is such that there need to
> : be 2 filling bits. Suppose the software is such that on the first
> : use it emits 00, the second time 01, the third time 10, the fourth time
> : 11, the fifth time 00, etc. Now suppose what the analysyt has after
> : decrpytion is a version with filling bits 00. He decompresses it
> : to the (presumed) plaintext and compresses that back again. There
> : are four different possibilties of the result. But in NO case can
> : he obtain any information, because he knows that any difference
> : is due to the 'ideosyncracies' of the compression software and
> : is not related at all to the 'proper' information in the file.
>
> That doesn't appear to be correct. Imagine the case where he has a
> complete known-plaintext attack on the cypher that recovers the key,
> and several consecutive known plaintexts. He can thus determine what
> padding bits have been used by the compressor. If he is intercepting
> all messages, he thus has information about what the padding bits are
> most likely to be on the next message, should that message require two
> padding bits. This is information he would not normally have, which may
> assist him with any attack.
>
> Of course, if he only has one message to work on, then - as you say -
> he's no better off.
In the example case mentioned above, all four filling bit patterns are
'equally likely', there is no 'most likely' one. Could the analyst
still do something with his 'statistical data' of the filling bits?
> Padding bits /ought/ to be as random as possible - given the constraint
> that they must not make any complete Huffman symbols.
>
> Any deviation from randomness are like preferentially padding with zeros -
> they potentially give the attacker statistical knowledge about the bits at
> the end of the file.
Covered above, I suppose.
M. K. Shen
------------------------------
Date: Thu, 13 Jan 2000 14:48:19 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Need some design suggestions for mass encryption
Albert Yang wrote:
> Hey there crypto-heads, I need some help.
>
> My company has commissioned me with a daunting task. We deal with
> highly sensitive private information (phone, credit card #, addy, etc..)
> and we want to save it on our DB encrypted. But there are certain
> things that have to happen. For example, I'm allowed to share my phone
> number or address with certain people, kind of like a group
> phonebook... So I would need to allow them access at any time. Yes, I
> know, sounds like a Public key deal, where I just encrypt with all the
> public keys that I want to have access to my stuff. But I need to be
> able to revoke access from certain people at any given time. So is
> there any way to design this smartly, where I don't have to basically
> decrypt, reencrypt with one less key, just to deny someone who use to be
> on my access list? Also, Public key crypto is slow, I'm not sure this
> is something that public crypto can do on the fly, fast enough. I would
> need to use something that's really fast. So any suggestions are
> welcome!
You are mixing two separate and distinct functions. The encryption of the
data is not necessarily related to the permission to decrypt the data. Thus
I suggest you need two layers, the top to manage access permissions
(awarding keys) and the bottom to perform encryption with those keys.
This is a tough area. And you can easily create a maintenance nightmare out
of your fuzz specs. So KISS your initial efforts to death.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES & satellite example
Date: Thu, 13 Jan 2000 12:43:48 GMT
Greg <[EMAIL PROTECTED]> wrote, in part:
>But an expensive mil bird would be a very strong candidate. Or do
>you think that the military would use something other than AES
>finalists?
They already do.
There's this little Federal agency called the NSA, that has thousands
of America's top mathematicians working for it, with experience in
cracking the ciphers of other nations, and a huge body of specialized
knowledge which is kept secret...and it designs the ciphers used by
the U.S. military. Without telling the world anything about the
algorithms used.
Because their in-house expertise exceeds that available in the open
academic community, they can get away with doing that and still have
secure ciphers.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Thu, 13 Jan 2000 15:01:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
John Savard wrote:
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>
> >Note that the satellite designer might settle for a single, reprogrammable
> >cipher, but AES must consist of multiple selections so the satellite manager can
> >quickly adjust to the news of a weakness. The alternative is for the satellite
> >manager to wait for a new super AES to be selected before secure communication
> >can be re-established.
>
> If people are so helpless that, upon discovering that the "official
> standard" cipher is no good, they cannot switch to another cipher
> unless it, too, has become an "official standard", they have little
> hope of achieving secure communications in any event.
>
The competence or helplessness of the people and organizations is not the issue. The
issue is contracts and regulations that will mandate the use of ciphers approved by
federal standards. I know _exactly_ how an organization faced with such constraints
will behave when faced with a flaw in their cipher: They will do nothing.
Given a choice between providing the legally mandated services, even though useless,
and providing useful services that fall outside the bounds of the approved set,
organizations will elect to stay legal.
Consider the reaction of the French banking industry to their woes with weak
ciphers. Denial is a preferred coping mechanism because it is a perfect defense
against criticism. A broken cipher standard invites exactly this response from the
bureaucrats responsible for choosing the cipher. This kind of behavior is
_extremely_ well documented.
Is this the kind of situation we want to arrange? I doubt it.
>
> One assumes that, even in the absence of "multiple AES winners", there
> will be new cipher designs and continued cryptographic research in the
> forthcoming years just as there has been in the past.
None of that will be relevant. Given the history of DES, which I think is now
expired longer than its originally expected lifetime, what should we expect of AES?
I'd bet we should expect nothing until there is a perceived need. Opportunistic
enhancements to federal standards are few and far between.
Given the level of complaints about "multiple standards is not a standard!", how loud
do you think those complaints will be after the standards are established? _NOW_ is
the only time it is reasonable to diversify the cipher set. If NIST picks one cipher
we're probably going to be stuck with it for decades.
------------------------------
Date: Thu, 13 Jan 2000 15:07:36 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Mok-Kong Shen wrote:
> Tim Tyler wrote:
>
> > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > :> : My 'No' was intended to negate your 'no longer portable', not
> > :> : 'non-deterministic'. Tell me in what sense the software is not
> > :> : portable?
> > :>
> > :> If you have no convenient source of genuine randomness, it won't work.
> > :> Not every system comes with a good hardware source of random numbers.
> > :> If you use something pat all redictable, you introduce possible problems.
> >
> > : I don't understand what 'possible problems' you would have.
> >
> > The attacker knows something about the data in the compressed file,
> > information which he need not be supplied with. He knows it is likely
> > to have certain non-random stuff at its end. This is less than ideal.
>
> Are you going to argue like those who unconditionally want 'absolute'
> security? Note that one never gets 100.00% pure gold in this world,
> there is always some foreign atoms in there.
Ah, but the arguments about imperfection of measurement cut in both directions.
If the limitations on our measurements indicate that we cannot determine that the
gold is pure, those same limitations indicate that we cannot determine that the
gold is _not_ pure.
So the statement "pure to the limit of measurement" can be sensibly equated with
"absolutely pure" because the two states are indistinguishable. A difference that
makes not difference is _not_ a difference. It is some kind of weak confirmation.
------------------------------
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Thu, 13 Jan 2000 20:07:54 GMT
EDI has been both translators and the private value added networks that
provide secure, reliable connectivity between the trading partners
(s/mime addresses some of the secure issues ... but existing internet
mail transport isn't exactly known for 100% reliability).
translators are complex because they operate between commercial legacy
systems and normalized transport format that has tended to be industry
specific.
it has been in extensive use for lots of b-to-b ... which you
wouldn't normally hear about in non-b-to-b locals (say internet
currently is small percentage of retail commerce and retail commerce
is small percentage of b-to-b, aggregate of value related to
EDI-transactions can easily be several orders of magnitude larger than
existing internet retail commerce).
another body playing here is OMG
http://www.omg.org/
in part because it isn't just the syntax of the information exchange
but also the business operations that operate on the information
exchanged (i.e. not only need to normalize information format ... but
also semantics of the business operations).
XML/internet, etc related EDI reasonably can move it into higher
volume & lower valued transactions (lot of existing, more expensive
EDI is wrapped around high value activities).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Thu, 13 Jan 2000 21:29:08 +0100
Trevor Jackson, III wrote:
>
> Mok-Kong Shen wrote:
>
> > Tim Tyler wrote:
> >
> > > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > :> : My 'No' was intended to negate your 'no longer portable', not
> > > :> : 'non-deterministic'. Tell me in what sense the software is not
> > > :> : portable?
> > > :>
> > > :> If you have no convenient source of genuine randomness, it won't work.
> > > :> Not every system comes with a good hardware source of random numbers.
> > > :> If you use something pat all redictable, you introduce possible problems.
> > >
> > > : I don't understand what 'possible problems' you would have.
> > >
> > > The attacker knows something about the data in the compressed file,
> > > information which he need not be supplied with. He knows it is likely
> > > to have certain non-random stuff at its end. This is less than ideal.
> >
> > Are you going to argue like those who unconditionally want 'absolute'
> > security? Note that one never gets 100.00% pure gold in this world,
> > there is always some foreign atoms in there.
>
> Ah, but the arguments about imperfection of measurement cut in both directions.
> If the limitations on our measurements indicate that we cannot determine that the
> gold is pure, those same limitations indicate that we cannot determine that the
> gold is _not_ pure.
>
> So the statement "pure to the limit of measurement" can be sensibly equated with
> "absolutely pure" because the two states are indistinguishable. A difference that
> makes not difference is _not_ a difference. It is some kind of weak confirmation.
No. It is some kind of 'strong' confirmation that 'humans are weak',
i.e. they lack the omnipotent power of God.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Thu, 13 Jan 2000 21:55:20 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Tim Tyler wrote:
>
>> :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>
>> :> : My 'No' was intended to negate your 'no longer portable', not
>> :> : 'non-deterministic'. Tell me in what sense the software is not
>> :> : portable?
>> :>
>> :> If you have no convenient source of genuine randomness, it won't work.
>> :> Not every system comes with a good hardware source of random numbers.
>> :> If you use something pat all redictable, you introduce possible problems.
>>
>> : I don't understand what 'possible problems' you would have.
>>
>> The attacker knows something about the data in the compressed file,
>> information which he need not be supplied with. He knows it is likely
>> to have certain non-random stuff at its end. This is less than ideal.
>
>Are you going to argue like those who unconditionally want 'absolute'
>security? Note that one never gets 100.00% pure gold in this world,
>there is always some foreign atoms in there. Returning to the present
>case, we are discussing about the (practical) problem raised by Scott.
>Do you think that my proposed scheme has 'practically' solved the
>problem or not? How does one proceed to exploit the 'certain
>non-random stuff'? Suppose he finds that with a certain key K1 (that
>he tries to decrypt) the resulting compressed file has 2 filling bits.
>With another key K2 it happens that there are also 2 filling bits.
>Let's say there are one hundred thousand keys that he has found to
>lead to 2 filling bits. Some of these filling bits are 00, others
>are 01, 10 and 11. Please tell me a 'concrete' way to get some
>'information' out of these that is 'actually' sensible to his task,
>namely to decrypt to obtain the information in the bit sequences
>'preceeding' these 2 filling bits. In case of the simple-minded method
>of filling that I described, he finds that the distribution of
>the bit patterns is uniform. But that's the 'only' statistical
>information he can get, isn't it? Is that data going to be useful
>to him in any way?? Note that by construction the filling bits are
>'not related' to the (presumed) 'plaintext' that is compressed
>and therefore the bunch of bits in the compressed file before
>the filling bits are also not related to the filling bits.
>
>>
>> : In fact, I don't need 'true randomness', nor even
>> : 'pseudo-randomness', only 'non-constancy'.
>>
>> This won't do at all, IMO.
>
>Please explain. Don't just put up a claim without any supporting
>material, for nobody would be able to know what you have in mind.
>
>>
>> : In particular, periodicity will do perfectly well for my proposal.
>> : Let's take the case where the plaintext (true one, or the wrong
>> : one because of wrong decrypting key) is such that there need to
>> : be 2 filling bits. Suppose the software is such that on the first
>> : use it emits 00, the second time 01, the third time 10, the fourth time
>> : 11, the fifth time 00, etc. Now suppose what the analysyt has after
>> : decrpytion is a version with filling bits 00. He decompresses it
>> : to the (presumed) plaintext and compresses that back again. There
>> : are four different possibilties of the result. But in NO case can
>> : he obtain any information, because he knows that any difference
>> : is due to the 'ideosyncracies' of the compression software and
>> : is not related at all to the 'proper' information in the file.
>>
Dear Mok
If the one intercepting konws your compression program there has to
be a means to seperate where the compression ends and the random
data begins. If one does that then the added random information did nothing.
Better to use a 1-1 compression where the data is compressed to fit the
spave available and where no extra info is added. Since the decompression
program most be able to seperate out this random stuff anyway.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
