Cryptography-Digest Digest #856, Volume #8 Wed, 6 Jan 99 17:13:06 EST
Contents:
Re: PGP International (fungus)
Re: M-94 Replica ("Dave Smith")
Re: What is left to invent? (Darren New)
Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
Help me with this crypto ! ([EMAIL PROTECTED])
Re: commercial digital watermark systems: results? (Medical Electronics Lab)
MAGENTA question... (John Savard)
Looking for pseudo-random number generators ("Mike DeTuri")
Re: M-94 Replica (wtshaw)
Re: On leaving the 56-bit key length limitation (wtshaw)
Re: Sapphire II key length vs. US Export Law (Jan Garefelt)
----------------------------------------------------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: PGP International
Date: Wed, 06 Jan 1999 13:07:14 +0100
Jason Shea wrote:
>
> Hi all,
>
> i figure ill probably get kicked in the ass for this question, but, is there
> a difference between PGP, and PGP international. Nothing in the manuals seem
> to indicate that it is in anyway different...
>
There's no diffference in functionality, the difference is a legality.
IIRC, the physical difference is in the RSA library used by the program.
One uses the official library (from RSA), one doesn't (it uses a clone).
> Im told by several people that the PGP international version is considerably
> weaker than the american version.
>
Not true.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Dave Smith" <[EMAIL PROTECTED]>
Subject: Re: M-94 Replica
Date: Wed, 6 Jan 1999 15:07:33 -0500
JTong1995 wrote in message <[EMAIL PROTECTED]>...
>.................................................I was wondering if anyone
>knew if these were the historically correct mixed alphabets used on the
>original M-94, or were they merely put together by the author to
demonstrate
>the concept? If I have to choose, I'd prefer to use the historically
accurate
>ones.
Friedman's book, (Military Cryptanalytics, Part II, Volume 1 by Lambros D.
Callimahos and
William F. Friedman, Aegean Park Press (C-44), 1985.) uses the following
set:
ID Letters Around The Rim
B 1 ABCEIGDJFVUYMHTQKZOLRXSPWN
C 2 ACDEHFIJKTLMOUVYGZNPQXRWSB
D 3 ADKOMJUBGEPHSCZINXFYQRTVWL
E 4 AEDCBIFGJHLKMRUOQVPTNWYXZS
F 5 AFNQUKDOPITJBRHCYSLWEMZVXG
G 6 AGPOCIXLURNDYZHWBJSQFKVMET
H 7 AHXJEZBNIKPVROGSYDULCFMQTW
I 8 AIHPJOBWKCVFZLQERYNSUMGTDX
J 9 AJDSKQOIVTZEFHGYUNLPMBXWCR
K 10 AKELBDFJGHONMTPRQSVZUXYWIC
L 11 ALTMSXVQPNOHUWDIZYCGKRFBEJ
M 12 AMNFLHQGCUJTBYPZKXISRDVEWO
N 13 ANCJILDHBMKGXUZTSWQYVORPFE
O 14 AODWPKJVIUQHZCTXBLEGNYRSMF
P 15 APBVHIYKSGUENTCXOWFQDRLJZM
Q 16 AQJNUBTGIMWZRVLXCSHDEOKFPY
R 17 ARMYOFTHEUSZJXDPCWGQIBKLNV
S 18 ASDMCNEQBOZPLGVJRKYTFUIWXH
T 19 ATOJYLFXNGWHVCMIRBSEKUPDZQ
U 20 AUTRZXQLYIOVBPESNHJWMDGFCK
V 21 AVNKHRGOXEYBFSJMUDQCLZWTIP
W 22 AWVSFDLIEBHKNRJQZGMXPUCOTY
X 23 AXKWREVDTUFOYHMLSIQNJCPGBZ
Y 24 AYJPXMVKBQWUGLOSTECHNZFRID
Z 25 AZDNBUHYFWJLVGRCQMPSOEXTKI
That set is confirmed in several texts and articles. Note that it is
different from the set used on the Pampanito web site in three instances
(lines 7, 10, and 11). I think the Pampanito set is in error, and that the
set from Friedman is correct.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
Date: Wed, 06 Jan 1999 18:12:24 GMT
> Darren New ([EMAIL PROTECTED]) wrote:
> : The only thing I can think of is the theory behind making a block
> : cypher's S-boxes secure and knowing it (rather than just making it real
> : complex and hoping there's no unexpected hole in it).
>
> And that one is probably equivalent to the "halting problem", which means
> there's no solution.
I'd be suprised at that. S-boxes are finite, after all.
> Anonymous digital cash requires doing a blind signature of piles of copies
> of something. Can we get out of that?
Actually, it only takes one blind signature, but lots of unblindings.
Besides, as has been pointed out, the delivery can't be anonymous. I'm
pretty sure there are other theoretical ways of doing anonymous cash
that sadly are unlikely to pan out while all the laws are in effect
preventing their implementation.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
Date: Wed, 06 Jan 1999 17:57:16 GMT
In article <76vmv9$hg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Harald Brinck) wrote:
>
> > 4. ADDING COMPRESSION
> [...]
> > g. the plaintext is compressed two times before encipherment, by a
> > known algorithm.
>
> > The new unicity calculation begins as the former one:
>
> > H(K) = log2(2^56) = 56 bits
> > |M| = log2(2^8) = 8 bits/compressed-character
>
> > while for H(M) we need now to transform units:
>
> > H(M) = log2(English) = 1.2 bits/character (the same as given in 3.)
> > 1 character = 1/2 compressed-characters
> > H(M) = 1.2*2 = 2.4 bits/compressed-character
>
> One of the effects of compression is that the probability/frequency of
> each character is (approximately) the same after compression.
Which character? One needs to distinguish *different* chraracter units, as I
explained in the posting and as I used above. Re-quoting what I wrote before:
If the plaintext is compressed before encipherment, then we rightly expect
its entropy *per compressed character* to increase -- even though its
entropy *per English character* does not increase.
As I wrote ... "This is often confusing ...." .... but one can view this in an
alternative way which may be more iluminating: The same amount of
English-information (ie, information as what you do not expect; surprise) is
present before and after compression -- but now in half the space.
Thus, the entropy per English-character MUST be the same (ie, not
approximately, but equal) before and after compression -- if you decompress
you will get the same text, the same entropy, the same surprise. However, the
entropy carried per compressed-character must be higher -- since you have
less space, less number of characters, and yet they must represent the same
amount of "surprise".
> Otherwise one could use Huffman or arithmetic encoding to compress the data
> even further.
I do not follow the logic of your connective "otherwise" -- perhaps because
of my remark above. However, I would like to make a comment that may help,
since this point is often a stumbling block for many:
For large (infinite) data length, the compressed data can be compressed even
further if and only if the entropy limit for the uncompressed data that can
be obtained from it has NOT been reached. For English, this is
(approximately) 1.2 bits/character -- only. For example, if I have a file of
English text with one million characters (usually 1 Mbyte) then I can expect
to compress it down to 0.15 Mbyte at most. However, I note that for small
data lengths as considered here, 20 bytes, one may be forced to stop much
sooner (this can also be theoretically explained, but the idea is clearer by
comparing with the infinite length case).
> So not only does the compressed text include all 256 possible
> characters, all of these characters have the same probability !
Why do you think they have the same probability? Check into any compressed
file and you will see it is not so. The reason is my comment above.
>
> Doesn't that mean that
>
> H(M)=|M|
>
> and the unicity distance in infinite ?
Yes and no ;-)
It depends on what M is. If M is a random collection of characters, all
equally likely -- yes. If M is English text -- no.
But, you are right. There is a problem with the current definition of unicity,
which is what I commented in the message, to requote:
I call attention to the fact that the denominator of the formula above
may be zero in some cases of interest -- currently, at least of
theoretical interest. This means that the formula will fail to provide
an answer in such cases. I expect to address this situation in a new
and expanded formulation of unicity, which will follow several aspects
to be advanced below -- specially in regard to the Sections on
identification of unicity, different unicity definitions and "added
trust".
Gr�sse,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Help me with this crypto !
Date: Wed, 06 Jan 1999 19:17:26 GMT
I need some help with this crypto (or algorithm).
I have a special box where you input some numbers and the box give you
some numbers back.
The first person who solves this will get a 40 dollars reward.
I have some examples where i have input some numbers.
Examples:
Input Output
======== ========
11111111 28234105
00000000 84335240
00000001 74331395
00000002 12539925
00000003 09409071
99999999 84348439
88888888 15936752
10000000 25903915
12345678 59340407
(if i input these numbers i always get the same output)
Best regards
Simon
PS. Could it be randomly generated numbers ??
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Crossposted-To: uk.transport,comp.dsp
Subject: Re: commercial digital watermark systems: results?
Date: Wed, 06 Jan 1999 12:30:34 -0600
[EMAIL PROTECTED] wrote:
>
> If anyone has had any experience using a commercial digital watermark system
> for images, video or audio, I would be interested to hear results regarding
> practicality and robustness. I am trying to figure out which to use, and which
> to avoid.
Do a web search on "stirmark". They have an
analysis on how to break several commercial
packages that should be interesting.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: MAGENTA question...
Date: Wed, 06 Jan 1999 20:30:45 GMT
The description of Magenta in the .PDF file was couched in
mathematical terms, and was difficult to read. One detail seems to be
missing from it.
The basis of Magenta is an S-box with 8 bits of input and 8 bits of
output, called f(x). f(255) = 0, and for other values of x, f(x) =
alpha ^ x where alpha is an *unspecified* primitive element of GF(256)
with the generating polynomial is x^8 + x^6 + x^5 + x^2 + 1.
That's my question - what is alpha, or better yet, is there a table of
this S-box? There is an assembly-language program for generating it in
the document, but that uses 101 (hex?) and not 101100101 (binary) to
XOR things down...after left shifts, and somewhere else the cycle
decomposition is noted, and the fact that f(x+1) = 2*f(x) whenever
both f(x+1) and f(x) are in the range 1...127 (which indicates
something about the mechanics of the assembly language program...)
The program uses 1 as a start value, then shifts it, and since the
S-box is to be a bijection, the S-box can't be just 1, 2, 4, 8, 16,
32, 64, 128, 1, 2, 4... and 101 is less than 256, so it can't just be
that 101 is a _decimal_ number. 256+64+32+4+1 equals 256+101...
Ah. The carry bit goes out, so XORing with 256 is already taken care
of...
The S-box contains the following:
1, 2, 4, 8, 16, 32, 64, 128, 101, 202, (404-256) xor 101...
I take it?
Anyways, given f(x), for those who are interested, Magenta goes like
this:
A(x,y) = f(x xor f(y))
[x and y are both bytes]
PE(x,y) = (A(x,y),A(y,x))
[that is, PE(x,y) is A(x,y) catenated with A(y,x)]
pi(x(0), x(1), ... x(15)) = (PE(x(0),x(8)), PE(x(1),x(9)),
PE(x(2),x(10), ... PE(x(7),x(15)))
and T(w) = pi(pi(pi(pi(w))))
[where w is a 16-byte vector]
S(x(0),x(1),x(2),...x(15)) =
(x(0),x(2),x(4),...x(14),x(1),x(3),x(5),...x(15))
We now define C(n,w), where n is a number, and w a 16-bit vector, as
follows:
C(1,w) = T(w)
C(n+1,w) = T(w xor S(C(n,w)))
Finally, with all these definitions, Magenta is a Feistel cipher.
Each Feistel round is expressed as taking (X(1),X(2)), where each X is
half the block, 64 bits in length, and replacing it with (X(2),X(1)
xor F(X(2),SK(n))), where n is the round number.
The F function equals the first eight bytes of S(C(3,(X(2),SK(n)))).
Untangling this long definition into some clear diagrams will take a
while!
The key schedule is *too* simple...
for a 128-bit key, the key is divided into parts, K1, K2, and the
subkeys for the six rounds in order are K1, K1, K2, K2, K1, K1.
for a 192-bit key, K1, K2, K3, K3, K2, K1.
for a 256-bit key, K1, K2, K3, K4, K4, K3, K2, K1.
It appears that, except for swapping halves, Magenta is reciprocal.
The first paper giving a cryptanalysis of Magenta incorrectly gave the
key schedule as K1 K2 K1 K1 K2 K1, it appears.
Originally, the F function was going to be the first eight bytes of
S(C(7,(X(2),SK(n)))), but the number of rounds inside the f-function
was reduced because of a possible weakness. Even so, Magenta is deeply
nested with complexity.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: "Mike DeTuri" <[EMAIL PROTECTED]>
Subject: Looking for pseudo-random number generators
Date: Wed, 06 Jan 1999 18:45:38 GMT
I'm looking for some (3-5) pseudo-random number generators, preferably in C
source. I've spent a few days searching from Excite and through Deja News
but haven't found anything.
Basically what I want to do is create a stream cipher where the key seeds
three to five PRNGs of different types. Then the program XORs the various
outputs together to create a keystream which can then be XOR'd with the
plaintext. I have read Applied Cryptography and saw this same thing
suggested with LFSRs and implemented in A5. I was just wondering what would
happen if someone tried the same thing with PRNGs instead of LFSRs.
I'm planning on using a salt value initialization vector similar to what is
suggested in CipherSaber so that you don't have to rekey each message.
As usual, if this has already been discussed please just point me to an
article or page.
Thanks in advance,
Mike
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: M-94 Replica
Date: Wed, 06 Jan 1999 14:26:10 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JTong1995) wrote:
> As an ACA member with too much free time on my hands, and access to a
> fully functional machine shop, I've started work on making a replica of the
> M-94 Cipher device (aka. a Jefferson Wheel). It's only going to be a general
> (rough) replica made for fun. I made the first disk on a lathe, where it
> polished well, but cutting it off from the rest of the cylinder proved too
> difficult and time consuming. Now I'm using a drill press and cutting the
> disks out of a 1/4 inch plate of aluminum, then polishing the edge of the disk
> (where the letters go) on the lathe. I then plan to use a vice, a hammer, and
> the letter dies to put the letters around the circumfrence of the disks. A
> little hard to line the spacing up exactly, but it's close enough for
fun work.
> Then some permanent ink into the letter grooves, number the sides of the disk,
> run a bolt through the center, and I think I'm done.
> I am currently planning on using the 25 disks with the mixed alphabets
> found in the SECRET CODE BREAKER I book by Reynard. I was wondering if anyone
> knew if these were the historically correct mixed alphabets used on the
> original M-94, or were they merely put together by the author to demonstrate
> the concept? If I have to choose, I'd prefer to use the historically accurate
> ones. Does 25 disks sound like the right number, or where ther 36 disks and 25
> were choosen for each days use based on a daily key? Lastly, does anyone know
> if the mixed alphabets were simply random ones, or were they choosen in some
> way as to make cryptanalysis more difficult? Thanks for any insights. Jeff
> Tong
I guess it has been a couple of months ago there was a discussion on the
matter. Try the archives as we worked to resolve two sets of disks to
their original values; Savard did some magic with analysis of some
photographs to resolve some discrepancies. From my mathematical analysis
of them, I seem to show that some effort was made in picking a better sets
than random could create, and also show that even these might be
improved. Of the two sets, one was markedly better than the other.
Sorry, but can't pull up the info here on cue, lots of water under the
bridge since then, and lot of isolated places to look.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
In Base 81: y\7RBRNBN 6*1O+aDR* QBOMR1OhE \*/XtS4+~ ;g/4,Y=Jn 6)IL;OC;H o93bR?bk\
v+/G(J=lE Ni@8L*x)I L(!\+O6;E Hu~u;Ho;R 9lX=g3x*n :Y(Yce;w~ 3l(9kS;NT YfmnPX=ya
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On leaving the 56-bit key length limitation
Date: Wed, 06 Jan 1999 14:18:37 -0600
In article <77085r$s8s$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In article <76vmv9$hg$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Harald Brinck) wrote:
> >
> > and the unicity distance in infinite ?
>
> Yes and no ;-)
>
> It depends on what M is. If M is a random collection of characters, all
> equally likely -- yes. If M is English text -- no.
There is lots of room in between. It is common practice for active
compression to be used some circles. As the text is going to have less
redundancies, it makes it harder to recover through analysis; there are
several forms, but what I am referring to is the international language of
telegraph abreviations. I've used it for 40 years, and it looks something
like this:
gud condx make fer a fb qso = bcnu agn sn om = tnx es 73 de me to u ar
Needless to say, if you write communications in this kind of lingo, and
encrypt to boot, it can be a devil to solve. The ACA for instance does
not accept challenges with it. The system of abbreviations is based
loosely on a set of published representations, but allows for any use of
phoentically similiar structures, or just drop in the usual word if there
is no known or remembered substitute.
A stenographer or court reporter does lots of active compression as well.
>
> But, you are right. There is a problem with the current definition of unicity,
> which is what I commented in the message, to requote:
>
> I call attention to the fact that the denominator of the formula above
> may be zero in some cases of interest -- currently, at least of
> theoretical interest. This means that the formula will fail to provide
> an answer in such cases. I expect to address this situation in a new
> and expanded formulation of unicity, which will follow several aspects
> to be advanced below -- specially in regard to the Sections on
> identification of unicity, different unicity definitions and "added
> trust".
>
I find your posting on the matter interesting. They speak well to people
getting too excited about throwing terms around that are not that current,
well-defined, and/or do not have the currency they once had is a much
different and simpler world. I will try to keep an open mind about
intercity as you cultivate your ideas.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
In Base 81: y\7RBRNBN 6*1O+aDR* QBOMR1OhE \*/XtS4+~ ;g/4,Y=Jn 6)IL;OC;H o93bR?bk\
v+/G(J=lE Ni@8L*x)I L(!\+O6;E Hu~u;Ho;R 9lX=g3x*n :Y(Yce;w~ 3l(9kS;NT YfmnPX=ya
------------------------------
From: [EMAIL PROTECTED] (Jan Garefelt)
Subject: Re: Sapphire II key length vs. US Export Law
Date: 06 Jan 1999 21:49:03 +0100
I (Jan Garefelt) wrote in part:
> All Snoopy has to do to find Charlie is to follow the 2^16 tracks made
> by Charlie and his friends.
I hope that this is obvious, but I state it all the same: it doesn't
matter if the hotel has 2^64 or 2^gazillion rooms. It is the number of
people in the crowd that counts.
> Charlie is still out of luck.
...because he has to few friends.
--
Jan Garefelt [EMAIL PROTECTED]
(You know what part to remove to get my mail address!)
http://www.synernet.com/public/sternlight-faq
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
