Cryptography-Digest Digest #548, Volume #12 Sun, 27 Aug 00 11:13:01 EDT
Contents:
Re: PRNG Test Theory (Tim Tyler)
Re: Destruction of CDs (Guy Macon)
Re: On pseudo-random permutation (Mok-Kong Shen)
Re: Steganography question (Mok-Kong Shen)
Re: R: Test on pseudorandom number generator. (Mok-Kong Shen)
4x4 s-boxes (Mack)
Re: New Site, Purple/Enigma/Sigaba/Russia Emulators (Mok-Kong Shen)
Re: DeCSS ruling -- More (Nomen Nescio)
Re: The DeCSS ruling and the big shots (Nomen Nescio)
Re: Bytes, chars, and I/O (Paul Schlyter)
Re: RSA Security Conference for 2001 ([EMAIL PROTECTED])
Re: 4x4 s-boxes ([EMAIL PROTECTED])
Re: stegonographic overuse (Sander Vesik)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Reply-To: [EMAIL PROTECTED]
Date: Sun, 27 Aug 2000 10:09:38 GMT
Paul Pires <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> [EMAIL PROTECTED] wrote:
:> : that should suggest that any PRNG test can be turned into a PRNG itself.
:>
:> As you mention you might expect - since PRNG tests aren't designed for
:> this job - unless you included a whole battery of such tests, the results
:> would pass that particular test used well, and fail other ones miserably.
:>
:> I expect using a whole battery of tests would probably result in an
:> extremely slow and cumbersome PRNG.
: Yes but there is an interesting question here. Can rejecting Non-random
: (determined by any means) ever result in random? My Knee jerk reaction is no
: but I never thought of it that way before.
The probability of the generator initially outputting very long strings
of zeros may well be likely to be zero - rather than a very small figure
as it would be for a genuinely random source.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Destruction of CDs
Date: 27 Aug 2000 10:28:10 GMT
Thomas W. Barr wrote:
>
>How about CD-Rs, is there any equipment of software to roast the disc,
>by flipping ALL the data are along the ttrack to its burnt state, not
>its blank state? This would add yet another layer of security to the
>data and you could then use some of the methods shown earlier in this
>thread.
>
>I, for one, would use a CD-RW for my one-time-pads and then go through
>an erase cycle, write 650mb of junk data (make sure you overwrite the
>FAT), and erase that. This would remove ALL remnants of data that could
>be left behind in the walls of the tracks.
Unless your tracking is perfect (it isn't), I can recover most of
the original data (laborously, one bit at a time) with an Atomic
Force Microscope. My particular setup (which is for investigating
the physics of DVD-RW, not for crypto) would fail to recover anything
if you were to repeat your write random/erase cycle 8 or 10 times on
the same drive that wrote the original data.
It bwould be cheaper and more secure to use a CR-R and burn it
(I mean in a fire pit, not a drive!) afterwards.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Sun, 27 Aug 2000 13:05:45 +0200
Benjamin Goldberg wrote:
>
> Tim Tyler wrote:
> >
> > <[EMAIL PROTECTED]> wrote:
> > : If the collision resolution is chosen such that the first
> > : element of the pair is always considered less than the
> > : second, then indeed there is a bias. The effect is [usually small].
> > : One can on the other hand use a random choice rule to resolve
> > : collision, in which case no bias can occur.
> >
> > Yes. It was not correct for me to have written: "No resolution
> > in the sort routine can possibly produce an unbiased sequence."
> >
> > As you say, use of a rule based on bits from the random stream
> > would be likely to provide a possible way of removing the bias.
>
> Here's a foolish question: What if you simply sorted your original array
> using (random()%2 ? 1 : -1) as your comparison function? While I'm
> certain that there has to be something wrong with this (because it
> sounds so simple and noone seems to have suggested it), I don't know
> what it is... especially if your sort routine tries to do the minimum
> number of comparisons.
I am not sure of having understood you properly. Do you
mean to use random() to resolve collision conflict or do
you just let random() to decide pairwise which element of
an array is smaller than the other? (BTW, which is the
'original array' in the context of my article?) Could you
please give an concrete example for doing a random
permutation of an array of, say, 4 or 5 elements so that
one can clearly see your idea? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Steganography question
Date: Sun, 27 Aug 2000 13:05:38 +0200
Harris Georgiou wrote:
>
> zapzing <[EMAIL PROTECTED]> wrote in message
> > An interesting case is when the random numbers you
> > are trying to hide your message in have some
> > other distribution, such as Gaussian for example.
> > ..........
>
> This is correct, it can be done theoretically if random data volume is much
> much larger than the real data, but there are various problem in practice.
> Since the random vs usable data ratio cannot be very large in real
> applications, only little can be done in "fusing" real and random data into
> one unified distribution. I 've tried implementing a variant of this: rather
> than fusing the two distributions together, I "hide" the real data of
> Gaussian distribution in another Gaussian of larger volume (mean, variance)
> so that the statistical attributes of it overwrite the ones of the usable
> data. Still, I have not found a solid theory in analyzing steganographic
> data even for trivial cases such as this.
Do I understand correctly that you want to embed informations
in a bunch of data with Gaussian distribution? But why
take the trouble to choose that kind of data? You can use
ANY (arbitrary) experimental data consisting of real-valued
numbers, each having a number of digits, and (pseudo-)
randomly pick some of these numbers and put the digits of
your information (I assume that's turned into decimal digits)
in the last digit locations of these so that the change is
not distinguishable from experimental errors. Cf. a note on
my web page.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: R: Test on pseudorandom number generator.
Date: Sun, 27 Aug 2000 13:05:28 +0200
Cristiano wrote:
>
> Now my question is: why statistical tests did not detect this big
> difference in these generators?
I am not a mathematician. But I believe that it is improper
to take the 8 leftmost bits of an integer generated by
such generators as a means to compare the quality of these.
Suppose you let the code of these for 32-bit machines to
be transferred to a 64-bit machine with integers now having
64 bits. Then the 8 leftmost bits would all be 0's, isn't it?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: 4x4 s-boxes
Date: 27 Aug 2000 10:58:42 GMT
Has anyone analyzed the number of s-boxes
that could be used for Serpent?
more specifically, serpent s-boxes don't appear
to have particularly good avalanche characteristics.
The criteria seem logic but is it possible that
the serpent s-boxes might have been chosen
using stricter criteria?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New Site, Purple/Enigma/Sigaba/Russia Emulators
Date: Sun, 27 Aug 2000 13:18:55 +0200
Charles Petersen wrote:
>
> I thought you all might like to check out my new site.
>
> http://dev.thinkquest.org/C004911/
>
> It has a simulation and explanations of the cryptography used by the
> major powers of World War II. This includes java applets that emulate
> the Purple, Enigma, Sigaba, Russian Espionage Cipher, and a public
> domain Bombe. In addition, there is a public forum reminiscent of
Just curious: If a message is superenciphered with a couple
of these machines, how vulnerable is it in the time of modern
technology?
M. K. Shen
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: Re: DeCSS ruling -- More
Date: Sun, 27 Aug 2000 14:00:11 +0200 (CEST)
I had thought of that, but I think it needs to be a little
more complex as a ROT13 scan could be easily performed.
In article <H11q5.9422$[EMAIL PROTECTED]>
"Stou Sandalski" <tangui [EMAIL PROTECTED]> wrote:
>
> How about something like ROT13 ?
>
>
> "No User" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > In article <rWMp5.3769$[EMAIL PROTECTED]>
> > "Stou Sandalski" <tangui [EMAIL PROTECTED]> wrote:
> > >
> >
> > Okay, here is the game... After all this is sci.crypt. Both
Deja-
> > News
> > & Alta Vista have removed the source from their servers. Someone
> > needs
> > to figure out a 'encryption method' that would convert the C
source
> > code
> > to something that would not look like the original document, but
not
> > be
> > seen as binary so it would be stored on Deja-News and its ilk.
> > Instead of
> > ASCII armour we need an 'English' armoured scheme.
> >
> > Documents would be stored on these servers and no-one would know
what
> > they
> > really represent. The keys could be distributed to convert them
> > back. This
> > would not need to be a high security scheme, just enough to get it
> > through a
> > binary scanner to get it stored.
> >
> > Any idea?
> >
>
>
>
------------------------------
From: Nomen Nescio <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling and the big shots
Date: Sun, 27 Aug 2000 14:40:10 +0200 (CEST)
The arguments about the expressivness of software have already been
made and won, in 2 different Federal Court districts. The cases
regarded
crypto. The argument about binary failed, example was what if the
language was interperted.
In article <[EMAIL PROTECTED]>
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>
> Sundial Services wrote:
> > Flawed it may be, but "human nature is what it is" (and let's be
> > brutally honest here folks ;-)). Can we honestly say that the
backers
> > of CSS have -no- valid position to take?
>
> Their position re: binary (functional) versions of the software is
> probably tenable. Binary versions of the software do possess a
> functional aspect and little expressive aspect. Restricting the
ability
> of a valid news outlet such as 2600 to post source code and links to
> source code, however, so obviously violates the 1st Amendment's
> freedom-of-press and freedom-of-speech guarantees that I was
absolutely
> astounded that the judge came to the conclusion that 2600 could not
post
> those items.
>
> It appears that the judge decided that 2600 was not a member of the
> press because he does not like the content of 2600. Which raises the
> question of, "what is a member of the press?". Well, basically, if a
> publication publishes on a regular schedule and says it is a member
of
> the press, it is, no matter whether or not a particular judge likes
the
> content.
>
>
> > Does the fact that a lock can
> > be picked mean that they are not allowed to have -any- lock or
object to
> > the free and wonton distribution of a lock-pick?
>
> The fact of the matter, though, is that DeCSS, like a lockpick, is
> merely a tool. It is not illegal to possess a lockpick in most
places
> (see http://www.faqs.org/faqs/locksmith-faq/ ), and it is not
illegal to
> sell a lockpick to anybody and everybody in most places. Former
convicts
> are amongst the most avid consumers of locksmithing kits sold via
mail
> order (if you want one for yourself, try http://www.paolos.com ).
The
> only time that possession of a lockpick becomes illegal is when it
is
> used in the commission of a crime, at which point it becomes a
"burglary
> tool". The astounding thing that has ocurred here is that a court
has
> decided that not only can a tool (the executable program "deCSS") be
> outlawed because it has no conceivable legal purpose (that was the
fact
> he found, despite the LiViD project and the original author saying
it
> was created for a legal purpose), but also discussion of how the
program
> works, its very blueprint if you will (its source code) can be
outlawed.
> As far as I know, this is a first here in the United States, where
it
> has long been a fact that possession of a bomb is illegal, but
> possession of the plans for a bomb is not (see
http://www.loompanics.com
> if you want your very own bomb plans :-). Note that I found all of
the
> links above (and many more!) in about 5 minutes of searching via
> http://www.google.com , so we are not talking about anything
> particularly brain-surgery-like.
>
> > That is, really, "a
> > two-sided and therefore tough question." (It doesn't have a
> > 'mathematical' answer.)
>
> Well, the Constitution of the United States has an answer.
> Unfortunately, the government of these United States has long shown
a
> willingness to ignore the Constitutional prohibitions (this is a
> longstanding problem, BTW, going all the way back to the presidency
of
> John Adams), and whether the courts go along with the government or
not
> appears to be a coin toss (for example, with RICO, an obvious
violation
> of the 4th and 5th Amendments, the Supremes basically said "since
the
> government has shown a compelling interest, we'll go along with
> violating the Constitution"). And this does not even count the
regular
> violations of the 6th, 7th, and 8th Amendments to the Constitution
> (e.g., the kid who was jailed on charges of "making threatening
> statements" and assigned $1M bail for joking about the Columbine
killers
> being stupid because "if they wanted to kill jocks, they should have
> started in the gym, not in the cafeteria", an action which is a
clear
> violation of both the 1st and 8th Amendments).
>
> --
> Eric Lee Green There is No Conspiracy
> [EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, chars, and I/O
Date: 27 Aug 2000 14:59:02 +0200
In article <[EMAIL PROTECTED]>,
Mark McIntyre <[EMAIL PROTECTED]> wrote:
> This is an old debate. The quotes from the standard merely ensure that
> C compilers must return 1 for sizeof(char). How many bits are in the
> object pointed to, the standard does not say. It does say how many are
> used tho - CHAR_BITS. The implementation could use 23 bits for a char,
> and still return 1. even if CHAR_BITS were 8.
On such an architecture, memcpy() would be quite useless to copy memory
blocks.....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA Security Conference for 2001
Date: Sun, 27 Aug 2000 14:49:12 GMT
In article <8oaagt$orc$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> > Cryptographers track not withstanding, RSA Security isn't a good
> > conference for this type of paper. It's mostly a security industry
> > trade show. I recommend looking for a more research-oriented type
of
> > conference, like Fast Software Encryption or one of the IACR
> > conferences. Unfortunately you just missed SAC 2000 (Selected Areas
> > in Cryptography) in Waterloo, Ontario, which I think is kind of near
> > you; and anyway, the submission deadline was May 1. You might try
for
> > next year though.
>
> With that in mind, this link may be helpful :
> http://www.dice.ucl.ac.be/crypto/call_for_papers.html
>
> Important deadline to note is FSE '01 papers due December 29.
>
> Thanks to the UCL crypto group for collecting these calls for papers!
Well I certainly can goto FSE '01. I need some help though. I have to
re-write the paper to be 15 pages and in Latex.
The 15 pages I can handle (the TC5 paper was 20 pages I think) but I
don't know much of LaTex at all.
Can somebody please help me get some Latex tools for win98 and how to
use them?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 4x4 s-boxes
Date: Sun, 27 Aug 2000 14:51:49 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mack) wrote:
> Has anyone analyzed the number of s-boxes
> that could be used for Serpent?
>
> more specifically, serpent s-boxes don't appear
> to have particularly good avalanche characteristics.
>
> The criteria seem logic but is it possible that
> the serpent s-boxes might have been chosen
> using stricter criteria?
My "serpent_sboxes" on my website are good candidates for replacement
sboxes if needed.
Tom
--
http://www.geocities.com/tomstdenis/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: stegonographic overuse
Date: 27 Aug 2000 15:01:04 GMT
John Savard <[EMAIL PROTECTED]> wrote:
> On Sat, 26 Aug 2000 11:49:27 GMT, [EMAIL PROTECTED] wrote, in
> part:
>>Detonate <[EMAIL PROTECTED]> wrote:
>>> embedding an encrypted message into a gif file is fine and all, but if
>>> somebody was eavesdropping on my email and i was repeatedly sending gifs,
>>Yes, no, maybe? Sending large amounts of jpegs may simply indicate
>>that you and your friends are going to go blind at an early age. ;)
> Just recently, I was in a computer book store, looking to see if
> Secrets and Lies was in yet, and I broke down and bought a book (by
> Artech House: "Information Hiding") on steganography.
> Before that, I would have commented that sending _.GIF_ files instead
> of _.JPG_ files would indeed be suspicious - and the former format,
> being lossless, lends itself to steganography. And this is true,
> because the simpler methods work most easily this way.
> Although I had heard of watermark methods claimed to work on .jpg
> images, I have now learned more about the methods that work with this
> format: actually adding the hidden information to the image after
> compression is possible, for example.
JPEG has two phases, lossless and lossy. IIRC jpeg released code that did
stego on jpegs, but I think there was some problem (stego adversly
affected the spectrum or somesuch so it was possible to tell.
Search for jhpeg stego and you should come up with lots of hits.
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
--
Sander
FLW: "I can banish that demon"
------------------------------
** 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
******************************
