Cryptography-Digest Digest #592, Volume #12 Fri, 1 Sep 00 16:13:01 EDT
Contents:
Re: Question Regarding Encrypting CD-ROM -RW Disks (Mack)
Suggestion (Delanyo Ofori)
Re: R: R: R: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Re: vernam cipher question ("Douglas A. Gwyn")
Re: blowfish problem ("Douglas A. Gwyn")
Re: blowfish problem ("Douglas A. Gwyn")
Re: vernam cipher question (Jim Gillogly)
Re: QKD and The Space Shuttle ("Richard Bembridge")
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed ("Paul
Pires")
Re: 4x4 s-boxes ("Douglas A. Gwyn")
Re: blowfish problem (Hong Ooi)
Re: Suggestion (stanislav shalunov)
Re: blowfish problem ("Trevor L. Jackson, III")
Re: blowfish problem ("Kelsey Bjarnason")
Re: one-time pad question (Jim)
Re: New algorithm for the cipher contest ("Alexis Machado")
Re: one-time pad question (Jim Gillogly)
Re: Patent, Patent is a nightmare, all software patent shuld not be (Mok-Kong Shen)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Capability of memorizing passwords (Mok-Kong Shen)
Re: Steganography vs. Security through Obscurity (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: 01 Sep 2000 17:10:22 GMT
>Mack wrote:
>>
>>All disks are not made of the same
>>material I believe there are three or
>>four different kinds.
>>
>
>Nope. You are confusing the plastic (always optical grade
>polycarbonate) with the dye in the CD-R (different kinds).
>
>Some Laserdiscs use different plastics, but CDs, CD-Rs, CD-RWs,
>DVDs, DVD-RAMs, etc. are all polycarbonate.
>
>Trivia fact: The optical grade polycarbonate that we reject as
>not being optically good enough for making CDs out of mostly goes
>into making eyeglasses and aircraft windows.
>
Thanks for the clarification. I was under the impression
that some disks might have been made of acrylic.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Delanyo Ofori)
Subject: Suggestion
Date: 1 Sep 2000 17:14:03 GMT
All encryption vendors should encrypt their source with their product and
make it available for download
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: R: R: R: Test on pseudorandom number generator.
Date: Fri, 01 Sep 2000 13:38:35 -0400
Cristiano wrote:
> If I collect p-values of Diehard in classes (as a histogram) ...
You lose more and more information, thereby weakening the test.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: vernam cipher question
Date: Fri, 01 Sep 2000 13:41:19 -0400
Jim Gillogly wrote:
> Depending on the nature of the message
> traffic there may be some question about which characters
> go in which message -- M XOR M' doesn't retain that
> information, which must be deduced by context or by finding
> structure in K.
In many cases, one reaches the end of one of the ciphertexts,
in which case the plaintext that continues belongs to the
ciphertext that continues.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 01 Sep 2000 13:44:48 -0400
Kaz Kylheku wrote:
> I would not bother using char for boolean values; rather I would use int or
> unsigned int. To save space in a structure for storing some boolean
> flags, there are bitifields.
Bit-fields are not addressable, which makes them not very useful
in matrix-oriented algorithms, and awkward to name in one's program.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 01 Sep 2000 13:50:25 -0400
"Trevor L. Jackson, III" wrote:
> But in many cases we're stuck with char of indeterminate sign
> because the elements of literal strings have that type.
?? String literals are arrays of char type, and the implementor
determines the signedness of char type for some reason having
nothing to do with string literals. Quite often it is to ensure
that the basic characters have the property that they have
positive codes, e.g. in EBCDIC where the code for '0' is 0xC0
which would have a negative sign if stored in a signed char.
On the PDP-11, operations with signed char tended to be faster
than with unsigned char, due to properties of the instruction set.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: vernam cipher question
Date: Fri, 01 Sep 2000 17:50:55 +0000
"Douglas A. Gwyn" wrote:
>
> Jim Gillogly wrote:
> > Depending on the nature of the message
> > traffic there may be some question about which characters
> > go in which message -- M XOR M' doesn't retain that
> > information, which must be deduced by context or by finding
> > structure in K.
>
> In many cases, one reaches the end of one of the ciphertexts,
> in which case the plaintext that continues belongs to the
> ciphertext that continues.
Quite so -- but since you have only one ciphertext after that
point, if you've found the longer plaintext you must already have
figured out the structure of the key and you can disambiguate
the messages directly.
I think this is why we see VENONA messages beginning or ending
abruptly in the middle.
--
Jim Gillogly
Sterday, 10 Halimath S.R. 2000, 17:48
12.19.7.9.4, 6 Kan 7 Mol, Fourth Lord of Night
------------------------------
From: "Richard Bembridge" <[EMAIL PROTECTED]>
Crossposted-To: sci.space.shuttle,talk.politics.crypto
Subject: Re: QKD and The Space Shuttle
Date: Fri, 1 Sep 2000 18:53:49 +0100
[snip]
> Yes. I didn't pay enough attention at first: he is talking about
> Quantum Cryptography, here referred to as Quantum Key Distribution. So
> he is asking about Shuttle parameters because he is wondering about
> setting up some kind of orbital satellite that uses Quantum
> Cryptography for a secure one-time-pad type link.
[snip]
So what do you think then?
Is it:
(a) impossible, or
(b) highly unlikely, or
(c) beyond current ability, or
(d) not worth it coz Public Key is good enough, or
(e) achievable within the next few decades but prohibitively expensive, or
(f) a definitely feasible program
to carry out such research to eventually get some kind of system in orbit?
How would such a system work?
I find this topic quite stimulating. In an intellectual sort of way.
RMB
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: Fri, 1 Sep 2000 10:51:55 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Thomas Wu wrote:
> >
> > While we're on the subject of nightmare patents, does anybody care to
> > look at US Patent #5222140, "Cryptographic method for key agreement
> > and user authentication"? It appears to cover protocols where the
> > server sends its public key to a client, the client encrypts a session
> > key with that public key, and the server recovers it by decrypting
> > with its private key. Sound familiar to anyone?
If you find someone who enjoys reading and analysing patents, then you
probably have found a masochist or a serial killer. I took a look at the
one stated in this thread because I had been so mean to MKS and
wanted to find some common ground with him. Reading these patents
in an attempt understand it is like getting a circumcision with a belt
sander.
>
> I seems as if most people doing PK today are infringing on
> lots and losts of patent rights. I find it very remarkable
> though that up till now nobody has noticed that (neither
> in this group nor in other crypto mailing lists). Would
> those who have expertise in patents or are comparatively
> knowledgeable in such matters kindly do the favour of
> examining the issues and say something practically useful?
> Thanks.
Not a trivial task. The claims are what matters and they must
be evaluated literally. If you feel that your understanding of all
of the various patents says that nothing much can be done
without interfereing, then your understanding might be wrong
since it seems to conflict with observation. I have a lot of
experience with patents in my own field (not crypto) so I'm
seeing this from a different perspective. I can read the claims
in crypto patents but I do not know the field well and cannot
understand the scope of the words or concepts well enough to
feel confident with them. It's like a cipher with two keys (crypto
knowledge & patent knowledge). If you don't have both, you are
reduced to brute force.
Forget what you see in the body of the patent. It is back ground
and support for the claims. In other words, everything that is
claimed must be tought in the text but everything in the text is not
necessarily claimed. The claims wording defines the coverage AND
limit it's scope. This is a perverse art form. If you are truely interested
you have some studying ahead of you. If you just want to comiserate
with like minded folks, I'll butt out. Have you noticed that those in
a position to know, don't comment. Answering the outrage of these
posts in a fact based way would require a lot of work and would
probably do little good. It also would never end. Each expaination
would be followed by "If thats true, what about US-XYZYXZYX?"
Paul
>
> M. K. Shen
> -------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 4x4 s-boxes
Date: Fri, 01 Sep 2000 14:06:14 -0400
Tim Tyler wrote:
> [EMAIL PROTECTED] wrote:
> : [EMAIL PROTECTED] (Mack) wrote:
> :> bent is usually used to refer to functions which have non-linearity
> :> which is maximum. They only occur on functions of 2n variables
> :> and are not balanced. You appear to be refering to nearly bent
> :> functions.
> : Ahem, according to "Perfect nonlinear Sboxes" by Kaisa Nyberg from
> : Eurocrypt '91, we have and I quote.
> : Definition 2.1: A function F: Zn/q -> Zq is bent if |F(w)| = 1 for all
> : w.
> Bent functions have maximum non-linearity.
Actually the correct definition is the one involving the FT.
There are several ways in which "nonlinearity" might be measured,
Ritter's not being the only one. Any nonlinearity property of
bent functions is a consequence of the FT-based definition,
and would depend critically on the way one defines the measure
of nonlinearity. It is true that under a reasonable definition
of nonlinearity, bent functions are necessarily highly nonlinear.
>From the cryptanalytic point of view, the FT property is more
important.
------------------------------
From: Hong Ooi <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 02 Sep 2000 05:24:30 +1100
On Fri, 01 Sep 2000 00:11:02 GMT, "Kelsey Bjarnason"
<[EMAIL PROTECTED]> wrote:
>[snips]
>
>"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>
>> >might be promoted to "int" when used in an expression but that
>> >isn't quite the same. No?
>>
>> In what context would a character constant not be used in an expression?
>
>I think he might be getting at the implicit silliness of the following:
>
>char c;
>
>c = (char) 'a';
>
>Since it's a char value, and since it's being assigned a char, why is the
>cast necessary? It shouldn't be... but if 'a' is an int rather than a char,
>one might presume that unless char and int are the same size on your
>implementation, you're risking compilation warnings ("Possible loss of
>precision assigning int to char" or some such).
Which compiler does this? Neither VC++, gcc nor Solaris cc warn about
converting an int in the range CHAR_MIN to CHAR_MAX to char. (They will
warn about truncating ints outside that range, but that's something else
entirely.)
>
>In such a case, the notion of character constants actually being ints seems
>bizarre in the extreme.
I agree that's odd, but then I'm a C newbie.
--
Hong Ooi | Centre for Maths and its Applications/
[EMAIL PROTECTED] | Research School of Inf. Science & Engn.
Ph: (02) 6267 4140 | Australian National University
| ACT 0200 Australia
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: Suggestion
Date: 01 Sep 2000 14:35:25 -0400
[EMAIL PROTECTED] (Delanyo Ofori) writes:
> All encryption vendors should encrypt their source with their product and
> make it available for download
It would be hard to distinguish between random data and encrypted
source.
Besides, if the source isn't available (unencrypted) you probably
don't want to use the product anyway.
--
Stanislav Shalunov Internet2
"APL is a write-only language. I can write programs in APL, but I
can't read any of them." -- Roy Keir
------------------------------
Date: Fri, 01 Sep 2000 14:46:44 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
"Douglas A. Gwyn" wrote:
> "Trevor L. Jackson, III" wrote:
> > But in many cases we're stuck with char of indeterminate sign
> > because the elements of literal strings have that type.
>
> ??
I think the point Kaz was making is that one cannot assume either form
of signedness in portable programs. One is left with the intersection
of two types, which is often uncomfortably small.
> String literals are arrays of char type, and the implementor
> determines the signedness of char type for some reason having
> nothing to do with string literals. Quite often it is to ensure
> that the basic characters have the property that they have
> positive codes, e.g. in EBCDIC where the code for '0' is 0xC0
> which would have a negative sign if stored in a signed char.
> On the PDP-11, operations with signed char tended to be faster
> than with unsigned char, due to properties of the instruction set.
Interesting. Must have been the versions before my time. I recall
nothing special about signed chars on -35, -60, -70, and the LSI-11
subfamily.
------------------------------
From: "Kelsey Bjarnason" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 01 Sep 2000 18:48:24 GMT
[snips]
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >c = (char) 'a';
> >
> >Since it's a char value, and since it's being assigned a char, why is the
> >cast necessary? It shouldn't be...
>
> Not only is it not necessary, it does nothing useful. The expression
> (char) 'a' promotes back to type int.
> >one might presume that unless char and int are the same size on your
> >implementation, you're risking compilation warnings ("Possible loss of
> >precision assigning int to char" or some such).
>
> That is not a diagnostic required by ANSI C and only a braindead compiler
> (MSVC?) would produce it an assignment from a character constant,
> not realizing that the constant has a suitable range to convert to a char
> without loss.
Never seen such from MSVC. However, since int and char frequently do not
have the same size, which means non-casted conversions _do_ potentially risk
data loss, a compiler should be perfectly within its rights to issue a
diagnostic here. Worse, as you point out up above, casting does _not_
remedy the situation, so therefore a compiler is perfectly within its rights
to *always* give warnings about this assignment.
Weird. Very weird. So much for those shops that insist on clean compiles.
:)
Yeah, okay, as a QOI issue a compiler that can't tell that the constant is
small enough to fit might rate a few raised eyebrows, but that doesn't make
issuing the warning an invalid action.
>
> >In such a case, the notion of character constants actually being ints
seems
> >bizarre in the extreme.
>
> It must have seemed that way to the C++ folk, because character constants
> have type char in that language. (The actual reason is to allow for finer
> grained overload resolution; the function call foo('x') will choose a
> void foo(char) candidate over, say, a void foo(int) candidate).
Yeah, well, C++ introduces its own headaches and weirdness. :)
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: one-time pad question
Date: Fri, 01 Sep 2000 19:24:56 GMT
Reply-To: Him!
On Thu, 31 Aug 2000 22:36:38 GMT, [EMAIL PROTECTED] (Mr. Ian E. Yolk)
wrote:
>Emery Conrad <[EMAIL PROTECTED]> wrote:
>
>>can someone explain to me (or point me to some resource) that explains
>>how one can crack a one-time pad whose key is not perfectly random. i'm
>>not sure i believe it can be done (in any but the most obvious of
>>patterned data).
>
>It's quite possible that at least in some cases, you're right and it can't
>be done. The main reason that pure randomness is stressed in the
>description of a one time pad is that the mathematical proof that the
>method is secure depends on that provision, among other things. A
>technically non-random pad might still be secure, but you won't be able to
>prove it.
So it must follow that, because the perfectly random key does not
exist, that any and all OTP can be broken?
--
Jim Dunnett
amadeus at netcomuk.co.uk
nordland at lineone.net
g4rga at thersgb.net
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Fri, 1 Sep 2000 16:38:14 -0300
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:8o8rni$ehm$[EMAIL PROTECTED]...
>
> I believe I have a way that, given K[3] (which is the fourth
multiplicative
> key), distinguishes it from randomness with a relatively few amount of
> chosen plaintexts and effort, and the actual chosen plaintexts do not
depend
> on K[3]. This immediately leads to a method of rederiving K[3] with about
> O(2**64) effort and circa 100-1000 chosen plaintexts. (It actually
consists
> of two tests, and the success rate of either depends on the value of K[1],
> and they both combined cover the entire range of K[1]'s)
>
> Outline of Nimbus (which is what he calls the cipher in the
documentation):
> - He treats the plaintext data as a 64 bit word
> - A round (in the encrypt direction) consists of:
> - Xoring in key dependent value into the data word. This key dependent
> value is called K[4]..K[7] in the documentation
> - Reversing the order of the bits of the data word (so bit 63 gets moved
> into bit 0). He calls this operation "mirroring" in the literature.
> - Multiplying (mod 2**64) a key dependent odd value into the data word.
> This key dependent value is called K[0]..K[3] in the literature
> - The cipher consists of 4 of these rounds. I will assume that the key
> dependent words used in each round is independently chosen.
>
> Now, assume the attacker knows K[3]. Then, he can logically strip out the
> last multiplication (by taking any ciphertext he has, and multiplying it
by
> the inverse). In addition, since my attack will care only about bit
> differentials, we can also ignore the xor/mirror steps in the fourth
round,
> because they do nothing to mask that.
>
> The first test is as follows: encrypt pairs of plaintexts. Each pair has
an
> xor differential in bit 0, and has common random data in the other bits
(and
> the randomness assumption is importent). Following through the pair
through
> the cipher, we see that, after the first round, that pair now has an xor
> differential in bit 63 and random data in the other bits. Then, in the
> second round, the xor does not affect the differential, and the mirror
> changes it so the values has an xor differential of 1, or as it is more
> convienent to look at it, an additive differential [1] of 1. This means
> that, after the multiplication, the values has an additive differential of
> K[1], and since we are at a random point, this means that there is a
> differential in bit 63 with probability P = K[1] / 2**63 if K[1] <= 2**63
> and P = 2 - K[1] / 2**63 if K[1] >= 2**63. Then, after round 3, bit 0
will
> have a differential with probability P. If P is greatly different from
1/2,
> that is, if K[1] is far from either 2**62 or 2**62+2**63, then a
relatively
> few number of pairs will distinguish it, in that bit 0 of round 3 will
have
> a differential either much more often than expected, or much less often
than
> expected.
>
> The second test is as follows: encrypt quads of plaintexts, each quad
> consisting of all four distinct bit 0/bit 1 values, and common random data
> in the upper 62 bits. Then (following the logic above), after the second
> multiplication, the quad will be X, X+K[1], X+2K[1], X+3K[1] in some
order.
> If K[1] is approximately 2**62 or 2**62+2**63, then these values will have
> four different values in the upper 2 bits with good probability, and so,
> after the third round, each of the quad will have a distinct value in the
> lower 2 bits with much higher probability than randomness, and so that
> yields a distinguisher when K[1] is in the right range.
>
> By some odd coincidence, the second test yields a distinguisher exactly
when
> the first test does not. So, no matter what K[1] is, we have a
> distinguisher (and, as a side bonus, we gain some information on K[1])
>
> [1] In this case, I refer to an additive differential of K as meaning that
> the pair is (X,X+K), without regard to which of the pair is X and which is
> X+K.
>
I could verify that the 3rd round outputs the differentials as stated by
Scott. In the 4th round this effect stops, leading to a O(2**64)
choosen-plaintext method. I think it's an excellent work and helped me to
understand this cipher better.
After talking to Scott, I decided (for precaution) to propose the addition
of one more round. The encrypting function would become:
Block CipherBlock (Key K, Block B)
{
B = Mirror(B ^ K[5]) * K[0];
B = Mirror(B ^ K[6]) * K[1];
B = Mirror(B ^ K[7]) * K[2];
B = Mirror(B ^ K[8]) * K[3];
B = Mirror(B ^ K[9]) * K[4];
return (B);
}
This doesn't add any complication to the cipher. Scott's method applies in
the same way, but now is O(2**128).
If someone disagrees about the modification necessity, please post comments.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: one-time pad question
Date: Fri, 01 Sep 2000 19:46:10 +0000
Jim wrote:
>
> On Thu, 31 Aug 2000 22:36:38 GMT, [EMAIL PROTECTED] (Mr. Ian E. Yolk)
> wrote:
> >be done. The main reason that pure randomness is stressed in the
> >description of a one time pad is that the mathematical proof that the
> >method is secure depends on that provision, among other things. A
> >technically non-random pad might still be secure, but you won't be able to
> >prove it.
>
> So it must follow that, because the perfectly random key does not
> exist, that any and all OTP can be broken?
No, Mike said the opposite: it might still be secure, but there's no proof
available if the key isn't random.
If a key is non-random in some known way, then information is leaked.
Perhaps not enough to break an intercepted "OTP" with ciphertext only,
but quite likely enough to determine with an adequate level of
confidence whether a particular long ciphertext message matches a
particular known plaintext. This may not often be a useful test, but
it does demonstrate that some information is leaked, and thus the
"OTP" is no longer perfect.
--
Jim Gillogly
Sterday, 10 Halimath S.R. 2000, 19:39
12.19.7.9.4, 6 Kan 7 Mol, Fourth Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be
Date: Fri, 01 Sep 2000 22:15:46 +0200
Paul Pires wrote:
>
> Forget what you see in the body of the patent. It is back ground
> and support for the claims. In other words, everything that is
> claimed must be tought in the text but everything in the text is not
> necessarily claimed. The claims wording defines the coverage AND
> limit it's scope. This is a perverse art form. If you are truely interested
> you have some studying ahead of you. If you just want to comiserate
> with like minded folks, I'll butt out. Have you noticed that those in
> a position to know, don't comment. Answering the outrage of these
> posts in a fact based way would require a lot of work and would
> probably do little good. It also would never end. Each expaination
> would be followed by "If thats true, what about US-XYZYXZYX?"
It's fine what you said. But if one is truly interested,
say, in one of the patents mentioned in this thread, how
is he going to start his 'study' properly? Apparently
'chewing' the English text of the patent (as is available
on the web page) wouldn't be fruitful, no matter how hard
one tries, isn't it?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Fri, 01 Sep 2000 22:15:38 +0200
"John A. Malley" wrote:
>
> Has anyone established the necessary and sufficient mathematical
> characteristics required of a mixing/scrambling function taking n
> predictable PRNGs into one unpredictable PRNG output? Many researchers
> point to one-way functions as the scrambler of choice. Few (if any) have
> I read that discuss the characteristics of the mixing function - but
> that's probably because I'm not looking in the right journals/web sites.
> (If anyone knows of such papers please tell me. Thanks.) This is an
> interesting area for analysis!
I am also interested to learn of research results in that
area.
Efficient and highly unpredictable pseudo-random sources
are particularly valuable, I believe, for use to
steer/control block encryption algorithms that are variable,
i.e. having parameters that can be changed from block to
block thus rendering opponent's analysis more onerous than
algorithms that are 'fixed'.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Capability of memorizing passwords
Date: Fri, 01 Sep 2000 22:16:04 +0200
It is often said that it is difficult for people to
memorize random passwords (commonly 8 characters). I am
very surprised to read in a magazine that the record of
memorizing a bit sequence, given a time of 30 minutes, is
2745 bits! So brain's capability of processing random
stuffs doesn't seem to be too bad after all.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: Fri, 01 Sep 2000 22:15:59 +0200
zapzing wrote:
>
> Don't you think it will look somewhat suspicious,
> all this random data being sent around ?
One of the best way, I suppose, is to publish some
commonly useful data, e.g. some daily or weekly
collected physical measurments, on a web page and embed
the message data in them. That way it's difficult to
trace out the recipients who access these to get the
messages.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
** 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
******************************
