Cryptography-Digest Digest #626, Volume #13 Sun, 4 Feb 01 09:13:01 EST
Contents:
Re: New checksum algorithm (Benjamin Goldberg)
Re: On combining permutations and substitutions in encryption (Mok-Kong Shen)
Re: New checksum algorithm (Mok-Kong Shen)
Re: New checksum algorithm (Benjamin Goldberg)
Re: New checksum algorithm (Benjamin Goldberg)
Re: Pseudo Random Number Generator (Charles Lyttle)
Re: On combining permutations and substitutions in encryption (SCOTT19U.ZIP_GUY)
Re: Do you like playing with numbers? (Simon Johnson)
OverWrite freeware completely removes unwanted files from hard drive (Anthony
Stephen Szopa)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sun, 04 Feb 2001 10:14:37 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
> > Mok-Kong Shen wrote:
> > >
> > > Benjamin Goldberg wrote:
> > > >
> > > > Terry Ritter wrote:
> > > > >
> > > > > Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > >I like to take this opportunity to ask a question of
> > > > > >ignorance:
> > > > > >Why does e.g. CRC-16 use a polynomial of degree 16? (I had
> > > > > >expected one of degree 15, since that can be represented with
> > > > > >16 bits, while one of degree 16 can't.) Thanks in advance.
> > > > >
> > > > > The remainder from a degree 16 poly is a degree 15 poly, and a
> > > > > mod 2 deg 15 poly has 16 bits: 15, 14, ... 1, 0.
> > > >
> > > > Plus, since the x^16 coefficient is always 1, it never needs to
> > > > be stored in the variable holding the taps.
> > >
> > > However, CRC-16 is geared to 16 bit word size, I suppose.
> > > So it is clumsy to operate with a 16 degree polynomial,
> > > isn't it? (How do you do subtraction without considering
> > > the one bit that you do not have in storage representation
> > > of the polynomial?)
> >
> > Think about how CRC works:
> > crcvalue = ((crcvalue<<1)+newbit) % polynomial;
> > Since the max crcvalue is just less than the polynomial, % is never
> > more than a single subtraction -- and since we are working with
> > polynomials, not integers, we only subtract when the top bit of
> > crcvalue was 1. This means, we can change it to the following:
> >
> > crcvalue = ((crcvalue<<1) & 0x10000) ?
> > ((crcvalue<<1)+newbit-polynomial) :
> > ((crcvalue<<1)+newbit);
> >
> > Or, better yet,
> > crcvalue = (crcvalue & 0x8000) ?
> > ((crcvalue<<1)+newbit-polynomial) :
> > ((crcvalue<<1)+newbit);
> >
> > Or better yet still:
> > crcvalue = ((crcvalue<<1)+newbit) -
> > ((crcvalue&0x8000) ? polynomial : 0);
> >
> > I think you can see that on any occasion where we shift a 1 bit out
> > of crcvalue, we are subtracting polynomial from crcvalue -- and the
> > x^16 coefficient of the poly is 1, too -- thus these cancel out, and no data
> > is lost.
>
> I was not saying that one can't manage to calculate correctly
> but that it may be easier with a degree 15 polynomial. For
> one could then work wordwise (16 bits) instead of taking in
> each new bit at a time, I guess.
>
> BTW, in your first version 0x10000 doesn't work with hardware
> with word size of 16 bits, I suppose. In the second version,
> what happens when (crcvalue<<1)+newbit with the 17th bit
> (the one omitted) added in is less 'polynomial' with the 17th
> bit added in? (I understand here 'polynomial' is without the
> highest 17th bit. I mean one should only subtract when the
> former quantity is not less than the latter.) Sorry, I can't
> understand your third version at all. For it says that
> crcvalue is either 'polynomial' or 0, if I don't err.
>
> M. K. Shen
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Sun, 04 Feb 2001 11:25:33 +0100
Terry Ritter wrote:
>
[snip]
> But for Dynamic Transposition, known-plaintext does *not* immediately
> expose any particular permutation, because many different permutations
> can produce that same transformation. This is an advantage. How big
> that advantage is, obviously depends.
The problem is that, while one can 'believe' that through
the permutation mechanism (instead of xoring plaintext) the
prediction of the PRNG source becomes difficult (or (very)^n
difficult), it is hard to quantify and that one commonly
needs some solid quantification in a strict formal proof,
I suppose. So the way out is to leave out such proofs,
which one also doesn't have for e.g. the security of an
airplane when one is boarding one, I believe.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sun, 04 Feb 2001 11:28:24 +0100
Benjamin Goldberg wrote:
>
> Mok-Kong Shen wrote:
> >
> > Benjamin Goldberg wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > >
> > > > Benjamin Goldberg wrote:
> > > > >
> > > > > Terry Ritter wrote:
> > > > > >
> > > > > > Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > >I like to take this opportunity to ask a question of
> > > > > > >ignorance:
> > > > > > >Why does e.g. CRC-16 use a polynomial of degree 16? (I had
> > > > > > >expected one of degree 15, since that can be represented with
> > > > > > >16 bits, while one of degree 16 can't.) Thanks in advance.
> > > > > >
> > > > > > The remainder from a degree 16 poly is a degree 15 poly, and a
> > > > > > mod 2 deg 15 poly has 16 bits: 15, 14, ... 1, 0.
> > > > >
> > > > > Plus, since the x^16 coefficient is always 1, it never needs to
> > > > > be stored in the variable holding the taps.
> > > >
> > > > However, CRC-16 is geared to 16 bit word size, I suppose.
> > > > So it is clumsy to operate with a 16 degree polynomial,
> > > > isn't it? (How do you do subtraction without considering
> > > > the one bit that you do not have in storage representation
> > > > of the polynomial?)
> > >
> > > Think about how CRC works:
> > > crcvalue = ((crcvalue<<1)+newbit) % polynomial;
> > > Since the max crcvalue is just less than the polynomial, % is never
> > > more than a single subtraction -- and since we are working with
> > > polynomials, not integers, we only subtract when the top bit of
> > > crcvalue was 1. This means, we can change it to the following:
> > >
> > > crcvalue = ((crcvalue<<1) & 0x10000) ?
> > > ((crcvalue<<1)+newbit-polynomial) :
> > > ((crcvalue<<1)+newbit);
> > >
> > > Or, better yet,
> > > crcvalue = (crcvalue & 0x8000) ?
> > > ((crcvalue<<1)+newbit-polynomial) :
> > > ((crcvalue<<1)+newbit);
> > >
> > > Or better yet still:
> > > crcvalue = ((crcvalue<<1)+newbit) -
> > > ((crcvalue&0x8000) ? polynomial : 0);
> > >
> > > I think you can see that on any occasion where we shift a 1 bit out
> > > of crcvalue, we are subtracting polynomial from crcvalue -- and the
> > > x^16 coefficient of the poly is 1, too -- thus these cancel out, and no data
> > > is lost.
> >
> > I was not saying that one can't manage to calculate correctly
> > but that it may be easier with a degree 15 polynomial. For
> > one could then work wordwise (16 bits) instead of taking in
> > each new bit at a time, I guess.
> >
> > BTW, in your first version 0x10000 doesn't work with hardware
> > with word size of 16 bits, I suppose. In the second version,
> > what happens when (crcvalue<<1)+newbit with the 17th bit
> > (the one omitted) added in is less 'polynomial' with the 17th
> > bit added in? (I understand here 'polynomial' is without the
> > highest 17th bit. I mean one should only subtract when the
> > former quantity is not less than the latter.) Sorry, I can't
> > understand your third version at all. For it says that
> > crcvalue is either 'polynomial' or 0, if I don't err.
> --
> A solution in hand is worth two in the book.
> Who cares about birds and bushes?
Sorry for not being able to comprehend what you mean
in the present context. (I have shown that possibly
none of your solutions is correct.)
M. K. Shen
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sun, 04 Feb 2001 10:26:15 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
> >
> > Mok-Kong Shen wrote:
> > >
> > > Benjamin Goldberg wrote:
> > > >
> > > > Terry Ritter wrote:
> > > > >
> > > > > Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > >I like to take this opportunity to ask a question of
> > > > > >ignorance:
> > > > > >Why does e.g. CRC-16 use a polynomial of degree 16? (I had
> > > > > >expected one of degree 15, since that can be represented with
> > > > > >16 bits, while one of degree 16 can't.) Thanks in advance.
> > > > >
> > > > > The remainder from a degree 16 poly is a degree 15 poly, and a
> > > > > mod 2 deg 15 poly has 16 bits: 15, 14, ... 1, 0.
> > > >
> > > > Plus, since the x^16 coefficient is always 1, it never needs to
> > > > be stored in the variable holding the taps.
> > >
> > > However, CRC-16 is geared to 16 bit word size, I suppose.
> > > So it is clumsy to operate with a 16 degree polynomial,
> > > isn't it? (How do you do subtraction without considering
> > > the one bit that you do not have in storage representation
> > > of the polynomial?)
> >
> > Think about how CRC works:
> > crcvalue = ((crcvalue<<1)+newbit) % polynomial;
> > Since the max crcvalue is just less than the polynomial, % is never
> > more than a single subtraction -- and since we are working with
> > polynomials, not integers, we only subtract when the top bit of
> > crcvalue was 1. This means, we can change it to the following:
> >
> > crcvalue = ((crcvalue<<1) & 0x10000) ?
> > ((crcvalue<<1)+newbit-polynomial) :
> > ((crcvalue<<1)+newbit);
> >
> > Or, better yet,
> > crcvalue = (crcvalue & 0x8000) ?
> > ((crcvalue<<1)+newbit-polynomial) :
> > ((crcvalue<<1)+newbit);
> >
> > Or better yet still:
> > crcvalue = ((crcvalue<<1)+newbit) -
> > ((crcvalue&0x8000) ? polynomial : 0);
> >
> > I think you can see that on any occasion where we shift a 1 bit out
> > of crcvalue, we are subtracting polynomial from crcvalue -- and the
> > x^16 coefficient of the poly is 1, too -- thus these cancel out, and
> > no data is lost.
>
> I was not saying that one can't manage to calculate correctly
> but that it may be easier with a degree 15 polynomial. For
> one could then work wordwise (16 bits) instead of taking in
> each new bit at a time, I guess.
Even if we changed to a degree 15 polynomial, we could not work more
than one bit at a time. We can precompute tables, true, and work a byte
at a time, but this is doable regardless of the size of the poly.
> BTW, in your first version 0x10000 doesn't work with hardware
> with word size of 16 bits, I suppose.
True. It was done to demonstrate, theoretically, what happens when a
crc is calculated.
> In the second version, what happens when (crcvalue<<1)+newbit with the
> 17th bit (the one omitted) added in is less 'polynomial' with the 17th
> bit added in?
Let's pretend that we are working with 17 bit words.
I only subtract 'polynomial' when the 17th bit is set, not otherwise.
Since the 17th bit of the poly is also set, this means that no matter
what, the 17th bit of crcvalue after the update is 0. Do you see why?
> (I understand here 'polynomial' is without the highest 17th bit.
If we are working with 16 bit words, the poly is without the 17th bit.
If we are working with words >16 bits, the 17th bit is set.
> I mean one should only subtract when the
> former quantity is not less than the latter.)
All versions are equivilant.
> Sorry, I can't understand your third version at all. For it says that
> crcvalue is either 'polynomial' or 0, if I don't err.
No, it says that you either subtract polynomial or 0. Here's the
original 3rd version:
> > crcvalue = ((crcvalue<<1)+newbit) -
> > ((crcvalue&0x8000) ? polynomial : 0);
Here's another way of stating it:
if( crcvalue&0x8000 )
temp = polynomial;
else
temp = 0;
crcvalue = ((crcvalue<<1)+newbit) - temp;
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Sun, 04 Feb 2001 11:00:27 GMT
Umm, you /did/ notice the message you replied to contained no new
content whatsoever, didn't you? I had pressed 'send' accidentally after
pressing 'quote'.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Charles Lyttle <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Pseudo Random Number Generator
Date: Sun, 04 Feb 2001 11:17:33 GMT
Matthew Montchalin wrote:
>
> On Sat, 3 Feb 2001, CR Lyttle wrote:
> |XOR two "almost" random uncorrelated data streams, should result in
> |a more nearly "white" data output stream.
>
> I sure hope so. But are we relying on gut feelings here, or on
> something we can prove?
>
No. I don't have the proof handy, but this is one result of the theorem
of large numbers. If you take enough measurements, everything tends to a
gaussian distribution. The only question is how fast. Are two videos
enough? Do we need three or four videos? I don't know.
> |Encrypting the compressed video stream should make the data look even
> |more random. Choosing a couple of action-adventure films with lots of
> |explosions, etc., should make for a good result.
>
> Heh. Okay, if we must rely upon gut feelings, if nothing else. Any
> *Schwarzenegger* film ought to make for a better 'key' than a 'My Dinner
> With Andre' sort of film.
>
Yes, at least from the HDTV viewpoint. Many more new pixels each frame.
> |Lots of pixels changing in chaotic manner. In this case, a good result
> |is one in which E[(X[i]-mX)(X[j]-mX)] = 0 if i != j. That means that
> |given previous output you cannot predict what the next output will be.
>
> This is the case for the algorithm I posted in sci.crypt back around
> June 1st or May 30th, 2000. And that was a very simple algorithm,
> so long as you choose a nonzero key, 8 bytes long, you get a sequence
> that doesn't repeat until after 2^42 iterations, which is a fair
> result.
>
Great. Recall why I posted this DVD idea in the first place : To get it
into the public domain so someone can't patent it and include it in some
snakeoil product. And it does seems as much fun as the "lava lamp" PRN
generator posted a while back:)
> |> And what do you do if the user chose to use two identical DVD's?
> |> (I know, you tell him not to, but what happens if he goes ahead
> |> and does so?) An identity function with very little appearance
> |> of randomness.
> |
> |Big goof! If I were writing a program to do crypto, I would have
> |that case abort with an error code. The correlation would be 1. The
> |programmer would have to set a limit on rho, say +/-0.07 or some such.
>
> But now we ought to conclude our algorithm with a series of "employee
> training sessions" to keep them from doing that sort of thing!? I
> don't think we would want our national defense to be hanging in the
> balance on how well some 'sociology major' CIA agent can figure out
> which key to type in on their encryption routines. (But vocabulary/
> grammatical transformation coding is more practical, even if more easily
> compromised and penetrated.)
>
> |Exceed the limit and get prompted to choose another video.
>
> Heh
>
> |Also note that DVDs will have lots of areas that contain non-video
> |information. The program will have to identify those and skip over
> |them.
>
> Well, compressing a DVD which is already compressed, should inflate
> it in some obvious (?) sort of way. And after that, you can encrypt
> it, I guess. As I have said in the past, and which others seem to
> have said, the weak point in all these encryption systems is the human
> element. There's just not much a 'high' security echelon can do in
> trying to straighten out an unreliable or incompetent lackey; all
> the codes in the world here won't help.
I think real world use for an idea like this one would be limited to
kids games or perhaps getting new random sequences for some simulations.
I certainly wouldn't use it for anything else.
--
Russ Lyttle
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: On combining permutations and substitutions in encryption
Date: 4 Feb 2001 11:49:48 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote in <[EMAIL PROTECTED]>:
...
>
>Known-plaintext is one of the most damaging information conditions,
>specifically because it can immediately expose a complete ciphering
>transformation.
>
>For the emulated huge simple substitutions we call conventional block
>ciphers, known-plaintext generally does expose one element from the
>emulated table.
>
>For classic simple XOR stream ciphers, known-plaintext immediately
>exposes the confusion or keying sequence, which then allows that
>sequence to be attacked.
>
>But for Dynamic Transposition, known-plaintext does *not* immediately
>expose any particular permutation, because many different permutations
>can produce that same transformation. This is an advantage. How big
>that advantage is, obviously depends.
>
>However, I would say that Dynamic Transposition is not "complex," but
>is instead far clearer in concept than any Feistel cipher.
>
Terry "wrapped PCBC" also is designed to "not immediately expose"
any particular permutation. But it also allows data to mix through
the whole file not just in the forward direction.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Do you like playing with numbers?
Date: Sun, 04 Feb 2001 13:14:08 GMT
In article <95hpt4$jqc$[EMAIL PROTECTED]>,
i-reza <[EMAIL PROTECTED]> wrote:
> Aren't numbers fun? I love numbers and I hate numbers.
>
> The folowing pair of sequence, I'm pretty sure is difficult to
decrypt.
> It's linked by an algorithm I hope will stump the most determined
> cryptanalyst.
>
> 0931 2506 8093 1663 5860 04
> -----------------------------------------------
> 0918 0405 8091 8632 9091 25
> -----------------------------------------------
> 0742 7296 8074 2224 5847 31
> -----------------------------------------------
> 0742 4725 8074 2843 6314 33
> -----------------------------------------------
> 0347 1442 8034 7046 5333 47
> -----------------------------------------------
> 0626 0230 8062 6483 7206 95
> -----------------------------------------------
> 0530 3100 ???? ???? ???? ??
>
> What is the algorithm behind it? What will the 14 unknown digits be?
>
> --
> normal? what for? i want unique...
>
> Sent via Deja.com
> http://www.deja.com/
>
Okay, Cryptanalysis usually assumes that you have an algorithm to
analyse. We won't even look at this sequence of digits without an
algorithm. Be prepared for nasty replies.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.conspiracy
Subject: OverWrite freeware completely removes unwanted files from hard drive
Date: Sun, 04 Feb 2001 05:39:21 -0800
OverWrite freeware completely removes unwanted files from hard drive
OverWrite Program: incorporates the latest recommended file
overwriting techniques. State-of-the-art detection technology and
the subtleties of hard drive technology have made most overwritten
and deleted data on magnetic media recoverable. Simply overwriting
a file a few times is just not good enough.
To insure that your files are thoroughly wiped clean they must be
overwritten numerous times with varying bit patterns.
OverWrite Version 1.0 uses the following 27 overwrite patterns when
any file is overwritten and deleted, such as plain text messages,
random number files, etc.
ref # binary decimal
1 01010101 01010101 01010101 85
2 10101010 10101010 10101010 170
3 10010010 01001001 00100100 146 73 36
4 01001001 00100100 10010010 73 36 146
5 00100100 10010010 01001001 36 146 73
6 00000000 00000000 00000000 0
7 00010001 00010001 00010001 17
8 00100010 00100010 00100010 34
9 00110011 00110011 00110011 51
A 01000100 01000100 01000100 68
B 01010101 01010101 01010101 85
C 01100110 01100110 01100110 102
D 01110111 01110111 01110111 119
E 10001000 10001000 10001000 136
F 10011001 10011001 10011001 153
G 10101010 10101010 10101010 170
H 10111011 10111011 10111011 187
I 11001100 11001100 11001100 204
J 11011101 11011101 11011101 221
K 11101110 11101110 11101110 238
L 11111111 11111111 11111111 255
M 10010010 01001001 00100100 146 73 36
N 01001001 00100100 10010010 73 36 146
O 00100100 10010010 01001001 36 146 73
P 01101101 10110110 11011011 109 182 219
Q 10110110 11011011 01101101 182 219 109
R 11011011 01101101 10110110 219 109 182
http://www.ciphile.com
Go to the Downloads Currently Available web page and scroll to the
bottom of the page.
------------------------------
** 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
******************************
