Cryptography-Digest Digest #156, Volume #14 Sun, 15 Apr 01 23:13:01 EDT
Contents:
interesting site (newbie)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: LFSR Security (David Wagner)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: LFSR Security ("Tom St Denis")
Re: please comment (Darren New)
Re: MS OSs "swap" file: total breach of computer security. (Darren New)
Re: MS OSs "swap" file: total breach of computer security. ("Tom St Denis")
Re: NSA is funding stegano detection (Bernd Eckenfels)
Re: MS OSs "swap" file: total breach of computer security. (Ben Cantrick)
Re: NSA is funding stegano detection ([EMAIL PROTECTED])
Re: Reusing A One Time Pad ("Scott Fluhrer")
Re: Why Not OTP ? ("Douglas A. Gwyn")
Re: NSA is funding stegano detection ([EMAIL PROTECTED])
Re: Function other than xor? ("Douglas A. Gwyn")
Re: Lorentz attractor... ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: interesting site
Date: Sun, 15 Apr 2001 20:25:15 -0300
http://citeseer.nj.nec.com
I discovered this very interesting site when you can download for free a
lot of articles about crypto.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 19:49:02 -0500
> If your method generates new pads such that all bitstrings
> are equally probable and independent of previous pads, then
> the perfect secrecy theorem still applies. Doing so will
> require additional entropy (that is, entropy not taken from
> the previous pads) sufficient to generate the new pad
> directly, so I don't see the new pad as re-use of the old
> one in any meaningful sense.
Well, that's just it, the reuse wouldn't be totally independent. What I'm
trying to get at is how practical it would be to take a modestly large pad
and rotate through it for "fairly" secure everyday use. I'm not talking
national security here. It would obviously depend on how often you used it
over a given period of time. I mean even if you used the same pad many
times over a long period you'd have to assume that someone was actually
collecting all your messages, which is not very likely.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: LFSR Security
Date: 16 Apr 2001 00:52:27 GMT
Graywane wrote:
>What I was fishing for was a reason why. [...]
For one, it is likely to be much slower than ciphers than modern
ciphers like AES. For another, without serious study it is hard
to gain any confidence that it is secure. Since existing ciphers
like AES are both faster and better-studied than this proposal,
what possible motivation could we have to use a scheme like this?
Also, large pads have serious key management issues that make them
basically unworkable in most practical settings.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Mon, 16 Apr 2001 00:59:02 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bdfjg$1v8m$[EMAIL PROTECTED]...
> > If your method generates new pads such that all bitstrings
> > are equally probable and independent of previous pads, then
> > the perfect secrecy theorem still applies. Doing so will
> > require additional entropy (that is, entropy not taken from
> > the previous pads) sufficient to generate the new pad
> > directly, so I don't see the new pad as re-use of the old
> > one in any meaningful sense.
>
> Well, that's just it, the reuse wouldn't be totally independent. What I'm
> trying to get at is how practical it would be to take a modestly large pad
> and rotate through it for "fairly" secure everyday use. I'm not talking
> national security here. It would obviously depend on how often you used
it
> over a given period of time. I mean even if you used the same pad many
> times over a long period you'd have to assume that someone was actually
> collecting all your messages, which is not very likely.
And what you don't get is that from the pad (0,1) it's conceptually the same
thing....
To encrypt repeatedly you must slice and dice and copy+paste the old pad
right? Where does the entropy come todo this? Ah... the new entropy is a
new key... and it's just as secure as an OTP if it's used to select new bits
with random probabilities (obviously the pad (0,0) is degenerative and
(0,0,0,0,0,1) is too far biased, etc...)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: LFSR Security
Date: Mon, 16 Apr 2001 00:59:51 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9bdfob$t5l$[EMAIL PROTECTED]...
> Graywane wrote:
> >What I was fishing for was a reason why. [...]
>
> For one, it is likely to be much slower than ciphers than modern
> ciphers like AES. For another, without serious study it is hard
> to gain any confidence that it is secure. Since existing ciphers
> like AES are both faster and better-studied than this proposal,
> what possible motivation could we have to use a scheme like this?
>
> Also, large pads have serious key management issues that make them
> basically unworkable in most practical settings.
Just to add to this.
Imagine working with a microcontroller unit (MCU) where you only have 1kb of
code space and say 128 bytes of ram.....
Tom
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: please comment
Date: Mon, 16 Apr 2001 01:07:33 GMT
> > > If the user is a dolt
> >
> > ... or honest, or getting charged less than the cost of breaking it, or
> > getting charged less than the cost of getting caught breaking it, ...
>
> Getting caught breaking it? What are they gonna do, send you to jail? LOL!
I was thinking of the case where the company doesn't want the employees
using the program to get caught using it and not paying. Imagine a similar
situation, where a company buys a site license, yet still wants copy
protection on the software so the employees don't take it home illegally. In
such a situation, the company is showing the software vendors that they are
indeed abiding by the license.
It's not always as simple as Alice vs Bob. :-)
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
schedule.c:7: warning: assignment makes calendar_week
from programmer_week without a cast.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Mon, 16 Apr 2001 01:10:58 GMT
Steve K wrote:
> >If you have sufficient RAM then the swap file, apparently, is not
> >utilized.
>
> In Win98, the swap file is in constant use. That includes idling with
> no active processes except the kernel and GUI.
Well.... You can turn off the swap file entirely. And if it was in constant
use, the disk drive would never spin down. Which it does. So I'm not sure
how either of those cases counts as "constant use".
> At least that is what I found with a swap file monitor, examining my
> own system which has 98 MB of RAM.
Try going into "system -> performance" in the control panel and turning off
VM.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
schedule.c:7: warning: assignment makes calendar_week
from programmer_week without a cast.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Mon, 16 Apr 2001 01:22:10 GMT
"Darren New" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Steve K wrote:
> > >If you have sufficient RAM then the swap file, apparently, is not
> > >utilized.
> >
> > In Win98, the swap file is in constant use. That includes idling with
> > no active processes except the kernel and GUI.
>
> Well.... You can turn off the swap file entirely. And if it was in
constant
> use, the disk drive would never spin down. Which it does. So I'm not sure
> how either of those cases counts as "constant use".
There can be stuff in the swap file without constant disk writting. If you
let the machine idle long enough obviously it will shut it down... but if
you repeatedly open and close MSIE it will never shut down even if the app
is in the disk cache.
> > At least that is what I found with a swap file monitor, examining my
> > own system which has 98 MB of RAM.
>
> Try going into "system -> performance" in the control panel and turning
off
> VM.
Ahh but alot of apps need VM to work. A better solution is to just lock
memory... INSTEAD OF BEING A COMPLETE FRIGGIN IDIOT!!!!!
Sure and while we are it, we will make the users destroy their hd's to avoid
having information being leaked... then we will labotomize them to avoid the
person actually giving away the info...
Tom
------------------------------
From: Bernd Eckenfels <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: 16 Apr 2001 01:23:46 GMT
In comp.security.misc Walter Roberson <[EMAIL PROTECTED]> wrote:
> On the other hand, the data may be compressed. Compression works
> by reducing redundancy, so the compressed data is "more random".
> Any compression algorithm that leaves statistically-detectable
> correlation in its file, could theoretically be improved [but improving
> the algorithm might be difficult as a practical matter.]
The Problem is not detecting correlatrions in the stegano data, the problem is
that adding to the noice of a existing data source will change the
characterisitics of the "natural" noise. So if you do not model the changing
of the bits after the equipment used to capture the transport-data-stream
(audio, ccd picture, scan picture) an analysis can quite easyly tell you that
"that kind of noise is not produced by an ccd cam". Or even worse, if you add
bits to compressed dataa like JPG you might generate pixel patterns which "are
never created by one of the well known JPG cmpressors".
Same is true for, lets say space formated text in block-formating. If someone
suspects you used stegano, hidden in the spaces, he asks you to show the
program which formated the long text that way... if you do not have an nroff
which does it... (of course this is not a proof that u used stegano, but at
least it is a good first sign).
Greetings
Bernd
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: 15 Apr 2001 20:01:07 -0600
In article <[EMAIL PROTECTED]>, Darren New <[EMAIL PROTECTED]> wrote:
>Steve K wrote:
>> >If you have sufficient RAM then the swap file, apparently, is not
>> >utilized.
>>
>> In Win98, the swap file is in constant use. That includes idling with
>> no active processes except the kernel and GUI.
>
>Well.... You can turn off the swap file entirely. And if it was in constant
>use, the disk drive would never spin down. Which it does. So I'm not sure
>how either of those cases counts as "constant use".
Simple - Unencrypted bits from memory are constantly on the disk. Anyone
who can read that file, can read the secret keys stored in the memory of
running programs.
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
Email spam sucks. Do something about it. http://www.cauce.org
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Mon, 16 Apr 2001 02:20:18 GMT
On Sun, 15 Apr 2001 12:25:11 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>
>[EMAIL PROTECTED] wrote:
>>
>> I'd have thought that detection of otherwise well constructed
>> steganography would be based on statistical analysis of the degree of
>> entropy or randomness in the data. Any unencrypted image, or other
>> file, intended to convey information is by definition not random. So
>> GIFs, JPEGs etc are not random. It would be perfectly feasible to
>> analyze a huge quantity of such files (ones without hidden messages)
>> to establish their statistical properties - in particular the degree
>> of randomness. Then one could focus on statistical comparisons of
>> files being sent by others with a view to establishing whether there
>> is any probability that the degree of randomness is more or less than
>> expected. Thus routinely embedding a pseudo-random (encrypted) file
>> in an image must marginally bias the degree of randomness of values in
>> the data. But, if the message is very small in proportion to the
>> container, then probability of detection is reduced. And, if very few
>> messages are sent, then probability of detection is also reduced.
>
>I don't think so. You may be able to find some statistical
>properties from pictures of a particular artist, just like
>style analysis of an author. But the painting of a little
>child or a computer generated chaos picture would have quite
>other properties.
I wasn't contemplating a simple analysis of overall patterns. No doubt
the diversity between Monets, Rothkos, family snaps and a superman
comic are sufficient to confuse analysis which simply looks for gross
patterns in total picture information.
I am not an expert in digitised image tech, but if one is looking for
hidden messages in an image file, one might, for example, analyse the
patterns in the least significant bits, between eachother and given
the values in the other bits. This follows the logic that one cannot
hide the message in bits that would affect the image's appearance, so
the LSBs are the prime suspects. Are the LSBs in a straight jpeg
without any pattern either in themselves (ie the value of each bit is
independent of the others) as well as wrt to the more significant
bits? If so, they must be, by definition, redundant. If not, then
presumably altering them may be detectable, given large enough samples
of tampered and untampered files to analyse, and a knowledge of JPEG
algorithms (or GIFs etc, as approp).
>> On this basis, I suspect that those using steganography in pictures
>> should:
>>
>> 1) use messages that are small relative to the container
>> 2) send images containing messages infrequently
>> 3) send lots of images which contain no messages
>> 4) perhaps, consider ways to salt encrypted messages after encryption
>> such that the frequency of bit values is not random, but rather
>> reflects the distribution of bits in the original container image, so
>> as to leave the statistical properties of bit values in the container
>> unvaried once the image is embedded.
>
>The total volume of images sent might be an issue. If two
>people exchange daily a number of pictures, that could
>under circumstances be suspicious. (On the other hand, a
>large number of pictures on a web site, e.g. a porno site,
>could evade suspicion and provide anonymity of the receiver.
>However, pictures all of a very restricted class might
>cause the problem of statistical properties.) Assuming
>that no 'standard' statistical properties of pictures
>exist (see above) and one sends (in the one-to-one case)
>only rather infrequently a picture (painting, photo,
>drawing) that correspond well to the accompanying text
>and the number of bits embedded is sufficiently small,
>I continue to think that detection by the opponent can
>be fiarly difficult.
>
>M. K. Shen
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 19:39:20 -0700
Mark G Wolf <[EMAIL PROTECTED]> wrote in message
news:9bdfjg$1v8m$[EMAIL PROTECTED]...
> > If your method generates new pads such that all bitstrings
> > are equally probable and independent of previous pads, then
> > the perfect secrecy theorem still applies. Doing so will
> > require additional entropy (that is, entropy not taken from
> > the previous pads) sufficient to generate the new pad
> > directly, so I don't see the new pad as re-use of the old
> > one in any meaningful sense.
>
> Well, that's just it, the reuse wouldn't be totally independent. What I'm
> trying to get at is how practical it would be to take a modestly large pad
> and rotate through it for "fairly" secure everyday use. I'm not talking
> national security here. It would obviously depend on how often you used
it
> over a given period of time. I mean even if you used the same pad many
> times over a long period you'd have to assume that someone was actually
> collecting all your messages, which is not very likely.
Well, yes, if your threat model is "your kid sister", then yes, there's
nothing insecure about reusing your "OTP". But, then again, in that
scenario, there's nothing particularly insecure about ROT13 either...
However, if the attacker is at all crypto savvy, and is really interested in
you (as opposed to decrypting random messages on the net), then:
- It's really easy for him to notice when you've reused the pad, simply by
comparing statistics between the two encrypted messages
- Once he has noticed this, it's simple for him to xor the two ciphertexts,
and then break the xor of the two plaintexts into their original forms.
It also brings up another question: if you are willing to throw away the one
advantage that the OTP has (information-theoretical security), why are you
using it in the first place? Why not pick a nice AES key, which you can use
as much as you want, and is secure against even quite determined attackers?
--
poncho
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why Not OTP ?
Date: Mon, 16 Apr 2001 02:51:02 GMT
Frank Gerlach wrote:
> Why is it that people do not like OTP ? It seems that some people do
> not like Public-Key crypto, so why not just exchanging a box of CDs ?
You can do that in limited applications (don't forget to destroy the
CD-ROM after using), but for large-scale communications it is utterly
impractical.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Mon, 16 Apr 2001 02:57:49 GMT
On 15 Apr 2001 20:34:10 GMT, [EMAIL PROTECTED] (Walter Roberson)
wrote:
>In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>:I'd have thought that detection of otherwise well constructed
>:steganography would be based on statistical analysis of the degree of
>:entropy or randomness in the data. Any unencrypted image, or other
>:file, intended to convey information is by definition not random.
>
>On the other hand, the data may be compressed. Compression works
>by reducing redundancy, so the compressed data is "more random".
>Any compression algorithm that leaves statistically-detectable
>correlation in its file, could theoretically be improved [but improving
>the algorithm might be difficult as a practical matter.]
Compression by definition involves *retention* of information
(notwithsanding that JPEG is 'lossy'). That is the data is decidedly
not random, but is contained in minimal size using an efficient
structure to organise the requisite information. So while compression
may reduce the obvious patterns in the values of the data (such as the
high frequency of the letter e in English text), it does so by
imposing a non-random structure. So compression alone does not
eliminate discoverable information
The only files that appear random and which are also not able to be
analysed to establish their content are those produced by strong
encryption. This is a truism.
But then we come to my point 4. If compressed data (including JPEGs
and GIFs for images) contain analysable information in an agreed
structure, does the addition of random data alter the properties of
the files in a detectable way, especially when one has access to both
the tampered files and a large population of "control" files.
>: So
>:GIFs, JPEGs etc are not random. It would be perfectly feasible to
>:analyze a huge quantity of such files (ones without hidden messages)
>:to establish their statistical properties - in particular the degree
>:of randomness.
>
>Not really. "Degree of randomness" has no objective meaning. There
>is only "degree of randomness compared to a particular model." And
>there isn't just *one* model for GIFs, JPEGs etc.; there is an
>indefinite series of models depending on subject matter, equipment
>and so on.
The obvious way to obtain a control population would be to access the
persons equipment and send a series of images which one knows contain
no message. This would eliminate a large amount of the possible
variance between the suspect files and the controls.
>:Then one could focus on statistical comparisons of
>:files being sent by others with a view to establishing whether there
>:is any probability that the degree of randomness is more or less than
>:expected.
>
>Yes, but by the time you account statistically for all of those
>different models, the statistical measure is going to have to be
>very loose -- unable to detect anything but the most obvious
>hidden information.
Probably true if one looks only at gross comparisons. But there are
means to refine the search. As mentioned elsewhere, one might focus
on the least significant bits, since they are a likely hiding place
which will least disturb the appearance of the image.
>:On this basis, I suspect that those using steganography in pictures
>:should:
>
>:1) use messages that are small relative to the container
>:2) send images containing messages infrequently
>:3) send lots of images which contain no messages
>
>Alternately, have *every* image contain a message, but make it very
>difficult to tell which messages are spurious. Perhaps even use
>a multi-level code in which the "outer" message was relatively
>innocuous and explicable/deniable. For example you could even give
>them full source to the image encoding algorithm... source that just happens
>to have a "bug" that picks up an "uninitialized" block of memory
>(whose contents you very subtly prime if you have something to send.)
>And so on.
In a real world application, the purpose of the steganography is to
avoid even suspicion. This would mean using the most commonly
available algorithms.
Second level subterfuges assume there is already a primary level of
suspicion. Resort to spurious messages assumes that the attacker may
be aware there are messages in the first place. Similarly resort to
deniable messages also means the complete avoidance of suspicion must
have already failed (or what's to deny?). Giving "them full source to
the... algorithm" means you have already attracted their attention, so
once again it is too late. Implicit in your thinking is the idea that
the burden of proof is on the attacker - that the suspect is innocent
until proven guilty. Unfortunately for much of the world, that is not
real world thinking.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Function other than xor?
Date: Mon, 16 Apr 2001 03:02:31 GMT
newbie wrote:
> No. This function does not meet my specification. I'm looking for
> function with a lot of properties.
> Additive, multiplicative, distributive etc...other than modulo,
> permutation or inverse.
> New, simple and logical function.
> "Douglas A. Gwyn" wrote:
> > newbie wrote:
> > > Has someone created this kind of function?
> > I'm not sure what you're really after. f(any_bit_string) =
> > Rotate_right_1_place(any_bit_string) seems to meet your
> > specification. but what good does that do you?
I have to say that I don't think you completely understand
the terms you're using. A function of a single variable
cannot possibly have the "distributive" property, because
that requires two functions of two variables each.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Lorentz attractor...
Date: Mon, 16 Apr 2001 03:06:42 GMT
ClaudeVMS wrote:
> ... I have since found only few reports on the use of attractors in
> encryption science.
I think you must mean use of chaos, because the problem for use in
encryption *is* the existence of attractors.
You won't find much written on the use of kittens in encryption,
either, for much the same reasons.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
