Cryptography-Digest Digest #971
Cryptography-Digest Digest #971, Volume #12 Sat, 21 Oct 00 18:13:01 EDT
Contents:
Re: Entropy and RC4 ("Scott Fluhrer")
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: My comments on AES (SCOTT19U.ZIP_GUY)
Bezozs and bountyquest.com ("Paul Pires")
Visual Basic ("binary digit")
Help identifiing password encryption scheme? ("Ethics")
Quasi philosphical question regarding Index of Coincidence ([EMAIL PROTECTED])
Re: Help identifiing password encryption scheme? (jungle)
another problem question (Ernest Dumenigo)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: Dense feedback polynomials for LFSR (Tim Tyler)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: Storing an Integer on a stream (Tim Tyler)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Visual Basic (Guy Macon)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: My comments on AES (Tim Tyler)
Re: xor algorithm (Tim Tyler)
From: "Scott Fluhrer" [EMAIL PROTECTED]
Subject: Re: Entropy and RC4
Date: Sat, 21 Oct 2000 09:42:46 -0700
George Gordon [EMAIL PROTECTED] wrote in message
news:rOHH5.120$[EMAIL PROTECTED]...
Other people have asked similar questions here, but let me ask a very
specific one.
Assume that you initialise RC4 using a 128-bit key. Then you output
exactly
16 bytes worth of the stream. (I don't care how many loops you do for the
initialisation)
OK, how could you determine how much of the entropy in the 128-bit key is
preserved in the 16 byte stream if 1) you assume RC4 specifically? 2)
you
assume a perfectly uniform distribution?
I don't know about RC4 in particular (and I seriously doubt anyone else does
either), but if you model the process by a uniformly chosen random function
from 128 bits to 128 bits, then it's not difficult.
If you have a full 128 bits of entropy coming in (that is, each bit pattern
has probability 2**-128), then you should have an expected 127.1728
(approximately) bits of entropy coming out.
You can see this by observing that, for a random function from 2**128 -
2**128, then for small k, then you would expect approximately 2**128/(e *
k!) outputs that have precisely k preimages (where e = 2.718281828...).
This approximation becomes worse as k becomes larger, but 2**128 is
sufficiently large that by the time k becomes large enough to make the
approximation invalid, the number of expected outputs is sufficiently small
not to affect the result materially.
Or, in other words, for each k, there are approximately 2**128/(e * k!) with
probability k2**(-128)
Then, we apply that standard definition for entropy:
E = Sum{ p_i lg( p_i )) }
(where lg is logarithm base 2). Combining equal terms, and summing over k,
we get:
E = Sum( 2**128/(e * k!) * k2**(-128) / lg( k2**(-128) ) )
k
The k=0 term can be ignored, and the rest can be computed to give the above
number.
--
poncho
--
poncho
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: 21 Oct 2000 17:01:38 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in [EMAIL PROTECTED]:
: Andras Erdei wrote:
: The method i like most is fibonacci coding:
:
: - start with the largest fib number smaller than your integer
:
: - if the current fib number is smaller than your number
: substitute it and write down 1
: else
: write down 0
: - take the next fib number
:
: Example:
:
: number: 15
: fib: 1,1,2,3,5,8,13
: encoding: 13+2 - 0010001
:
: This way you encoded your (arbitrarily big number) in a way that
: there are *no consecutive 1s* in the encoding, and it ends with 1;
: so you can append an additional 1 and thus make it a prefix code.
:
: result: 00100011
:
: IIRC this encoding is asimptotically optimal.
"Severly sub-optimal" is how I would describe it, especially in the
context of padding schemes.
Padding with a format that can't use repeated 1s could only ever be
anywhere near optimal for small values.
Since when larger and larger values are used, methods which can use a
greater range of symbols will systematically trounce it, it's hard to see
how it could be described as "asymtotically optimal".
It reminds me of the work I use to do on interial guidance systems
I wrote a lot of algorithms that worked. My cohrots use to find artices
in the "IEEE" or like journals telling how they did some optimal
crap and my workmates would laugh and say gee they almost got it right
to bad that can't see the code your wrote so that maybe they could get
it right. When I won the EDN desing award one time some professor
use to tell my when other later invented subsets of the method I did.
He claims he taught it in his
Cryptography-Digest Digest #972
Cryptography-Digest Digest #972, Volume #12 Sat, 21 Oct 00 19:13:01 EDT
Contents:
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: My comments on AES ([EMAIL PROTECTED])
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
Re: Hash programs (Cornelius Sybrandy)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Help identifiing password encryption scheme? ("Ethics")
Date: 21 Oct 2000 22:03:16 -
From: pgp651 Use-Author-Address-Header@[127.1]
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
=BEGIN PGP SIGNED MESSAGE=
It's would make sense to implement this in hardware instead.
Is this hardware or software implementation ?
On Fri, 20 Oct 2000, jungle [EMAIL PROTECTED] wrote:
how this trick works ?
by intercepting calls to bios from o/s ?
Jonathan wrote:
How about strong encrypt the whole system drive with something like safeboot
www.controlbreak.nl or safeguard http://www.utimaco.com . With these
utilities you can't get acces to the drive period. (even if you try ntfsdos
or bios tricks.)
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Sat Oct 21 22:03:14 2000 GMT
From: [EMAIL PROTECTED]
=BEGIN PGP SIGNATURE=
Version: 2.6.2
iQEVAwUBOfISpE5NDhYLYPHNAQG6bgf9EyIu9ShMN3VqudDSE/RZo+pXjl9wMnHg
/hwpJKKmrRCAciO+TDeEGQy9bZBNssMCGRRzA716W3kS3buKgoXvI73oJMsajarK
+rxfGE7YHVJmADw8aSQTgZCfz7nav9GQqPaeIL/MHXvhEcwVuNKGbJyDYRFvnlkT
/37nVSDq60+WSnJKfVqp2WHJ7653UYgLxH26xY/Y/I8c0J0N+xYNq2jPT+Sk4eHu
SCC1vNJ67v97EFVW0u2+YBZnV/PnbtLZU/mx2BcT4yd7lThOSfsS1FVQa8TiXyWy
nqk9fitZazR/s4o5Im5nPQFn44MT/zAw68nMvh1WPV1x7QDeGDlwHg==
=BbpF
=END PGP SIGNATURE=
--
From: Joaquim Southby [EMAIL PROTECTED]
Subject: Re: Dense feedback polynomials for LFSR
Date: 21 Oct 2000 22:01:16 GMT
In article [EMAIL PROTECTED] Tim Tyler, [EMAIL PROTECTED] writes:
Joaquim Southby [EMAIL PROTECTED] wrote:
: In article [EMAIL PROTECTED] Tim Tyler, [EMAIL PROTECTED] writes:
:The original idea makes no sense, but execution time does not appear to be
:a problem with it.
: Simply because you fail to grasp an idea or possible applications for it
: doesn't mean it makes no sense.
True, but not pertinent here.
Pertinence is in the mind of those who can imagine.
: I didn't come up with this idea; it was passed on to me from a friend who
: uses me as a sounding board from time to time. She pointed out that
: sub-maximal LFSR's have most of the same behaviour as maximal LFSR's. If
: a maximal length LFSR has a tap sequence of n, A, B, C, then an LFSR with
: the tap sequence n, n-A, n-B, n-C will also be maximal length. Guess
: what -- it works for sub-maximal LFSR's, too. The state spaces of two
: sub-maximal LFSR's constructed in that way and using the same init vector
: are the same size. [...]
Which might be interesting - if you had provided a method of identifying
which LFSRs had a large period that does not involve stepping through the
states one at a time, and noticing when they repeat.
[FWIW, I know such methods exist - but do not know of any useful ones.]
Since this appears to be the best approach you've mentioned, the results
will not have a guaranteed minimum period greater than what you can step
through. Consequently, they are only known to offer protection against
attackers with resources less than or equal to your own.
Hmm. I guess I'm making some progress here. In previous posts, you held
that there was no such thing as a guaranteed minimum period.
Perhaps you would buy such a device. To me it appears to have nothing but
disadvantages compared to a maximal period LFSR.
Sorry to waste your time. Perhaps someday someone will produce something
that fits in better with your approach to protection schemes.
: One group of behaviours that is dissimilar between the two is how
: "random" the output stream looks. The output over a period of a
: maximal-length LFSR will *always* have the same characteristics: a) # of
: 1's minus # of 0's = 1; [...]
# of 1s minus # of 0s = n where n = register width?
From Golomb's "Shift Register Sequences": "In any
Cryptography-Digest Digest #973
Cryptography-Digest Digest #973, Volume #12 Sat, 21 Oct 00 21:13:01 EDT
Contents:
Re: Visual Basic (Sundial Services)
Re: Quasi philosphical question regarding Index of Coincidence (John Savard)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: Storing an Integer on a stream ([EMAIL PROTECTED])
Re: Storing an Integer on a stream ([EMAIL PROTECTED])
Re: BIOS password, will it protect PC with PGPDisk against tampering ? ("Jonathan")
Re: Hypercube structure / balanced block mixing (Benjamin Goldberg)
Re: How about the ERIKO-CHAN cipher? (Benjamin Goldberg)
Date: Sat, 21 Oct 2000 16:45:31 -0700
From: Sundial Services [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Visual Basic
Yes, bit, they exist and someone has already posted one.
What's more practical is to get (or buy) a cipher package that, ideally,
is packaged as an ActiveX (OCX) control. Then simply call its methods
appropriately. DLLs (dynamic link libraries) can also be called from VB
although it takes a little bit more work.
Cipher algorithms usually require so much "bit twiddling" that it is
much more efficient for the cipher core to be done in a compiled
language. Visual Basic is simpler for the less compute-intensive tasks.
binary digit wrote:
Anyone know where I can find some encryption algorithms that have been coded
in Vb and have good documentation on them?
==
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
Fast(!), automatic table-repair with two clicks of the mouse!
ChimneySweep(R): "Click click, it's fixed!" {tm}
http://www.sundialservices.com/products/chimneysweep
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Quasi philosphical question regarding Index of Coincidence
Date: Sat, 21 Oct 2000 23:46:06 GMT
On Sat, 21 Oct 2000 20:23:11 GMT, [EMAIL PROTECTED] wrote, in part:
If your faced with a cryptogram which includes both upper and lower case
letters, who would you calc the IC? Would you first convert all the
letters to one case and look only at frequency? Or do you consider "I"
as a seperate symobol from "i"?
That depends strongly on the particular encoding scheme used. 8-bit
ASCII? A 52-character set? A Huffman encoding?
Using a 52-character set just to allow upper- and lower- case would be
awfully wasteful, and thus it would weaken the cipher used, by
providing redundancy.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: Joaquim Southby [EMAIL PROTECTED]
Subject: Re: Dense feedback polynomials for LFSR
Date: 21 Oct 2000 23:56:41 GMT
In article [EMAIL PROTECTED] Trevor L. Jackson,
[EMAIL PROTECTED] writes:
There's a logical gap here. In order to claim something "looks more random"
one must provide a criteria by which one detects the degree of randomness. My
criteria leads to the conclusion that fractional LFSR periods are far less
random looking than their maximal versions because the missing bit patterns are
glaring artifacts.
So, I'll show you mine if you show me yours (tersely). What "looks random" to
you?
I was speaking in regards to the randomness postulates as expressed by
Golomb. The output over a period of a maximal-length LFSR meets those
postulates exactly. A random stream of bits will approach those
postulates, but is not likely to meet them exactly; this holds true for
the output of the sub-maximal LFSR.
What criteria do you use that would make the missing bit patterns stand
out? (That's not a challenge -- I'm really interested.)
Can you see any possible uses for a sub-maximal LFSR now?
If you think about LFSR's in terms of state spaces, you might realize
that the two types we're discussing differ only in the number of state
spaces. All LFSR's have at least two state spaces; one of these is the
space that contains the single state of zero. The maximal-length LFSR
has two state spaces: one is that zero state space and the other consists
of all the states between 1 and 2^n - 1. The sub-maximal LFSR has more
than 2 state spaces. Of the non-degenerative (by this I mean an LFSR
that returns to its original state -- those that have an odd number of
taps or that do not include the output bit in the tap sequence will not
do so) sub-maximal LFSR's I've had time to investigate, every one has an
even number of state spaces; at least one of those spaces' size was equal
to a power of 2 minus 1.
The parenthetical remark is confusing. An even number of taps implies that
there are two degenerate states corresponding to all zeros and all ones. But
the rest of the states may form a maximal length cycle, which yields an odd
number of cycles.
I've found that an odd number of taps leads to an output sequence that
loops through a portion of the sequence, rather
Cryptography-Digest Digest #975
Cryptography-Digest Digest #975, Volume #12 Sun, 22 Oct 00 01:13:00 EDT
Contents:
Re: Quasi philosphical question regarding Index of Coincidence ("Douglas A. Gwyn")
Re: Huffman stream cipher. (Benjamin Goldberg)
Re: SDMI Successfully Hacked (Matthew Skala)
Re: idea for spam free email (Matthew Skala)
Steganography books (CryptoBooks)
Re: another problem question ("Douglas A. Gwyn")
Re: Is it trivial for NSA to crack these ciphers? ("Douglas A. Gwyn")
Re: Quasi philosphical question regarding Index of Coincidence ([EMAIL PROTECTED])
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Re: another problem question ("John A. Malley")
Re: Is it trivial for NSA to crack these ciphers? ("Douglas A. Gwyn")
Re: RSA codes (SCOTT19U.ZIP_GUY)
Re: How about the ERIKO-CHAN cipher? ("Douglas A. Gwyn")
Re: Is it trivial for NSA to crack these ciphers? ("Douglas A. Gwyn")
Re: Rijndael implementations ("Douglas A. Gwyn")
Re: SDMI Successfully Hacked (Scott Craver)
Re: Rijndael implementations ("Douglas A. Gwyn")
Re: Rijndael implementations ("Douglas A. Gwyn")
Re: For those touting "compression as encryption" ideas - Upcoming IEEE conference
of interest (JPeschel)
Re: Steganography books (Scott Craver)
Re: A new paper claiming P=NP ("Douglas A. Gwyn")
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Quasi philosphical question regarding Index of Coincidence
Date: Sun, 22 Oct 2000 03:16:08 GMT
[EMAIL PROTECTED] wrote:
If your faced with a cryptogram which includes both upper and lower case
letters, who would you calc the IC? Would you first convert all the
letters to one case and look only at frequency? Or do you consider "I"
as a seperate symobol from "i"?
I'm curious how much the derived stat is "thrown off" by assuming the
English alphabet has 52 charaters rather than 26?
Index of Coincidence has nothing to do with case and everything
to do with correlation. What you need to do is to determine how
the I.C. is going to be *used*; generally it is used to detect a
deviation from a purely random (coincidental) behavior in some
specific test. When you study the situation it should become
obvious what to do.
--
From: Benjamin Goldberg [EMAIL PROTECTED]
Subject: Re: Huffman stream cipher.
Date: Sun, 22 Oct 2000 03:21:00 GMT
SCOTT19U.ZIP_GUY wrote:
[snip]
As for the fact a stream is not a file in one sense of the word
you seemed to use it in other senses like in the case in adding
an integer to a stream. In reading that problem I took it as a file
and you did not object. Also I give you an example for that other
thread. WHere you capaple of following it or what?
I have not, and do not plan to, look at your DSC program. If you can
explain the algorithm in clear english, I would be happy, but I am not
going to look at your shitty source code.
I did not comment on the fact that DSC requires that it operate on a
file of known length because you had not been willing to make the effort
to mention that. Now that I know, I can see that your algorithm is
crap, for the purposes I need.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
--
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: SDMI Successfully Hacked
Date: 19 Oct 2000 12:56:17 -0700
In article [EMAIL PROTECTED],
Mack [EMAIL PROTECTED] wrote:
if any were successful. I suspect they
are trying to get out of paying the $10k.
Ten thousand dollars is small pocket change to them; it's worth very much
more than that to avoid admitting that their system does not and cannot work.
If you broke SDMI and they could pay you ten million dollars and thereby
ensure that your break, or news of it, would never become publically
available, they'd do it.
--
Matthew Skala
[EMAIL PROTECTED] :CVECAT DELENDA EST
http://www.islandnet.com/~mskala/
--
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: idea for spam free email
Date: 19 Oct 2000 13:18:16 -0700
In article dIzH5.2293$[EMAIL PROTECTED],
G. Orme [EMAIL PROTECTED] wrote:
Any suggestions are most welcome on the folowing.
Impossible and immoral.
Your scheme depends on a trusted piece of client software which knows and
uses some secret information without telling the user. That is
impossible. Anything my computer knows, I know. It's my computer.
You attempt to patch that problem by putting the trusted client under a
restrictive license agreement forbidding the user from extracting the
secret information. That is immoral. Anything my computer knows, I have
a right to know. It's my computer.
Also,
