Cryptography-Digest Digest #562, Volume #13 Fri, 26 Jan 01 19:13:01 EST
Contents:
Re: Producing "bit-balanced" strings efficiently for Dynamic ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Encoded serial number:Help! (Giannikol)
Q: solving simultaneous equations in modulo arithmetic (G. Ralph Kuntz, MD)
Re: Some Enigma Questions (Neil Sluman)
Re: Random stream testing. (long) ("Joseph Ashwood")
Re: Some Enigma Questions (John Savard)
Re: Some Enigma Questions (John Savard)
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (Terry
Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
----------------------------------------------------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Producing "bit-balanced" strings efficiently for Dynamic
Date: Fri, 26 Jan 2001 15:19:06 -0700
Reply-To: [EMAIL PROTECTED]
Arbitrary 37 bit strings will fit into 40 bits. 2**37 is just larger
than 40!/20!**2. I didn't check to see if the suggested algorithm would
actually work.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:21:52 GMT
On Fri, 26 Jan 2001 09:07:03 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt "Paul Pires"
<[EMAIL PROTECTED]> wrote:
>[...]
>I also am not clear on the goal. Yes there needs to be bit balancing so that
>a bias in the input is not recognizable in the output but by doing this
>hiding,
>don't you sacrafice another valuable property? Seems like the output would
>fail a taylored randomness test. You are going to get data that has a
>prefect
>distribution of zero's and ones within a block and something else if the
>block
>reference is displaced. Right?
It is not necessary for strength or security that a cipher to produce
random-like output. Most ciphers do so, but such is not necessary.
Here I think the possible output codes do appear with equal
probability.
This is a characteristic which represents the inefficiency of balanced
coding. But since that is a plaintext coding, and is known by both
designer and opponent, it does not seem particularly worrisome.
>Seems like what you'd want would be a method where the transposition
>works on a pile that is "Probably" balanced but where the deviation from
>perfect is not correlated to the input or output. I could be screwy here.
I have mentioned the possibility of a statistical or "almost" balance,
which could be very effective. But it seems like that analysis would
be much more complicated. We would have to talk about the
distribution of balance, and how strength changes accordingly, which
seems beyond what can now be done.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:25:04 GMT
On Fri, 26 Jan 2001 12:07:40 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>I have a suggestion for the initial statistical-balance step (to reduce
>the later balance extensions.) XOR the input with a DeBruijn sequence.
>For example a simple method would be to XOR the sequence 0101010101....
>Better would be 001100110011.... and even better 0001011100010111.... In
>the latter case, the XORing sequence is one byte long so one might
>improve things by rotating this sequence between bytes. Longer
>sequences are possible 0000100110101111 could be used on pairs of
>bytes--with rotation.
If we are going to process plaintext with a known sequence, why should
any particular balanced sequence be better than any other? It seems
like there will always be some plaintext that will not be helped, or
would in fact be made worse.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:26:55 +0100
Terry Ritter wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
> >After some re-thinking, I do like to elaborate a little
> >a previous point of mine concerning the question of
> >perfectness of DT.
> >
> >Suppose we have block size of n and we agree not to use
> >the non-balanced groups of bits but only the balanced
> >ones to transmit informations (in other words, we have
> >an 'alphabet' of a certain size m that is less than n). This
> >serves to separate out the issue of bit balancing in order to
> >simpify the argumentation below.
> >
> >Now what we have is the following: Given an information block,
> >we do permutations of its bits to produce an enciphered block
> >with the help of a PRNG. A PRNG never provides a perfect bit
> >sequence in the sense used in the context of the theoretical
> >OTP.
>
> First of all, "perfect secrecy" is a technical term from Shannon for a
> type of balanced ciphering. I have also used "perfect" in my articles
> to describe a random number generator (RNG) which is a permutation
> generator (with a single cycle). But, in general, I am unaware of any
> technical meaning for "perfect bit sequence." There can be no perfect
> sequence. There is only a universe of sequences, which we can sample,
> and with the sampled properties we can establish statistically.
>
> It is hardly a surprise that something we build is not perfect in an
> absolute sense. At issue is whether the difference between perfect
> and what we have is noticeable or exploitable.
>
> The statement "A PRNG never provides a perfect bit sequence" is
> technically false:
>
> Suppose as an RNG we had a simple shift-register (SR), that simply
> repeated its' contents cyclically: Surely we can see that any
> possible sequence *shorter* than the SR is easily produced. Of
> course, for longer sequences, only some are possible, and those
> sequences are internally correlated, which is not good. Since we
> normally use short RNG's, that is the behavior we are taught to
> expect.
But the point is whether your DT is on a par with the
theoretical OTP or perhaps better than it. So it is a
'theoretical' question, not a technical question. Thus
a perfect bit sequence, as I said, is what is understood
in the context of OTP and has, in particular, no finite
period.
>
> The point of using a large-state RNG in Dynamic Transposition is to
> support a full permutation computation using independent state.
>
> The problem occurs when we talk about RNG output beyond the internal
> state size. Here the problem would arise in subsequent permutations,
> where perhaps not all possible sequences of permutations are
> available. That issue would be clearer if we just used the raw output
> from the RNG, but we don't: we deliberately process values so that
> less information is available. We fold the output value and mask it
> (a power-of-2 modulo), and delete values from the sequence (thus
> creating completely different shuffling sequences). These operations
> act to hide correlation and improve statistical qualities.
>
> Suppose we had a numbered 64-card deck, which had only the values 0
> through 62 and 0 again. We assume we can only sample a small part of
> the deck at a time, and can have only so many samples. Eventually we
> may be able to establish that there 0 has twice the expected
> probability, and somehow exploit that situation.
>
> Now suppose we can only see the lower 2 bits of each card value. Here
> no value is missing, and 0 is only slightly more probable than 1 or 2.
> There is still a statistical difference, and we would still have
> difficulty finding it. But we could not say that any particular value
> would not occur, or that a related Shuffle move would not occur.
>
> I think the worst we could expect is that some permutations might be
> less probable than others. But I don't think we could catch the
> effect in practice, because there are too many permutations and our
> sample space is too small. Moreover, the actual defect is likely to
> be more like Y-permutation is less probable if X-permutation just
> occurred, which makes the statistical problem even worse.
>
> >How can it be that this imperfectness does not manifest
> >itself in some form (possibly in certain very much reduced,
> >practically entirely negligible, intensity) AT ALL in our
> >encryption result?
>
> There is no perfect sequence. We describe perfection statistically,
> across our sample of results. In a statistical sense, it may well be
> possible to approach statistical perfection -- over a limited use --
> to the extent that statistical differences are not apparent.
>
> This done first by having a large state RNG, and then by folding and
> masking the RNG value, so that many different RNG values produce
> exactly the same shuffling value. This is information reduction or
> loss, and in this way deviations are hidden.
>
> >Let's order all the distinct balanced bit
> >groups into a sequence S and feed repetitions of S into our
> >algorithm.
>
> I don't understand "feeding repetitions of S." An RNG algorithm steps
> or produces a sequence in some way, but does not take input.
>
> >This input is evidently perfectly predictable. Can
> >the output be perfectly unpredictable? It certainly cannot.
>
> An RNG is "perfectly unpredictable" as it starts and continues so
> until the output exceeds the internal state. Here, that should
> support a full double-shuffle. An RNG just can't be perfectly
> unpredictable indefinitely.
>
> >For the PRNG has a finite period and hence the ciphertext
> >must cycle ultimately.
>
> If the RNG cannot cycle while our Sun still shines, can we really say
> that it does, in practice, cycle? Knowing that, can we use even the
> most gross property of cycling? I think not.
>
> >This shows that, while DT could be
> >practically very secure (an issue that certainly merits
> >careful study before its being used in practice), it cannot
> >offer perfect security that pertains to the theoretical OTP.
>
> Again, "perfect security" is a technical term. It refers to a cipher
> where any possible plaintext may be ciphered into exactly the same
> ciphertext with equal probability. That arguably does occur in
> Dynamic Transposition on a block basis.
>
> It is when we consider multiple blocks that the arguments become
> weaker. But since the ciphering does not expose the permutation, this
> imperfection may not be detectable. If it is not detectable, can we
> say, in practice, that it even exists?
>
> That is not a semantic argument, or a philosophical question -- it is
> the real situation. For example, perhaps we could show that a certain
> amount of information is necessary to distinguish between our real RNG
> and the theoretical ideal. Then if we could show that the information
> is not available, we could have provable "perfection," much like other
> cryptographic proofs.
Then one has to wait your 'showing'. Before that, one
certainly can't legitimately support your previous claim
of superiority of DT over OTP, I believe.
M. K. Shen
------------------------------
From: Giannikol <[EMAIL PROTECTED]>
Subject: Encoded serial number:Help!
Date: Sat, 27 Jan 2001 00:50:18 +0200
Hi,
can somebody help me with this situation:
I have a machine with its serial number stored in an eprom.
The firmware is stored in a 2nd eprom. In this 2nd eprom the serial
number is not stored with the same way is in 1st eprom, but is stored in
a form of something like a checksum(?) of the serial number.
The machine reads the s/n from the first eprom, calculates something and
it compares it with the value stored in the 2nd eprom.
So if you change the firmware (2nd eprom) with the firmware of some
other machine, the machine's operation is stoped (Machine "understands"
the change!).
I figured out the following by comparing the 2nd eproms of two diferent
machines:
for s/n: 96000529 (dec) the number: 2D (hex) is calculated in
2nd eprom
for s/n: 95000367 (dec) the number: 2E (hex) is calculated in
2nd eprom
It does not seems too difficult, but I do not have the experience to
understand the method used.
Thank you
------------------------------
From: G. Ralph Kuntz, MD <[EMAIL PROTECTED]>
Subject: Q: solving simultaneous equations in modulo arithmetic
Date: Fri, 26 Jan 2001 23:01:46 GMT
I am trying to implement Adi Shamir's "How to share a secret" key-
splitting algorithm. For example, I want to share the secret "4" among
5 people so that any 3 can retrieve it. I pick a set of random
coefficients a1 = 2, a2 = 5, and p = 11. My equations become:
q(x) = (4 + (2 * x) + (5 * x ^ 2)) mod 11
D1 = (4 + 2 + 5) mod 11 = 0
D2 = (4 + 4 + 20) mod 11 = 6
D3 = (4 + 6 + 45) mod 11 = 0
D4 = (4 + 8 + 80) mod 11 = 4
D5 = (4 + 10 + 125) mod 11 = 7
Now D2, D3, and D5 get together to retrieve the secret "S". Their
equations become:
D2: 6 = (S + (2 * a1) + (4 * a2)) mod 11
D3: 0 = (S + (3 * a1) + (9 * a2)) mod 11
D5: 7 = (S + (5 * a1) + (25 * a2)) mod 11
Unfortunately, the neuron(s) in my brain that knew how to solve this set
of equations (in modulo arithmetic) have long since died as a result of
certain liquids consumed in college.
Any help on how to do it in an algorithm (so that I can implement it in
Java or C)?
Thanks, Ralph
------------------------------
From: Neil Sluman <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
Reply-To: [EMAIL PROTECTED]
Date: Fri, 26 Jan 2001 23:07:26 -0100
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> "David C. Barber" wrote:
>> Q7: Did the German Navy's creation of a 4th rotor position that included a
>> rotor that in one position made the machine act like 3 rotor machine result
>> in a weakened 4th rotor -- even if it hadn't already been compromised
>> otherwise? Seems to me what the 4th rotor did was simply create a 3 rotor
>> machine with 26 possible reflecting rotors, instead of the previous 1 fixed
>> rotor. Right or wrong?
> I was under the impression that the additional rotor was a true rotor.
Even if it isn't fixed, an actual rotation of this rotor would be rare.
I would have expected this to occur once every 17576 characters.
--
Squigle
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Random stream testing. (long)
Date: Fri, 26 Jan 2001 14:47:52 -0800
Crossposted-To: sci.crypt.random-numbers
"Paul Pires" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
> <Snip>
> > Well RNG output has 1 bit of entropy per bit, (Deterministic)PRNG output
> has
> > a fixed k bits of entropy scattered throughout the infinite output
> (although
> > the entropy in a given bit is likely to diminish to true 0 near the end
> > versus near the beginning).
> Is there any test that detects this difference in blind data? I believe
that
> you
> said no but I just wanted to verify.
Such a program can't exist, a program could however be created that gave an
apparent entropy value, but not a measurement of real entropy.
> Did you folks run any data collected from some true random source as a
> control? Did it perform similarly to PRNG's as far as "passing your
> criteria"
> goes? I have found that it is real hard to raise the bar just high enough
> so
> that there is a distinction between otherwise "Good" generators. Maybe it
> is not possible but I still have some subborn pig-headed bumbling about to
> do before I stop looking.
Well we ran into a very hard problem, in order to verify the test suite we
would have had to find a perfect true RNG, and that requires a mathematic
proof for verification, so we actually couldn't (although we did do a
smaller test on a bunch of dice where the dice actually failed, I suspect
it's because of the bias in them, or because the suite was too small). If it
didn't have a solid proof behind it then we ran the risk of verifying
correctness against an incorrect benchmark.
Joe
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Some Enigma Questions
Date: Fri, 26 Jan 2001 22:56:03 GMT
On Fri, 26 Jan 2001 21:59:31 GMT, [EMAIL PROTECTED]
(JimD) wrote, in part:
>On Thu, 25 Jan 2001 21:13:42 +1100, "Yeah" <[EMAIL PROTECTED]> wrote:
>>Didn't the British Government invent the worlds first programmable computer
>>to crak the enigma code. (Suck that America, IBM more precisely)
>Yes, Collossus at Bletchley Park, to help break ENIGMA and
>FISH.
Wrong, actually, on two counts.
IBM built the world's first programmable computer before Colossus; it
was the Harvard Mark I. However, that computer was not _electronic_.
Also, Colossus, sometimes erroneously reported in early accounts as
being applied to the Enigma, was actually used against the particular
FISH known as TUNNY, that is, the Lorenz Schlusselzusatz. It wasn't
even used on STURGEON, the Siemens Geheimschrieber.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Some Enigma Questions
Date: Fri, 26 Jan 2001 23:03:04 GMT
On Fri, 26 Jan 2001 14:52:52 GMT, [EMAIL PROTECTED] (Jim Reeds)
wrote, in part:
>I suspect, but have no evidence, that the special purpose
>number theoretical calculators built by D. H. Lehmer in the
>1930s in California were a kind of mental jumping off point
>for the Colossus team. The team that used Colossus, and
>which commissioned Flowers to design and build it,
>was full of pure mathematicians, who would have known of
>Lehmer's machines.
That could be true; however, they may also have been aware of IBM's
efforts towards building the Harvard Mark I, or even the Bell Labs
Relay Calculator.
Much of their work, though, seems to have been based on pulse counting
equipment - as may be used in radar, and as certainly _is_ used in
connection with devices such as Geiger counters. One would think they
would have been compartmentalized away from 'Tube Alloys', but this
sort of equipment may have predated the war and the atom bomb effort.
In any case, telephone switchboards perform rudimentary 'computing'
functions, and so one may not have to look any further than the
British Post Office for initial inspiration. And Alan Turing's
abstract work on computing machines is well known. So I think there
were several sources of inspiration; the thing was, though, that
Colossus went far beyond anything these various hints implied, so the
existence of inspiration doesn't minimize the accomplishment.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition
Date: Fri, 26 Jan 2001 23:21:06 GMT
On Fri, 26 Jan 2001 15:19:06 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>Arbitrary 37 bit strings will fit into 40 bits. 2**37 is just larger
>than 40!/20!**2. I didn't check to see if the suggested algorithm would
>actually work.
As a programmer, I normally think of taking whole chars (bytes) from a
file, processing them, and sending them back to a file.
In contrast, a lot of the bit-balancing schemes would leave me with
partial bytes. Dynamic Transposition can handle that fine, but then I
have to store the result -- as integral bytes. Then I have to deal
with partial-byte data when deciphering.
Now, I could innovate a variable-length record structure in which each
record includes a length in bits. But what I *really* want is to get
bytes, process bytes, and store bytes, with no structure at all.
One alternative, if I could take 16 bits to 18 in some convenient way,
is to take 8 bytes (64 bits) to 9 bytes (72 bits), or any multiple
thereof. But then I have to pad the plaintext to 8-byte blocks, which
means I have to remove the padding somehow when deciphering, so it
seems that either the padding must have a unique byte code (not
possible with binary data), or I again need a structure with a
bit-length value.
Another alternative might be to interpose an object which gets bits
from a file, puts bits to a file, and generally hides the bit-length
structure. In that way we can put it out of our mind, but nothing is
going to make it particularly efficient. It is at least 8x as much
work as we would normally spend getting a byte, and then 8x as much
putting it away. The shuffling effort should still dominate, but not
by nearly as large a factor.
So it seems to me that there is a lot to be said for trying to
bit-balance byte data using whole bytes.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:29:03 GMT
On Fri, 26 Jan 2001 23:26:55 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>Then one has to wait your 'showing'. Before that, one
>certainly can't legitimately support your previous claim
>of superiority of DT over OTP, I believe.
Then you believe incorrectly.
We already know that OTP is weak if the sequence it uses is
predictable. We also know that there is no test which can guarantee
that a sequence we use is not predictable. The OTP thus has inherent
potential weakness: the possibility of using a sequence with
predictable structure.
In contrast, Dynamic Transposition hides any structure in its'
sequence behind permutations which do not reveal the sequence. This
is an obvious superiority.
Now we have a contest. OTP is not the obvious winner, I believe.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:18:50 GMT
On Fri, 26 Jan 2001 21:52:58 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>That is not a semantic argument, or a philosophical question -- it is
>the real situation. For example, perhaps we could show that a certain
>amount of information is necessary to distinguish between our real RNG
>and the theoretical ideal. Then if we could show that the information
>is not available, we could have provable "perfection," much like other
>cryptographic proofs.
That's an interesting thought.
But the 'answer' is that as soon as one has enough bits of information
to do a successful brute-force search, we can distinguish, even if we
don't know how to distinguish _efficiently_. And proving that we won't
discover in future how to distinguish efficiently is, I believe,
fundamentally impossible.
In the specific case of Dynamic Transposition:
We have N bit blocks.
Our PRNG generates one of N! permutations for each block.
Given known plaintext, all we know is that the permutation generated
is one of a set of (N/2)!(N/2)! possible permutations.
Then, if the internal state of our PRNG is x bits, the number of
blocks of known plaintext required (on average) for uniquely
establishing that state is z, where z is the least integer such that
2^x
is less than or equal to
(N!/((N/2)!(N/2)!))^z
This even applies if there are two transposition layers, as long as x
is the number of state bits in _both_ PRNGs.
The security of Dynamic Transposition, like other ciphers with a
fixed-length key shorter than the plaintext, depends on the work
factor, and is not information-theoretic in nature.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Fri, 26 Jan 2001 17:31:34 -0600
From: Lord Running Clam <Use-Author-Address-Header@[127.1]>
Subject: Re: Why Microsoft's Product Activation Stinks
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
=====BEGIN PGP SIGNED MESSAGE=====
On Fri, 26 Jan 2001, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>> Excuse me, but is this little piece from alt.security.pgp relevant to your
>> flamewar?
>>
>> http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=720256016&fmt=text
>Go ahead and run. Can't stand your own ground? Can't come up with
>anything that your own mind can conceive?
WTF is that supposed to mean?
[WARNING: Please ensure that your flame-retardant garments are free
from cuts and tears.]
Did you read it? No. Obviously not.
Because the only way you could've made yourself look more stupid,
would have been if I was supporting your sorry case.
If you don't like using the Deja archives, then you can look for the
message on your news server. It was posted as Message-ID:
<[EMAIL PROTECTED]>.
I should know. I wrote it. Yesterday.
You, and the other pair of idiots who found me with time to spare,
and a sharp engineer's pencil, should all go into business together.
I am confident it would take no time at all for the three of you to
produce a tamperproof system, full of adverts; promoting its ease of
use, security, and unannounced functional suspension features.
The only problem is, Microsoft would sue you for copying Windows.
LRC.
- --
The bigger the humbug, the better people will like it.
~ Phineas Taylor Barnum.
=====BEGIN PGP SIGNATURE=====
Version: N/A
iQEVAwUBOnCv8oer+ijnZohVAQEGowf/Xs7r/eCJ517EI76pFkMjigDDhqaisYWe
OQYz20iFrf0lZlKwVjlVmTuqjYHjkivebdsJMEcuLHPiqTIgDRIKkyCFWz7VUQL4
mkVy5I/3QFUmRCDcJpyA2SFT7WqhXZwTayZXCilAoLcKIacoK2fABNOWqBmouaax
7JSEjGTYokXNoqmCOTRCCvyYlqaAZ6S/o04pWgbdTYkf1XVc9iDgoj1/J8AAQyQN
97/6lHpHNilnZPfeg0WD17H/iEHedJ5sW7AY6yYrmtqhAVu+bKT78rgO2SFCx+fr
lYkj3q+hCwX5+p+CkFegsJwM80CyNIV30qlMiz+uzmNAOktBuncMtw==
=qaSD
=====END PGP SIGNATURE=====
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 15:37:09 -0800
Terry Ritter <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
> On Fri, 26 Jan 2001 09:07:03 -0800, in
> <[EMAIL PROTECTED]>, in sci.crypt "Paul Pires"
> <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >I also am not clear on the goal. Yes there needs to be bit balancing so that
> >a bias in the input is not recognizable in the output but by doing this
> >hiding,
> >don't you sacrafice another valuable property? Seems like the output would
> >fail a taylored randomness test. You are going to get data that has a
> >prefect
> >distribution of zero's and ones within a block and something else if the
> >block
> >reference is displaced. Right?
>
> It is not necessary for strength or security that a cipher to produce
> random-like output. Most ciphers do so, but such is not necessary.
> Here I think the possible output codes do appear with equal
> probability.
>
> This is a characteristic which represents the inefficiency of balanced
> coding. But since that is a plaintext coding, and is known by both
> designer and opponent, it does not seem particularly worrisome.
Oh, I wasn't saying I found a breach, just that it seems to have an identifiable
appearance & therefore offset from a thoretical ideal. More in the way of
making a note than pointing at a practical fault.
My main comment was in response to suggestions made By John Savard on a way
to fix it. First you need to find out if it's broke and if the fix is better than the
break. As I said before, I think there are ways to avoid the bit balancing
altogether. The interesting part of this is your clear statement of the security
premis and that seems to be "transposition by random direction". I took the bit
balancing part to be "One way you could do it" as a way to enable the
other discussion.
> >Seems like what you'd want would be a method where the transposition
> >works on a pile that is "Probably" balanced but where the deviation from
> >perfect is not correlated to the input or output. I could be screwy here.
>
> I have mentioned the possibility of a statistical or "almost" balance,
> which could be very effective. But it seems like that analysis would
> be much more complicated. We would have to talk about the
> distribution of balance, and how strength changes accordingly, which
> seems beyond what can now be done.
I don't know about that. I think it can be done. But that opinion and
$2.79 might by a cup of coffee.
Paul
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
** 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
******************************
