Cryptography-Digest Digest #550, Volume #13 Thu, 25 Jan 01 18:13:01 EST
Contents:
Re: unknown encryption algorithm ("Douglas A. Gwyn")
Re: Random stream testing. (long) ("Paul Pires")
Re: crypt(3C) algorithm under Solaris 2.6? (Jim Gillogly)
Re: Differential Analysis of "A + (B xor X)" ([EMAIL PROTECTED])
Re: Barrett modular reduction (Bryan Olson)
Re: DES check values (58)
Re: How much of this group's discussion violates the DMCA ("Douglas A. Gwyn")
Re: Differential Analysis of "A + (B xor X)" (Alexis Machado)
Re: NSA and Linux Security (Greggy)
Re: How much of this group's discussion violates the DMCA (lcs Mixmaster Remailer)
Re: How much of this group's discussion violates the DMCA (Darren New)
Re: How much of this group's discussion violates the DMCA (Ichinin)
Re: unknown encryption algorithm ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Fitting Dynamic Transposition into a Binary World (Terry Ritter)
Re: Random stream testing. (long) ("Douglas A. Gwyn")
Re: Echelon in Asia. (Jim)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: unknown encryption algorithm
Date: Thu, 25 Jan 2001 19:30:57 GMT
[EMAIL PROTECTED] wrote:
> plaintext:
> dclient177-193
> some examples of encrypted (all of the same plaintext)
> kUqmnlaqr433-774
> jemuvastu663-255
> aEcofidqd366-512
> Djltfhmpi664-422
> 2dnsymiov322-450
> EEouuclio090-343
The first two characters are evidently a "salt",
or key used in the encryption. Since letters
encrypt to letters, digits to digits, and
punctuation to itself, it must be a simple
ad-hoc scheme.
I looked at the bit level for a simple Vigenere scheme,
assuming ASCII coding, but didn't find one.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Thu, 25 Jan 2001 12:22:10 -0800
Matt Timmermans <[EMAIL PROTECTED]> wrote in message
news:OvNb6.5022$[EMAIL PROTECTED]...
> "Paul Pires" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
<snip>
>
> You're testing PRNGs, right? So you can make as much data as you like. I
> would suggest using 100 meg samples, and accepting as "OK" any result
> between 0.0001 and .9999. Anything outside of that would make me nervous,
Well, I have what I think is a bizzare scheme for a PRNG and I just can't
make it
fail. Not even a little bit looking at gigabytes in every way I can think
of.
I'm searching for what to do now since I am still curious about it and more
testing seems pointless. I guess I was searching for the
"PRNG evaluation process - Level 2 handbook" for clueless newbies and
the mathematically challenged. Pretty unrealistic.
> unless I had several hundred test results. If you get something outside
of
> that "good range", but you're running a whole lot of tests, then make a
new
> or larger sample and run it again -- if it is an artifact of your PRNG,
then
> it should be reasonably consistent.
>
> It seems that you simply stumbled upon a bad description of how to use
> randomness tests. I seem to remember that Marsaglia (sp?) included a very
> nice description of how to interpret the results of his DIEHARD suite.
Yes, he does say "but remember, P's happen" which
I took to mean that results cannot be interperated standalone but
only in the context of the actual sample.
Thanks.
Paul
> > Terry Ritter has made a convincing argument
> > that data sets should be examined for any deviation from
> > a random expectation including the case were the results
> > are "too good".
>
> That is exactly right -- if you run the same tests on multiple samples,
you
> should expect an even distribution of P-values. If you run 1000 tests and
> don't get any results outside of .25-.75, it is very likely that your data
> isn't random.
>
>
>
====== 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! ======
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: crypt(3C) algorithm under Solaris 2.6?
Date: Thu, 25 Jan 2001 12:29:51 -0800
[EMAIL PROTECTED] wrote:
> Does anybody now what encrypt algorithm is used by crypt(3C) under
> Solaris 2.6?
crypt(3C) under Solaris is a hashing algorithm, not an encryption
algorithm. It uses a "salt" of two characters and does 25 iterations
of a runtime-modified DES (26*16 rounds).
> I'm looking for DES encryption under 2.6. Solaris 7 and
> 8 seem to include libraries for these.
There's an encrypt(3C) that claims to provide encryption/decryption
based on crypt(3C) and mentions, but since it doesn't give details
in the man page I wouldn't use it. If you're determined to get DES
under stock Solaris 2.6 you might try this, checking some known DES
validation triples to make sure it's really doing it right.
I suggest SSLeay or OpenSSL. They compile and run fine under 2.6,
especially if you have gcc, and give you lots of options other than
DES.
--
Jim Gillogly
Highday, 4 Solmath S.R. 2001, 20:20
12.19.7.16.10, 9 Oc 13 Muan, Sixth Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Differential Analysis of "A + (B xor X)"
Date: Thu, 25 Jan 2001 20:18:30 GMT
In article <94pq0l$qea$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Alexis Machado" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I'm studying the function "F(X) = A + (B xor X) (mod 2**n)"
differential
> > properties.
>
> That's easy, a change in X is virtually always isolated. I.e consider
> flipping the MSB it must flip the MSB of the output bit.
>
> Besides I would use a linear attack to solve this it would be much
more
> efficient.
>
> For example you can collapse the LSB of A and B into a single bit and
solve
> it. Then once you do that repeat it for the next bit of A and B...
i.e an
> attack with 8 steps.
>
> Tom
>
> Sent via Deja.com
> http://www.deja.com/
>
F(X) is not intended to be a round function.
This work gives a tool (I hope) to analize more complex (round)
functions that use modular additions (mod 2**n).
Consider U and V two differentials and the equation
F(X xor U) xor f(X) = V (1)
The differentials you propose is U = V = 2**63. After reading the paper
you will see that, in this case, any X solves equation (1) with
probability 1, trivially.
But you can go further. Using mod 2**64, for example, you can compute
quickly (O(64)) the probability for more complex differentials:
Example 1:
For U = V = 0x0101010101010101, a random X will solve (1) with
probability 2**(-14.28)
Example 2:
For U = 0x4000000000000001 and V = 0xC000000000000001, a random X will
solve (1) with probability 2**(-2.79)
---
Alexis
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Barrett modular reduction
Date: Thu, 25 Jan 2001 20:19:28 GMT
[EMAIL PROTECTED] wrote:
> In RSA there's an alternate decryption using CRT; in place
> of c ^ d % n, one can do
> A (c ^ d % p) + B (c ^ d % q) % n
> where
> A=q * (q ^ -1 % p)
> and
> B=p * (p ^ -1 % q)
>
> In this case c is of the same magnitude as n (ie 2x p's magnitude). In
> the first round of finding modexp, this is squared, mod p, so you get
> 4x p's magnitude.
>
> Is there a trick, like x %= m before the first round to prevent this?
Yes, and a couple more.
Let:
c_p = c mod p
c_q = c mod q
d_p = d mod p-1
d_q = d mod q-1
Compute,
x_p = c_p ^ d_p mod p
x_q = c_q ^ d_q mod q
Use CRT reconstruction to find the unique m such that
0 <= m < p*q
m mod p = x_p
m mod q = x_q
Below is complete code in Python. Python has arbitrary
size long-integers built in, and it's built-in function
pow(base, exp, modulus) computes base^exp mod modulus.
> This use of A and B is to accelerate the decryption, because A and B
> can be precomputed, and the exponentiations % p and % q should be
> faster than % n.
Garner's algorithm is modestly better for reconstructing the
result mod pq from the mod p and mod q residues. It's in HAC
and the code below uses it in the two-prime case. The code
shown below doesn't take advantage of a precomputed inverse of
p mod q, but the inverse algorithm is quadratic and dominated
by the cubic exponentiations.
> However, now that I have extended Barrett's reduction, I find that for
> me c^d%n is slightly faster than the method with A and B.
I think you have not taken full advantage of the CRT method.
Given two prime factors of roughly equal length, it should be
slightly less than four times faster, assuming the usual
multiplication algorithm.
--Bryan
Python code for RSA decryption using the CRT:
|
| def inverse(x, n):
| """Return the mod n inverse of x."""
| y, a, b = n, 1, 0
| while y>0:
| x, (q, y) = y, divmod(x, y)
| a, b = b, a - b*q
| if a < 0:
| a = a + n
| assert x==1, "No inverse, GCD is %d" % x
| return a
|
|
| def crt_RSA(m, d, p, q):
| """ Compute m**d mod p*q for RSA private key operations."""
| xp = pow(m % p, d%(p-1), p)
| xq = pow(m % q, d%(q-1), q)
| t = ((xq - xp) * inverse(p, q)) % q
| if t < 0:
| t = t + q
| return t * p + xp
|
Sent via Deja.com
http://www.deja.com/
------------------------------
From: 58 <[EMAIL PROTECTED]>
Subject: Re: DES check values
Date: Thu, 25 Jan 2001 20:21:13 GMT
In article <xdWb6.34576$[EMAIL PROTECTED]>,
"madcow" <[EMAIL PROTECTED]> wrote:
> You can get source code for DES in Basic at :
>
> http://home.wxs.nl/~napel/des.htm
Which I just did. Thank you very much.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
Date: Thu, 25 Jan 2001 19:41:09 GMT
Mok-Kong Shen wrote:
> It might be of interest to recall in this connection that
> decades ago there was once a (unrealized) suggestion that
> editors of scientific journals voluntarily submit articles
> about crypto, the publication of which could be of relevance
> to national security, for preview by some institutions.
Of course that raised the issue of what criteria would be
used to judge the impact on national security. The intent
of most of the proponents seemed to be to slow down the
open development of the science, on the assumption that
the national interest would benefit from reduced
understanding slower employment of improved technology.
That evidently begged the question of whether improving
understanding and technology might be better for the
nation and indeed for everybody.
------------------------------
From: Alexis Machado <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis of "A + (B xor X)"
Date: Thu, 25 Jan 2001 20:41:54 GMT
A little mistake. I wrote
> The differentials you propose is U = V = 2**63
Should be
> The differentials you propose is U = V = 2**(n-1)
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Thu, 25 Jan 2001 21:02:59 GMT
> > > And have the courts further upheld the application
> > > of those powers, and noted that the reason for such
> > > permissiveness is the ongoing state of emergency?
>
> > The congress removed the issue from the jurisdiction of the US
Supreme
> > Court. We see this when they say, "This is a political matter" and
> > deny a hearing. They are not allowed to hear the case and they say
> > those words verbatim according to the law passed by congress.
>
> Cites? You'll have to excuse me if I'm not willing
> to take your word for it.
I don't want you to take my word for it. I want you to stop asking for
cites and read the cites I gave earlier. They cite the exact US laws
to support what I claim. If you ask again, I will not bother to
respond.
--
I prefer the fourth amendment over a drug free society.
Did W declare the national emergency over yet and give us
back constitution rule? No? Why am I not surprised?
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: 25 Jan 2001 21:20:37 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
The DMCA exempts encryption research activities. See
http://www.eff.org/ip/DMCA/hr2281_dmca_law_19981020_pl105-304.html:
`(2) PERMISSIBLE ACTS OF ENCRYPTION RESEARCH- Notwithstanding
the provisions of subsection (a)(1)(A), it is not a violation
of that subsection for a person to circumvent a technological
measure as applied to a copy, phonorecord, performance, or
display of a published work in the course of an act of good
faith encryption research if--
`(A) the person lawfully obtained the encrypted copy,
phonorecord, performance, or display of the published work;
`(B) such act is necessary to conduct such encryption
research;
`(C) the person made a good faith effort to obtain
authorization before the circumvention; and
`(D) such act does not constitute infringement under this
title or a violation of applicable law other than this
section, including section 1030 of title 18 and those
provisions of title 18 amended by the Computer Fraud and
Abuse Act of 1986.
`(3) FACTORS IN DETERMINING EXEMPTION- In determining whether
a person qualifies for the exemption under paragraph (2),
the factors to be considered shall include--
`(A) whether the information derived from the encryption
research was disseminated, and if so, whether it was
disseminated in a manner reasonably calculated to advance
the state of knowledge or development of encryption
technology, versus whether it was disseminated in a
manner that facilitates infringement under this title or
a violation of applicable law other than this section,
including a violation of privacy or breach of security;
`(B) whether the person is engaged in a legitimate course
of study, is employed, or is appropriately trained or
experienced, in the field of encryption technology; and
`(C) whether the person provides the copyright owner of
the work to which the technological measure is applied with
notice of the findings and documentation of the research,
and the time when such notice is provided.
`(4) USE OF TECHNOLOGICAL MEANS FOR RESEARCH ACTIVITIES-
Notwithstanding the provisions of subsection (a)(2), it is
not a violation of that subsection for a person to--
`(A) develop and employ technological means to circumvent a
technological measure for the sole purpose of that person
performing the acts of good faith encryption research
described in paragraph (2); and
`(B) provide the technological means to another person
with whom he or she is working collaboratively for the
purpose of conducting the acts of good faith encryption
research described in paragraph (2) or for the purpose
of having that other person verify his or her acts of
good faith encryption research described in paragraph (2).
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
Date: Thu, 25 Jan 2001 21:32:05 GMT
lcs Mixmaster Remailer wrote:
> The DMCA exempts encryption research activities.
> `(C) the person made a good faith effort to obtain
> authorization before the circumvention; and
I wonder what happens if you attempt to make a good-faith effort to obtain
authorization, but said authorization is denied?
> `(D) such act does not constitute infringement under this
> title or a violation of applicable law other than this
> section, including section 1030 of title 18 and those
> provisions of title 18 amended by the Computer Fraud and
> Abuse Act of 1986.
I would have to look these up, but it sure sounds like they're saying
"You're exempt from this law, as long as you're not breaking this law."
> `(B) whether the person is engaged in a legitimate course
> of study, is employed, or is appropriately trained or
> experienced, in the field of encryption technology; and
Don't do this at home, kiddies.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"It says this wine has syphilis."
"I think that's pronounced `sulphates'."
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
Date: Thu, 25 Jan 2001 21:26:19 GMT
In article <94n560$e98$[EMAIL PROTECTED]>,
"David C. Barber" <[EMAIL PROTECTED]> wrote:
> Any informed opinion(s) on this?
Sure;
The DMCA is VOID outside Us soil.
Regards,
Ichinin
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: unknown encryption algorithm
Date: Thu, 25 Jan 2001 21:43:11 GMT
hi douglas,
yes thats what i thought too... do you have a simple code for this
vigenere? with a source code i can try a bit...
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > plaintext:
> > dclient177-193
> > some examples of encrypted (all of the same plaintext)
> > kUqmnlaqr433-774
> > jemuvastu663-255
> > aEcofidqd366-512
> > Djltfhmpi664-422
> > 2dnsymiov322-450
> > EEouuclio090-343
>
> The first two characters are evidently a "salt",
> or key used in the encryption. Since letters
> encrypt to letters, digits to digits, and
> punctuation to itself, it must be a simple
> ad-hoc scheme.
>
> I looked at the bit level for a simple Vigenere scheme,
> assuming ASCII coding, but didn't find one.
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Thu, 25 Jan 2001 22:27:38 GMT
On Thu, 25 Jan 2001 10:57:56 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>Finally, I would like to say that part of the discussions
>on your DT is not about its 'practical' security (i.e.
>whether it is effectively unbreakable) but about whether
>it could offer 'perfect' security (this is one of the
>points that John Savard raised and doubted, if I understand
>correctly).
"Perfect secrecy" is the technical condition where every possible
plaintext is equally likely to represent the ciphertext. This is the
cipher as a Latin square. A "perfect" cipher is not vulnerable to
brute force because traversing each possible plaintext will just
produce every possible message.
The bit-balancing, bit-permutation, and one-time use of each
permutation in Dynamic Transposition allows one to argue that each
block does in fact have the "perfect security" property in that sense.
Moreover, since the permutation is not exposed -- even by
known-plaintext -- the best attack would appear to be some form of
brute force.
In addition I would like to think that the tremendous reduction of
information from stage to stage hides the imperfections which must
exist at earlier stages.
In a previous message, somebody suggested that I might be using two
different definitions of "proof." I think that is the case, and I
suspect it is common.
In the first case, I want "proven secure" to be some sort of absolute
mathematical statement about a cipher. I accept that the
implementation would have to be validated to the theory in some way,
which probably would require experimentation to complete the "proof"
in practice. Still, such a "proof" would be an absolute statement
about the security of the cipher per se. This is the type of proof we
seek, but may never find.
The other case is cryptographic proof as it functions today:
Assumptions are made, and from those, conclusions drawn, all of which
may bear on cryptographic strength. But usually there is no universal
statement of strength which applies against any possible attack
whatsoever. These are "security proofs" in the sense that they are
mathematical proofs pertaining to security, but they are not a
guarantee of overall strength.
I see no reason why a "mechanistic" cipher like Dynamic Transposition
cannot have numerous security proofs; which is to say, mathematical
statements about various aspects of the cipher. These should fit
right into the body of cryptography as it has grown over the past
couple of decades.
We might hope to express the difference between an ideal goal, and
achieved practical reality, and then show that the difference tends
toward zero as the size of some component is increased.
We might be to follow the reduction of information from stage to
stage, and describe that as increasing uncertainty with respect to the
original value. In this way, we might be able to show that any
information exposed by the cipher is simply insufficient to attack an
earlier stage.
Because the main strength of Dynamic Transposition lies in a single
"arbitrary" permutation, it may be one of the cleanest possible
mechanistic ciphers about which one might make mathematical
statements.
---
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: Fitting Dynamic Transposition into a Binary World
Date: Thu, 25 Jan 2001 22:28:38 GMT
On Thu, 25 Jan 2001 15:16:28 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Thu, 25 Jan 2001 06:23:15 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>Since the description in my "Revisited" article is not working, and
>>since -- for some reason -- I am obviously not getting through,
>>perhaps someone else could help out here.
>
>Given your description:
>
>:Some of the analytic and strength advantages of Dynamic
>:Transposition depend upon having the same number of 1's
>:and 0's in each block, which is called "bit-balance."
>:Exact bit-balance can be achieved by accumulating data to
>:a block byte-by-byte, only as long as the block can be
>:balanced by adding appropriate bits at the end. Then the
>:block is ciphered, and another block filled.
>
>:We will always add at least one byte of "balance data,"
>:at the end of a block, and only the first balance byte,
>:immediately after the data, will contain both 1's and 0's.
>:We can thus transparently remove the balance data by
>:stepping from the end of the block, past the first byte
>:containing both 1's and 0's.
>
>and also
>
>: It does bit-balance arbitrary data into a
>: fixed-size block, is not limited in block size (and thus gains
>: efficiency with large blocks), and decoding is trivial.
>
>I thought that I accurately described your algorithm, although I
>worked backwards rather than forwards in determining when to complete
>a block, and I explicitly noted one pathological case.
>
>A block balanced by your algorithm will always consist of one byte of
>balancing data containing both 1s and 0s, followed by zero or more
>bytes of balancing data containing only 1s or only 0s.
That is what I said. It was insufficient.
>Thus, an N byte block can be balanced, when containing N-k bytes of
>input data, if the excess of 1s or 0s in the input data is less than
>or equal to 7 + 8*(k-1); that is, N-1 bytes can be balanced with an
>excess of 7 1s or 7 0s or anything in between, N-2 bytes can be
>balanced with an excess of 15 1s or 15 0s or anything in between. Or
>can they?
>
>It might happen that I have N-2 bytes of balanced data followed by one
>byte of all 1s. Let's say that each of the first N-2 bytes has 4 1
>bits and 4 0 bits, so that the first N-2 bytes are perfectly balanced
>no matter where I truncate them, for simplicity in what follows.
>
>If I try to balance that by your algorithm, I find I have eight excess
>1s, so I can't put N-1 bytes of data in my N byte block.
>
>How about N-2? Now, my data is *too* balanced. My first balancing byte
>cannot be all 1s or all 0s, or it won't decode. But my second
>balancing byte must be all 1s or all 0s. So those two bytes together
>can't balance!
>
>So I have to balance the block by putting in N-3 bytes of balanced
>bits, followed by one byte with 4 0s and 4 1s, followed by an
>all-zeroes byte and an all-ones byte (in either order).
Right. Good catch.
Only now do I understand a previous comment that suggested allowing f0
balancing, as well as ff and 00.
The bit-balancing flag need have only 7 codes (e.g., 01, 03, 07, 0f,
1f, 3f, 7f) to cover all the balancing it can do with a 1-bit flag.
All reaming codes could be used as part of the balancing process after
the flag. We know about 00 and ff, but the others are available for
use; perhaps 55. (Something like this is needed to pad out a partial
block anyway, and I actually implemented it, but felt that was too
much detail for the article.)
My goal would be to minimize the extraction effort. Clearly, the
balancing or encoding end is going to need byte-by-byte bit-counts in
any case. If necessary I would spend a little more on the encoding
end to reduce decoding to as much of a triviality as possible.
So for decoding we would first suck up any padding 55's at the end.
Then the rest is the same -- we skip back until we get something other
than ff or 00, and skip that too. That's it.
>Thus, although your description of your algorithm didn't include
>backtracking, there is in fact a slight need for it.
While I would prefer to have no backtracking, putting one char back is
a common feature in some algorithms.
>A modification of your algorithm, making the single balancing byte of
>the form 01111111, 00111111, ... 00000001,
That's what I do.
>and using the bit pattern
>11110000 *along with* 00000000 and 11111111 as an allowed value for
>the second and subsequent balancing bytes, would eliminate this
>complexity.
Yes. With backtracking, that should solve the problem. The actual
padding value would need to be bit-balanced, and not a value used for
the first balancing byte, but otherwise could be anything. I would
expect this additional value would be fairly rare, perhaps 1 time in
16, thus representing a half a bit of overhead per block on average.
>I also note that your original Dynamic Transposition article is from
>1991, so it may well be the first proposal ever openly made for any
>form of polyalphabetic block encipherment.
Oh, surely not!
I don't see Dynamic Transposition as "polyalphabetic." Normally,
"polyalphabetic" refers to some necessarily small fixed set of
alphabets. But Dynamic Transposition does not select from among a
small subset of permutations; instead the idea is to build any
possible permutation.
In the design, I was attempting to achieve Shannon perfect secrecy in
the context of individual blocks, instead of messages.
It was also an attempt to cipher indirectly, in a way that did not
expose the actual cipher transformation and thus invite attack.
>Thus, even if my claim that
>one can avoid the overhead of bit-balancing by doing something just as
>good with substitution is true, that has less impact on the
>significance of Dynamic Transposition than I had thought.
I doubt that substitution could be "just as good." Resolving that
issue would seem to require a comparable alternative design which
could be examined and compared.
Thanks for exposing the problem with the bit-balancing description in
the "Revisited" article.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random stream testing. (long)
Date: Thu, 25 Jan 2001 21:39:50 GMT
Paul Pires wrote:
> If handy, could you provide me with a name or a link to
> one or two such papers?
The first one to come to mind is "'Cracking' a Random Number
Generator" in Cryptologia Vol. I No. I. There were other
articles in later issues of Cryptologia, but I'm away from
my collection at the moment so I can't browse them to find
particularly good examples.
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Echelon in Asia.
Reply-To: Jim
Date: Thu, 25 Jan 2001 22:55:07 GMT
On Wed, 24 Jan 2001 23:32:40 +0100, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>
>
>Abe Lin wrote:
>>
>> We've been seeing a bit about echlon, but I haven't heard anything
>> in Asia yet. Given Chinese Government's nature, they'd really surprise
>> me if they don't have one.
>
>The technique is certainly within the reach of many countries
>since quite a time.
NSA assists the government of the PRC with such things.
(Two somewhat less than democratic countries!)
Presumably it's targetted against Russia.
>For example, after the
>unification of Germany it was discovered that East Germany
>had had in Berlin a (small) station intercepting among others
>communications from the office of the Chancellor of West
>Germany.
Something they were perfectly entitled to do. Be rather silly
to.
--
___________________________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
'Crematorium plans put on back-burner.'
-- Selkirk Advertiser.
__________________________________________
------------------------------
** 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
******************************
