Cryptography-Digest Digest #500, Volume #10 Wed, 3 Nov 99 12:13:03 EST
Contents:
Q: Removal of bias (Mok-Kong Shen)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (David Bernier)
Re: Steganography Academy (Johnny Bravo)
Re: Your Opinions on Quantum Cryptography ([EMAIL PROTECTED])
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: Q: Removal of bias (Tom St Denis)
Re: unpacker to trace code (Tom St Denis)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: An encryption proposal from a Newbie... (CoyoteRed)
Re: An encryption proposal from a Newbie... (CoyoteRed)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (CoyoteRed)
Re: announcement: steganography program "steghide" (jerome)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Removal of bias
Date: Wed, 03 Nov 1999 08:40:52 +0100
Could anyone give references to practical results of removal of
bias in random number/bit sequences, showing the efficiency of
the techniques? Thanks in advance.
M. K. Shen
------------------------------
From: David Bernier <[EMAIL PROTECTED]>
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 07:57:33 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (CoyoteRed) wrote:
> On Mon, 01 Nov 1999 20:48:11 GMT, [EMAIL PROTECTED]
> (HJS) wrote:
>
> >Why not just take the noise from the loudspeaker? Easier - and no
doubt
> >just as random as all this camera business.
>
> Feed it directly into the computer's A-D converter and mix with a ham
> radio's output.
>
> Or take several samples from a computer mic and mix together.
>
> Or use 50 or so TV receivers ( or AM / FM radios ) and mix the output
> of each sound channel together to get a file. Sample only when you
> encrypt.
>
> Mix these sounds bitwise, not soundwise...
Yes, I agree that taking noise from a loudspeaker is simpler. In fact,
around 1990, I used an FM tuner tuned to a frequency with no
nearby commercial station broadcasting near the chosen frequency as
input to the joystick wires of an 8088-based computer. There was
a function in BASIC allowing to read the X-value and the Y-value
of the joystick. The X-value (say) was influenced in a way I cannot
describe precisely by the audio signal from the power-amp, which was
amplifying noise from the tuner. I would sample the X-value about
200 times, take the parity of the sum of the 200 samples, and obtain
ONE distilled bit as a result. It took several weeks in order to
produce roughly 750,000 "random" digits [0 to 9 inclusive].
My interest here is in bandwidth: audio power-amps have output
with a frequency bandwidth from ~20 Hz to ~20 kHz. My main question is:
<< what household (or other) device could one use that
produces output with a frequency bandwidth into the MHz range?>>
Also, enclosing the entropy generator in a Faraday cage seems to me
to be a reasonable security precaution because:
(a) it attenuates interference from electro-magnetic radiation
coming from the outside...
(b) it makes it harder for eavesdroppers outside the cage to
gain information on the em signals inside the cage. This is
not unlike "tempest" devices, I think (cf [1] ) and it may be
that efficient home-made tempest-like systems can be made
cheaply using mesh wire available in, e.g. hardware stores.
I'm not a physicist, an electrical engineer or a computer scientist,
so I'd welcome comments, especially about household devices that
could be used as high-throughput entropy generators.
Thanks!
David Bernier
[1] http://www.tempestusa.com/
--
http://homestead.deja.com/mathworld/fish_school.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Steganography Academy
Date: Wed, 03 Nov 1999 04:15:02 GMT
On Tue, 02 Nov 1999 18:14:36 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
>break the scott16u contest. I hope my encryption which is orders of
>magnitude stronger than the weak short keyed methods of the AES
>From the Snake Oil FAQ
"Algorithm or product X is insecure
Be wary of anything that claims that competing algorithms or products are
insecure without providing evidence for these claims."
You have stated on numerous occasions the AES finalists are weak, prove it.
Or are you just dealing in snake oil.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Your Opinions on Quantum Cryptography
Date: Wed, 03 Nov 1999 10:04:04 GMT
In article <7vob9h$2ok$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <7vnnus$l2e$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Dear All,
> >
> > I am preparing a short paper on Quantum Cryptography. I would be
most
> > grateful if you could give your opinion/thought/knowledge on the
> > following points:
> >
> > 1. Is there a need for Quantum Cryptography?
>
> No. Modern cryptography is strong enough. Quantum key exchange might
> prove usefull.
>
> > 2. Will Quantum Cryptography reach a phase where it can be
implemented
> > over long distances successfully?
>
> Probably. Will martians invade earth at the same moment all three
laws
> of thermodynamics are broken?
>
> > 3. Will Quantum Cryptography become a neccesity against increasing
> > advanced crypto attacks?
>
> I thought quantum computers were used TO BREAK modern cryptography...
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Tom, from you last point it seems you've confused quantum cryptography
with quantum computing. The two things are quite different, although
based on Quantum physics.
Thanks for the feedback anyway
VivS
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 12:08:50 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> So you don't really need cryptological security at all then?
Now you are annoying. What if my message is in transit?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 12:14:03 GMT
In article <7vobl1$32s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I have recently been playing with peekboo, and find it to be a neat
way
> of encrypting email with minimum overhead. However, I questioned Tom
> about the lack of password protection, and am pleased that he is
> considering implementing one. I like PGP and use it, but it is pretty
> heavy duty (and requires an install) for what I need. peekboo might
be
> a good additional product.
Thanks for the feedback. Here is my response:
I will add an optional password protection feature on the dat file. It
will let the user choose whether they need to encrypt there file.
I would suggest you join the mailing list (info on the website) and
watch out for a next release. I still want to add file crypto [some
shared routines now :)].
I have taken enough flak from this, and well you guys are my quasi-
customers [and the customer is always right].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Removal of bias
Date: Wed, 03 Nov 1999 12:15:44 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Could anyone give references to practical results of removal of
> bias in random number/bit sequences, showing the efficiency of
> the techniques? Thanks in advance.
>
> M. K. Shen
Efficient?
For x = 0 to size
Ax = 0
For y = nx to nx + n
Ax = Ax xor By
next y
next x
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: unpacker to trace code
Date: Wed, 03 Nov 1999 12:16:38 GMT
In article <[EMAIL PROTECTED]>,
Virginie Robbins <[EMAIL PROTECTED]> wrote:
> Anyone knows a good unpacker to trace code ?
For windows? dos? beos? linux? win32? ???
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 03 Nov 1999 13:46:38 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> I see your point, but this wouldn't work with email for example. Here
>> the choice of cipher must be made by me alone.
>
>How so? In a PK environment one would publish one's cipher set along
>with one's public key. It's still the intersection of the cipher sets
>of the two parties.
Let's see: Normally, I compose the message and encrypt it off-line,
then I connect to Internet and send all my mail in batch mode. Oh, I
suppose I could encrypt it after connecting to the Internet and after
downloading a certified set of each addressee's set of ciphers and
choosing a cipher for each one. I suppose this can be done, but it
looks complicated. What if none of the ciphers in one addresse's set is
trusted by me? What if my addressee does not have public keys? What if
my addressee uses a different PK protocol? What if I want to send one
message to 100 destinations?
More importantly: what if the standard (or widely used) PK system
suffers a catastrophic failure in the future? This is more probable to
happen with PK than with a symmetric cipher. Therefore it is even more
important to be able to change PK environments.
(...)
>I would fear such a central repository. It adds a third party to the
>system, and that third party is going to be vulnerable to attacks that
>the original parties would not.
A third party is not necessary if a group of people stick to a few
ciphersuites. Then I just have to name one key exchange protocol (or
several to be executed in parallel) and one cipher (or several to be
executed in series). Also consider that a PK environment normally
involves third parties too. In a networked world third parties are a
fact of life.
Now, I don't claim that my suggestion is the best solution or that
public servers are an indispensable component to any solution. What I
do claim is that it is worthwhile to think about the feasibility of a
"protocol of protocols". I want to be able in the future to dynamically
change ciphersuites as a defense against unforeseen attacks and
catastrophic failures. The Y2K error is so costly because so many
programs all around the world are using one single, stupid (and de
facto standard) data structure. We should learn from that experience
and try to avoid a situation in the future where somebody discovers
that a standardized cryptographic primitive that forms part of almost
all security software is useless. In other words let us define a high
level standard that explains how to change a low level standard.
>I also have an aversion to downloading security code on demand. It
>appears to me to be the inverse of a trojan. instead of an opponent
>penetrating my firewalls, security, permissions, etc. by subterfuge. I
>actually invite them in by regularly replacing the critical security
components of my infrastructure from an external source.
Trojan horses are a huge problem but I wonder if a few trusted central
servers of certified code would not work *against* Trojan attacks. In
my original message I suggested that you should be able to instruct
your "code downloader" to only fetch code trusted by you. For example,
you could instruct it to only download code certified by NIST or, if
you prefer, by Schneier as well as by Shamir. Also *all* ciphersuites
in the central servers should be in source code too - a big problem
(but not insurmountable) for Trojan Horse designers. Finally, loading
new code can be a fully manual process.
Anyway, I see what you mean. In many cases you would never want to use
the centralized code servers but you would be glad they are there just
in case something extraordinary happens. For example: many applications
will happily use the AES main winner as the only symmetric cipher
primitive. Other more conservative applications may include code for
both the AES-1 and the AES-2 winner (assuming NIST does choose two
winners), just in case that something very bad happened to AES-1. Now
you may argue that it is highly unlikely, but it is still realistically
possible that both AES-1 and AES-2 suffer a sudden catastrophic failure
in 50 years time. Then you will want to be able to instruct your
application to download the new cipher X from a centralized server - or
at least be able to introduce cipher X directly into the application.
Let us trust in standards, but let us also be prepared.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 03 Nov 1999 14:11:21 GMT
In article <7vdek7$bia$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Vernon Schryver) wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
>
> > ...
> >IMO, to maintain any hope of improving security, you need to ensure
> >that the cipher used in the negotiation phase is _different_ from
any
> >of the ciphers that can be selected by the negotiation.
> >
> >If the protocol allows the same cipher to be used both for
negotiation
> >and for messages, then breaking that single cipher allows a MITM to
> >force the same cipher to be selected with the negotiation as well,
so
> >he can then break the messages being sent.
> >
> >By NOT allowing the same cipher to be used for both negotiation and
> >messages, the opponent has to break both the negotiation-phase
cipher
> >and at least one more before he can really accomplish anything.
>
> That's a good insight on the hole, but the fix is not sufficent.
>
> A man in the middle who has broken the initial cipher could prevent
what
> the PPP community calls "convergence" on choosing the next cipher.
The
> bad guy could modify the negotiating to ensure that there is no
common
> cipher or make it seem to each peer that the other does not agree.
Since
> Terry Ritter insists that the negotiating is done in what he calls
the
> background (just like some PPP protocols including compression)
without
> notice to the users as user data is passed, the bad man in the middle
> could force the entire session to be run in the broken cipher without
the
> users knowing.
If we are using Mr. Ritter's protocol, we will not start
dynamic cipher negotiation until *after* a secure and
certified (if necessary) link is established. There is
no man-in-the-middle, because if there were, that would
be identified by public key certification, or by the fact
that the MITM does not have the message or session keys,
and therefore cannot modify the ciphertext without
detection.
If the original key-exchange is broken, cipher negotiation
is not going to help. And if the original cipher, or the
message or session keys are broken (!!!), we had better be
using different, unrelated keys and other cipher layers to
protect the negotiation better than the data. Then we could
negotiate a different cipher which might terminate the
existing break, which would seem to be more than any single
static cipher could do.
Dynamic cipher negotiation is intended to support the
dynamic change of ciphers, which terminates any existing
break, and also allows new cryptanalytic results to
move an earlier cipher out of use. The act of changing
ciphers frequently also reduces the amount of ciphertext
under any one cipher, thus reducing the advantage of
breaking that cipher, and hides which ciphertext is
related to which cipher, which is an essential part of
most attacks. But dynamic cipher negotiation is *not*
the one solution to all possible security problems.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Wed, 03 Nov 1999 14:27:21 GMT
In article <7vdr1q$5ng$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > David Wagner ([EMAIL PROTECTED]) wrote:
> > : Hmm. I didn't realize that was what you meant by a
non-cryptographic
> > : negotiation. If it's encrypted, it sounds cryptographic to me.
> >
> > Although it was noted early on as being encrypted, I think the
intent was
> > to state that the protocol need not be an elaborate one with
special
> > properties; except for being enciphered, other special measures do
not
> > seem to be obviously required.
>
> I'm not convinced (yet).
>
> First, there are the obvious protocol attacks.
>
> If it's encrypted, it'd better be MAC'ed as well -- otherwise there
might
> well be ciphertext tampering attacks (e.g., truncate the ciphertext
> to delete some of the sender's proposed ciphers).
Yes, of course. Every cipher should have (and all of my cipher
systems do have) some sort of hash of the data which allows us
to detect ciphertext modification. In an overall system which
coordinates email exchanges, there may well be sequence numbers
as well.
>Also, you have
> to worry about replay attacks -- so does that mean we need to add a
> challenge-response prelude to the negotiation protocol?
Sequence numbers.
>And as
someone
> else pointed out, we better make sure the cipher we use to encrypt
the
> negotiation protocol is different from the cipher we use to encrypt
> the rest of our traffic, because otherwise we have a huge single
point
> of failure.
Fine.
> Once you start getting into this level of complexity, I have to
wonder
> whether the claim that "it need not be elaborate" is truly realistic.
But what else could possibly be "realistic" in a deployed
cipher system? Do you seriously suggest that one would
build a cipher system *without* (effectively) having
error-detection on the plaintext or ciphertext? So that,
at least, would seem to be there already.
The whole point of such a system is to change ciphers,
which implies that we have multiple or many ciphers, any of
which can be used. Is it then an "elaborate" extension to
allow different or additional ciphers for the dynamic
cipher negotiation? I think not.
> Second, there are the obvious implementation issues.
>
> Usually if we need a cipher negotiation protocol, it's because we
don't
> know a priori of any ciphers that are strong enough to satisfy
everyone
> and yet are implemented everywhere. (After all, if we had one, we'd
just
> use it for encrypting all our traffic.)
That is only one part of the goal, and perhaps the lesser
part. Just finding one cipher which we can agree upon does
not give us the dynamic cipher changes which: (1) terminate
existing breaks, (2) reduce the amount of information under
any one cipher, and (3) hide the correspondence between
cipher and ciphertext, as most attacks require.
>But now we've got a
bootstrapping
> problem: how do we pick which cipher to encrypt our negotiation
under?
> We could precede it with another negotiation protocol, but that'd be
silly.
Yes, that would be silly.
> So I'm not convinced that cipher negotiation is as trivial as it is
> made out to be. In fact, experience (SSL, SSH, etc.) seems to
suggest
> exactly the opposite.
Any protocol is going to be more complex than not having
a protocol. Presumably, the simpler we make that protocol,
the better off we are. By making it a simple selection
instead of some horribly complex (and equally unprovable)
cryptographic protocol, we have a better chance to understand
it well and implement it well.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: An encryption proposal from a Newbie...
Date: Wed, 03 Nov 1999 14:29:44 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On Wed, 03 Nov 1999 03:50:06 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>CoyoteRed wrote:
>> It has nearly the security of a OTP, it's not as secure because ...
>
>Your example had a lot of discrepancies, but it didn't seem
>very "secure" to me... How are you determining its "security"?
Could you please point out the discrepancies.
The security that I am after is near that of a OTP. Now transfering
your random number to be decrypted is a problem. You have to do it
everytime and thus doubles your message. Then encrypting the your
random number with a assymetrical key is realitively slow. So you
have really secure encryption that is large and slow, it weakness
becomes the securely of your random number.
So to get around the need to send your RN every time we set up a few
random numbers and send them ahead. We then combine these numbers in
various combinations to get other numbers, but not just one number and
use some sort complex math that may be guessed. Thus we get /a lot/
more random number sequences AND we don't have to double our message
size.
If we wanted, we could use each combination only once, avoid any
"weak" combinations and approach the security of a OTP without the
most of the drawbacks.
But, that's what I'm thinking anyway.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: An encryption proposal from a Newbie...
Date: Wed, 03 Nov 1999 14:29:43 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On 3 Nov 99 12:47:01 GMT, [EMAIL PROTECTED] () wrote:
>
>I think some schemes of this type have been proposed and used in real
>life. IBM has SEAL, and there was another scheme based on a large pool of
>random numbers that was even exportable because it included key escrow.
I thought it couldn't have been an original idea... :)
>
>One weakness is that you're sending the 64 bit key in the clear, and it
>*could* be a key with very few 1 bits in it.
Well, the key would encrypted with an asymmetrical key. See "Next, we
use our partners public key to encrypt our 65 bit index key
and add it to the beginning of our ciphertext." in my message.
One thing I thought of is if the attacker ever broke the asymmetrical
system and he could go back and decrypt all of the previous messages
and get these index keys. Now if we had ever used a index key with
only 1 bit "on" then he has that one 1k file, bang, in the clear and
that message (or portion) is decrypted. We would have to test for
"weak" keys. So therefore we would have somewhat less than 2^64
possible indexes and thus possible random files.
>
>This could be dealt with by using a 4 of 8 code; the combinations of 8
>bits where four of them are 1 bits and four are 0 bits happen to be 70 in
>number, so 6 bits could be used to pick one of them. Do that after
>encrypting the key (now only 48 bits long) with a key-exchange key.
You know off the top of your where this is explained on the internet?
I would like to learn a little more about 4 of 8 code.
>
>If the key is exchanged in the clear, one can deduce information about the
>contents of the 1K files if two keys happen to differ by only one bit, for
>example.
Key is not exchanged in the clear, I meant it to be encrypted with an
asymmetrical key. But I see your point about even a 1 bit
/difference/, because that 1 bit difference would give him one of
those files. (Well, not all of it if it was one of the last "blocks"
because in all likelihood not all of it was used.)
>
>While such a system doesn't have the absolute security of a true OTP, it
>may indeed have some security. Since one is only doing an XOR, there may
>be other weaknesses besides the ones I've thought of, though.
I'm also running with the idea that you can XOR any combination of
these 1k files and get an equally random file out. If you can, then
the strength relies on the 64 bit index key and it's protection. But
once the key's protection is broken then we have to rely on not using
any "weak" keys.
As I see it so far, a "weak" key is a key that is only 1 bit off from
a previously used key (which also then becomes "weak.") This would
mean that we automatically cut our number of usable keys by half.
(...and much more if my suspisions are correct.) So, the next question
is: just how many strong keys do we have and how do we get back to
having more strong keys?
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 14:38:51 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On Wed, 03 Nov 1999 07:57:33 GMT, David Bernier <[EMAIL PROTECTED]>
wrote:
>Also, enclosing the entropy generator in a Faraday cage seems to me
>to be a reasonable security precaution because:
>(a) it attenuates interference from electro-magnetic radiation
> coming from the outside...
This is good because you may pick up noise from motors and such that
is not random.
>
>(b) it makes it harder for eavesdroppers outside the cage to
> gain information on the em signals inside the cage. This is
> not unlike "tempest" devices, I think (cf [1] ) and it may be
> that efficient home-made tempest-like systems can be made
> cheaply using mesh wire available in, e.g. hardware stores.
I think by the time this become a concern, then we would have to start
thinking about a lot more physical security than just a Faraday Cage.
:( Ouch!
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: announcement: steganography program "steghide"
Reply-To: [EMAIL PROTECTED]
Date: Wed, 03 Nov 1999 15:23:43 GMT
On 3 Nov 1999 03:09:27 GMT, David A Molnar wrote:
>
>then it seems that distinguishing the encrypted message from random
>would imply predicting the PRG. which is supposed to be hard. and if we
>have confidence that the message is random, it becomes easier to find
>places to put it in the carrier file.
>
i think you are right a pseudo random generator (with a seed derived
from a secret key and data from the carrier file), should make it
appears as random.
but i though more during the night and i am not sure that my requirement
'to have a message which appears random' was a good one.
suppose the original carrier file contains some patterns known by the
attacker, the absence of these patterns will reveal the message.
'the aim is to have the message mimics the former pattern (or absence
of patterns) contained in the original file' seems better to me.
In the application on jpeg pictures, modification of the resolution
and the loss rate makes probably the least significant bit of each
pixel reasonably random. So hard to distinguish it from by a message
which appears random. But the randomness of this least signicant bit
has to be checked.
maybe the work has been already done in this field...
------------------------------
** 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
******************************
