Cryptography-Digest Digest #875, Volume #10 Mon, 10 Jan 00 07:13:01 EST
Contents:
Re: How about this for a "randomly" generated bitstream? (David Wagner)
Re: WSO have really protected my home PC with Windows 98 ! ([EMAIL PROTECTED])
Re: frequency analysis with homophones ("Douglas A. Gwyn")
Re: Anagram ("Douglas A. Gwyn")
Re: DH parameters ("Scott Fluhrer")
Re: Little "o" in "Big-O" notation ("Scott Fluhrer")
Re: OT Re: letter-frequency software ("Douglas A. Gwyn")
Re: Just a little help please... ("Douglas A. Gwyn")
Re: Interview with an ECHELON Spy ("Douglas A. Gwyn")
Re: How about this for a "randomly" generated bitstream? (Guy Macon)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: DH parameters (David A Molnar)
Re: simple string encryption ("Dan Coyle")
Example C programs to encrypt/decrypt password ("benny")
Re: "1:1 adaptive huffman compression" doesn't work (John Savard)
Is there a sci.crypt FAQ? ([EMAIL PROTECTED])
8-round Blowfish ("Thierry FALISSARD")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: How about this for a "randomly" generated bitstream?
Date: 9 Jan 2000 20:08:50 -0800
In article <[EMAIL PROTECTED]>,
David Kessner <[EMAIL PROTECTED]> wrote:
> When converting from 24 to 16 bit audio, we take the original
> 24 bit sample and add an 8-bit random number. [...]
>
> The random numbers used in this process need to be very
> random. The human ear has an uncanny ability to pick out
> bad noise sources. Typically, multiple LFSR PRNG's are used
> with bit-lengths of >64 bits. Each PRNG will generate one bit
> of that 8-bit number.
>
> What this means for the crypto guy is unclear.
Youch. That sounds like taking just the LSB of audio might not be such
a great way to seed your RNG.
But, hey, look on the bright side -- this sounds like a great setup for
stego! Just replace your multiple-LFSR PRNG with a crypto-strength PRNG,
and now you've got a super subliminal channel available for whenever
you need it (you can merely replace the output of the crypto-strength
PRNG with the encryption of whatever text you want to hide via stego;
the two cases should be indistinguishable, from the point of view of
an eavesdropper).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: WSO have really protected my home PC with Windows 98 !
Date: Mon, 10 Jan 2000 04:34:18 GMT
> >Need to protect your compter? I did. That's why I wrote Windows
> >Security Officer. It works with Windows 95 and 98 systems, and it can
> >do the following for you :
>
> Sounds potentially useful. Do you have it posted anywhere for
> download, and do you have docs/ manuals online? Me wanna see.
>
> Steve K
>
You can get more info about Windows Security Officer on :
http://www.mach5.com/wso/officer.html
Also you can download it from :
http://www.mach5.com/download/secoff38.zip OR
http://members.xoom.com/winsecof/secoff38.zip
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: frequency analysis with homophones
Date: Mon, 10 Jan 2000 04:56:52 GMT
Mok-Kong Shen wrote:
> ... the 'statistical significance' of the sort that
> you found is of such 'uncertainty' (on the scale of my personal
> 'subjective' measure) that I wouldn't start put much energy
> straightaway in following the direction 'indicated' by the computing
> results.
If the statistical analysis is performed correctly,
the significance of the results should also be known.
One of many amazing facts in cryptanalysis is that fitting
an HMM to the observed data often results in approximate
categorization that is good enough to work with.
Similarly for other methods (cluster analysis, SVD, etc.).
Even relatively simple statistical tests are often more
reliable than judging by eye; there are examples in MilCryp.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Anagram
Date: Mon, 10 Jan 2000 04:59:18 GMT
Scott Fluhrer wrote:
> He got it right. ...
Thanks for saving me the trouble of explaining it.
- Douglas (back at my own computers now)
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: DH parameters
Date: Sun, 9 Jan 2000 20:58:44 -0000
JH <[EMAIL PROTECTED]> wrote in message
news:01bf5b20$42240080$9cfcd6d8@gateway...
> I am trying to implement the Diffie-Hellman key exchange and have a
> question about the size of the various numbers used. Most of the
documents
> I have looked at give an example using very small numbers and then make a
> general statement that for real security you would use much larger
numbers,
> but they don't specify the actual sizes of each of the values. It looks
> like you can keep a small generator such as 3 or 7 and I would imagine the
> prime would be 1024 or 2048 bits for high security. But I havn't been able
> to tell if your secret key must be about the same size as the prime or if
> it only needs to be around 128 bits.
> Will the following values give me roughly the same strength as a 128 bit
> key for Blowfish?
> In "a = g^x mod P"
> generator : g = 7
Fine: the size of the generator is irrelevant, as long as it doesn't produce
too
small of a group. I assume you will be making sure this is not the case.
Making sure (P-1)/2 is quite sufficient.
> public prime : size of (P) = 256 bytes = 2048 bits
IIRC, P needs to be a little larger, but this is reasonably close. However,
since
no one has ever tried NFS discrete log attack against such a large prime and
our
best guess on how NFS will scale is believed to be not very accurate, no one
is
really quite sure how hard this would be. (bobs: if I just said anything
too
outrageous, feel free to jump in and correct me).
> private key : size of (x) = 16 bytes = 128 bits
> or does x need to be 256 bytes also?
Having the private key be only 128 bits is known to be insufficient. If the
private
key is N bits, there are known attacks to break it with O(2**(N/2)) effort.
You
want to make the private key at least 256 bits, possibly a bit larger.
OTOH,
making it a full 2048 bits is complete overkill -- NFS doesn't care (AFAIK),
and for any reasonably large private key, it is the best known attack
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Little "o" in "Big-O" notation
Date: Sun, 9 Jan 2000 21:03:59 -0000
r.e.s. <[EMAIL PROTECTED]> wrote in message
news:859c5b$a16$[EMAIL PROTECTED]...
> "Jeff Moser" <[EMAIL PROTECTED]> wrote ...
> : > o(f(x)) = g(x) is true iff:
> : >
> : > lim f(x) / g(x) = 0
> : > x->oo
> :
> : Perhaps it's obvious and I'm missing it.. but I usually see o(1).. (a
> : constant). This doesn't seem to be a function that'd change heading to
> : infinity. For example.. o(1) is given in the big O of the NFS
Actually, the fact that '1' doesn't look like a function is rather
irrelevant.
1 can be regarded as a function of x, that is, the function that returns 1
for all values of x. So, o(1) becomes arbitrarily small for sufficient x.
And, this does not state how quickly or how slowly o(1) goes to zero,
only that it does head that way eventually.
>
> He's got it exactly reversed -- it should be
> f(x) = o(g(x)) iff f(x)/g(x) -> 0 as x->oo.
> (The "little o" is to suggest that it grows
> more slowly than g.)
Oops. Shows that I really should proof my outgoing posts a bit better.
Yes, a better way to say it might be that f(x) = o(g(x)) means that f(x)
becomes arbitrarilly smaller than g(x) -- you need only wait until x
is big enough.
--
poncho
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OT Re: letter-frequency software
Date: Mon, 10 Jan 2000 05:04:35 GMT
> >cat document.txt|awk 'BEGIN{N=0} {f[$1]++}END{ for (j in f) print j, " ",
>f[j]}'|sort -n +1
William Rowden wrote:
> Ah! The ubiquitous unnecessary cat! Try input redirection.
It is very useful in shell scripts (which is the best way to package
such stuff) to use "cat $* | whatever", which works whether or not
the shell script has arguments (if not, input is taken from stdin).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Just a little help please...
Date: Mon, 10 Jan 2000 05:07:56 GMT
"John C." wrote:
> ... i was hoping that someone could help me out for a week or two
> to get me started into the better methods and or teach me a few
> tricks on decrypting encrypted messages or vice vesa.
Just as Archimedes noted that there is no royal road to mathematics,
cryptanalysis (decrypting without a priori knowledge of the key) is
not a matter of just a few quickly-learned "tricks". The sci.crypt
FAQ, last I looked, contains several references that should get you
started.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Interview with an ECHELON Spy
Date: Mon, 10 Jan 2000 05:25:56 GMT
What a weird mixture of (well-known) fact and hogwash.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How about this for a "randomly" generated bitstream?
Date: 10 Jan 2000 00:25:35 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David Kessner) wrote:
>
>> In article <853ocm$[EMAIL PROTECTED]>, Guy Macon wrote:
>> >One problem: an audio recording that is accurate to the LSB sounds
>> >considerably worse than one with 1 LSB of random noise added. Because
>> >of this, it is common to add 1 LSB of random noise. In the old days
>> >this was usually resistor noise, but nowdays it is cheaper to write a
>> >psuedorandom generator program on the DSP chip in your mixing board.
>> >I doubt that the psuedorandom generator programs are at all suitable
>> >for crypto. (At last! My membership in the Audio Engineering Society
>> >finally paid off!)
>
>Ummm... I assume that you are talking about audio dithering. If
>this is the case, then there should be a little clarification for
>those non-audio people here.
>
>You don't add 1 LSB of random noise, you add "a small amount of
>noise that is <1 LSB".
Actually, the prefered method is a triangular probability distribution
with the peak at the actual value and the skirts at +1 LSB and -1 LSB.
This is often approximated by using 2 RNGs which generate random errors
of up to 1/2 LSB with equal probability and multiplying them.
>Further, this is only done when taking
>audio from N bits down to N-M bits (I.E., from 24 bit audio to
>20 bit audio).
>
>And in this case, the LSB is the last bit in the
>N-M bit data, not the original N bit data.
I beg to differ. You are confusing the common practice of using the
discarded bits as a probabilistic dither to the new LSB with the
equally common practice of adding noise to the LSB when the word length
stays the same.
>To put this into a practical sense, let's say that we're
>converting 24 bit audio into 16 bit audio. And, for the
>sake of discussion I will ignore what to do with the sign
>bit(s).
>When converting from 24 to 16 bit audio, we take the original
>24 bit sample and add an 8-bit random number. Remember that
>the "LSB" is the 16th bit (from the left), so our 8-bit random
>number is <1 LSB. This produces our new sample. This is
>repeated for every sample, but with a different random number
>(obviously).
O.K. You have a bunch of 24 bit samples with the top 16 actual
measurements of the physical audio, the bottom 8 actual measurements
of the physical audio modified by noise. Then you throw away the
bottom 8 bits during your 24 to 16 conversion. What is the result?
No change. You have to make changes in the remaining 16 bits to
have any effect at all on the output.
>This has the effect of masking the quantanization noise. Under
>some conditions the quantanization noise would sound very non-
>random. But with this method of dithering the quanization noise
>is basically white noise and thus less objectionable to our
>ears.
If you are listening to a CD (16 bit audio), the only possible way
to mask anything is to make changes to one of those 16 bits, presumably
the LSB. One can trade time for resolution by taking the bits in the
24 bit source and turning them into what amounts to pulse density
modulation of the LSB, but that doesn't help you if your source is
16 bits, so it is common practice to feed the PDM with a triangular
shaped RNG noise source.
>This has a very different effect than "taking a 16 bit audio
>stream and adding a random 1-bit stream to it". In that the
>effect is much more subtle and much less noisy.
>I should stress that this is only done when converting from one
>word size to a lower word size. It is not done when going to a
>higher number of bits or when the word size stays the same.
What you described is indeed done when converting from one word
size to a lower word size, but the LSB noise is often done when
digitizing to a particular word size, and when going to a higher
number of bits, the two most popular choices are filling the
empty bit with pink noise or doing a curve fit that hits all of
the data points that are actual audio samples.
>What this means for the crypto guy is unclear.
It means that the commonly voiced opinion that the LSB of digitized
noise is random and not pseudorandom is suspect.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 10 Jan 2000 00:36:31 EST
Correct me if I am wrong, but it seems that the chip has a small processor
or state machine in it that handles the memory cell programming and does
a SHA1 hash on the output of the thermal noise source. I can find no way
to get at the unhashed data, and I don't have the source for the SHA1,
which IMO puts this into the Security Through Obsurity category.
I have a couple of questions about SHA1 in this application:
[1]
Does SHA1 put out more bits than it is seeded with? If so, how can we
call those bits random?
[2]
Does the nature of SHA1 match the behavior of variable delays between
delivery of the random bytes?
[3]
Is there any way to derive the input to the SHA1 from the output,
and thus let me see the original thermal-random data?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: DH parameters
Date: 10 Jan 2000 05:30:59 GMT
JH <[EMAIL PROTECTED]> wrote:
> In "a = g^x mod P"
The Pollard rho attack will recover your secret exponent x in about
2^{x/2} steps. So if x is 128 bits long, the attack will take 2^64
operations. This is a lot, but not really enough. Try setting x to be 160
or 256 bits instead.
> key sizes for DH vs. Blowfish, IDEA etc.
You might try www.cryptosavvy.com -- they treat key sizes.
Thanks,
-David Molnar
------------------------------
Reply-To: "Dan Coyle" <[EMAIL PROTECTED]>
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Re: simple string encryption
Date: Mon, 10 Jan 2000 00:20:14 -0600
"Paul Agics" <[EMAIL PROTECTED]> wrote in message
news:85a2if$hp1$[EMAIL PROTECTED]...
> Where can I get some simple string encryption examples?
>
>
I don't know about anybody else be my favorite has always been a simple Xor
operation with a random number generator
It works like this
you have an input string that you want to encrypt, well call it 'INSTRING'.
INSTRING is 'N' bytes long
you also have a Key, a 32bit unsigned integer We'll call 'INKEY'.
you also have a random number generator, well call 'RANDOM'.
you also have a function to retrieve the ascii value of a character
within a string called 'ASCIIVAL', as well as a function called
CHRVAL that returns the Character from an ASCII Value.
just construct a for loop like this
/* declare a local 32 bit variable, well call 'I' */
long I
/* set the seed value of random number generator */
RANDOMSEED = INKEY
/* Loop through the string Xoring each character with a random number
between 0 and 255 */
for I = 1 to N do
INSTRING[I] = CHRVAL(ASCIIVAL(INSTRING[I]) Xor Random(255))
now to retrieve the unencrypted string from the encrypted string, just run
the same function again with the same inputs.
the pseudocode for the algorithm is only 5 lines long, it's fast, and it
can't be broken with a pocket calculator.
Nice and simple.
long I
RANDOMSEED = INKEY
for I = 1 to N do
{
INSTRING[I] = CHRVAL(ASCIIVAL(INSTRING[I]) Xor Random(255))
}
------------------------------
From: "benny" <[EMAIL PROTECTED]>
Subject: Example C programs to encrypt/decrypt password
Date: 10 Jan 2000 06:48:18 GMT
Hi,
I need to get sample of c programs to encrypt/decrypt password.
I need those, because currently I use clear text passwords to access
database application which is not secure, and will use compiled C programs
to encrypt/decrypt the password. Thanks alot for your help.
regards,
Benny
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Mon, 10 Jan 2000 07:17:12 GMT
On Sun, 09 Jan 2000 19:25:20 +0100, Daniel Vogelheim
<[EMAIL PROTECTED]> wrote:
>It describes 5 rules about
>how to cut off the last bits of the message in order to achieve
>byte-sized output. I think this idea is fundamentally flawed, as
>simply discarding information should make reconstruction impossible in
>general.
Yes, discarding information will do this.
I think that David A. Scott's scheme does have a minor problem,
although I've been unable to convince him of that. But it may not have
the serious problem which you describe.
However, it is possible, at least with a static Huffman code
(actually, there is no reason why this wouldn't work as well for
Adaptive Huffman compression), to represent the last symbol in a
message with fewer bits. This has to do with the fact that the Huffman
codes for symbols have the prefix property. The last symbol does not
need to have this property, since it doesn't have to contain the
information of how many bits it contains - the representation has to
stop when the message itself runs out of bits.
I illustrate this in the section entitled "Tying Up Loose Ends" on my
web page, which illustrates the principle with an explicit table of a
Huffman code for the English alphabet, and the required code to
represent the last letter in a compressed text with slightly fewer
bits.
The URL for that section is
http://home.ecn.ab.ca/~jsavard/mi060303.htm
http://www.freenet.edmonton.ab.ca/~jsavard/mi060303.htm
there is other stuff on the page, the relevant part is under the
heading "Terminating Compression".
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Is there a sci.crypt FAQ?
Date: Mon, 10 Jan 2000 11:09:47 GMT
Hi
Is there a FAQ for sci.crypt? I'm looking for a
fairly technical introduction to
hillclimbing/genetic algorithms useful in
cryptanalysis. I have a Maths degree.
Cheers
Ben Pickering.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Thierry FALISSARD" <[EMAIL PROTECTED]>
Subject: 8-round Blowfish
Date: Mon, 10 Jan 2000 12:18:42 +0100
Bruce Schneier says in his famous Blowfish paper :
"It is probably safe to reduce the number of iterations from 16 to 8 without
compromising security. The number of iterations required for security
may be dependent on the length of the key. Note that with the current
subkey generation procedure, an 8-iteration algorithm cannot accept
a key longer than 192 bits."
May I infer from this that 8-round Blowfish (192-bit key) is at least
as strong as triple-DES (168-bit key) ? (or even stronger)
I know there were some attacks against 8-round Blowfish,
in very particular cases though (I mean, not realistic cases).
>From what I could judge,16-round Blowfish is 2 or 2.5 faster
than simple 56-bit 16-round DES. Well, this is fast, but not so
fast in my opinion... 8-round Blowfish is a good compromise
that could be preferred.
Any opinion is welcome.
@ < http://os390-mvs.hypermart.net >
@ ("Is there life after MVS ?")
------------------------------
** 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
******************************
