Cryptography-Digest Digest #963, Volume #9 Sun, 1 Aug 99 10:13:04 EDT
Contents:
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is ("Douglas
A. Gwyn")
Re: Modified Vigenere cipher (Jim Gillogly)
Re: Modified Vigenere cipher (JPeschel)
Re: Looking for RC4 alternative ([EMAIL PROTECTED])
Re: Modified Vigenere cipher (Jim Gillogly)
Re: Modified Vigenere cipher ("Douglas A. Gwyn")
Another random question ("Jeffery Nelson")
Re: Modified Vigenere cipher (Castover80)
Re: Bad Test of Steve Reid's SHA1 (Jaime Suarez)
Re: Modified Vigenere cipher (JPeschel)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Ariel Scolnicov)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
("donald tees")
Re: ? PGP, RSA and ElGamal ? (Gallicus)
Re: bits and bytes (Thomas Pornin)
SCOTT19U CONTEST UPDATE (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is
Date: Sun, 01 Aug 1999 01:19:11 GMT
[EMAIL PROTECTED] wrote:
> ... A megabyte is 2^20 bytes so megabyte is not always 2^23 bits?
"Megabyte" is ambiguous even if you mean 8-bit bytes. Some people
mean 2^23 bits, while others mean 2^9*5^6 bits. ISO came up with
some new, unambiguous prefixes to replace Kilo-, Mega-, etc., but
nobody seems to use them.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Modified Vigenere cipher
Date: Sat, 31 Jul 1999 19:22:00 -0700
JPeschel wrote:
>
> >[EMAIL PROTECTED] writes:
>
> >What is the "average column IC" for a ciphertext ?
>
> Fauzan Mirza wrote some code in C called vigsolve to solve
> Vigeneres. I believe it also gives the IC for a couple other
> polyalphabetic substitution systems.
Period determination with I.C. is independent of the type of
periodic polyalphabetic system: it measures the roughness of
each column, but expresses no opinion on how that roughness
came about. If it gives the IC for Vigenere it will also give
it for Beaufort, Variant Beaufort, Porta, and the mixed alphabet
versions.
--
Jim Gillogly
Hevensday, 9 Wedmath S.R. 1999, 02:20
12.19.6.7.7, 12 Manik 15 Xul, Third Lord of Night
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Modified Vigenere cipher
Date: 01 Aug 1999 02:01:02 GMT
>[EMAIL PROTECTED] writes:
>What is the "average column IC" for a ciphertext ?
Fauzan Mirza wrote some code in C called vigsolve to solve
Vigeneres. I believe it also gives the IC for a couple other
polyalphabetic substitution systems.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Looking for RC4 alternative
Date: Sun, 01 Aug 1999 02:52:45 GMT
In article <7nvsbp$bn4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Aha, this may explain why my results from a similar algorithm.
> Essentially, I took the final table stirring part of the key
> schedule from David Wheeler's WAKE, cut it down to 8 bits and
> came up with:
>
> if( x == 0 ) t[256] = t[0];
> x = (x + 1) & 255;
> y = y ^ t[x ^ y];
> t[x] = t[y];
> t[y] = t[x + 1];
> out = t[t[x] ^ t[y]];
>
> I've been putting it through the DIEHARD tests and it did not
> seem to do as well as RC4.
Probably cuz you get a lot of 'x == y' conditions. In RC4 there is no
fixed point where 'x == y' will result in a zero output. There are
zero points in RC4 though (it's possible to fix either x or y and find
the other which will result in a zero output).
> However, I think we may agree that changing the 't' calculation
> in RC4 would be a good way to modify it without changing some
> of its useful characteristics (cycle lengths etc).
Maybe not. Your
y = y ^ t[y ^ x]
is not close from being in RC4, the line should read
y = (y + S[x]) mod 256
or in your code
y ^= S[x];
Why not just keep RC4 the same? If you really want to change something
change the last line to
O = t[t[x] + ~t[y]]
or something ... This has absolutely no effect on the 'security' of
it, makes it slower and intrigues others ...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Modified Vigenere cipher
Date: Sat, 31 Jul 1999 19:19:27 -0700
JPeschel wrote:
>
> [EMAIL PROTECTED] writes:
>
> >"MilCryp" in this case denoted the later edition by Callimahos
> >& Friedman, but the name is also used with the earlier Friedman
> >version.
>
> Doug, what is the difference between the editions? Do you think
> reading the Friedman edition, rather than Callimahos, is sufficient?
Speaking for myself, Military Cryptanalytics I and II (Friedman &
Callimahos, Callimahos & Friedman) is much more complete, readable,
and useful than Military Cryptanalysis I-IV (Friedman). However,
Mil. Cryptanalysis IV has some material that's presumably covered
in Mil. Cryptanalytics III (still mostly classified, Callimahos) --
so you can't just dump one set and concentrate on the other. If
your budget is short, I'd get Military Cryptanalytics first.
--
Jim Gillogly
Hevensday, 9 Wedmath S.R. 1999, 02:13
12.19.6.7.7, 12 Manik 15 Xul, Third Lord of Night
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Modified Vigenere cipher
Date: Sun, 01 Aug 1999 03:20:06 GMT
JPeschel wrote:
> what is the difference between the editions [of MilCryp]? Do you
> think reading the Friedman edition, rather than Callimahos, is
> sufficient?
Sufficient for what? While early portions of Callimahos' edition
were heavily based on Friedman's edition and don't add much, later
portions add significant new material, and Callimahos' Part III (which
is for the most part not available to the public) is based entirely
on original material, most of it published in monographs and/or the
NSATJ. The Callimahos series also has much additional material in
its Appendices (Volume 2 of Parts I & II), expecially the Zendian
problem, which is highly recommended practice for the student cryppie.
------------------------------
From: "Jeffery Nelson" <[EMAIL PROTECTED]>
Subject: Another random question
Date: Sat, 31 Jul 1999 23:13:15 -0000
Here's something to consider. As we know, every computer in the world (or
type of computer) processes things at different speeds. Compare a 286's
compile time (in something such as Turbo C++ 3.0) to a Pentium 233. This
makes for interesting possibilities. Say you used your internal clock to
seed random numbers. In this was wouldn't the seeds be unique to that
machine? Or couldn't you make it that way by slowing the PRNG's iteration
that slowed it PRN(x) times per loop?
------------------------------
From: [EMAIL PROTECTED] (Castover80)
Subject: Re: Modified Vigenere cipher
Date: 01 Aug 1999 05:13:03 GMT
Jim Gillogly <[EMAIL PROTECTED]>wrote:
>Speaking for myself, Military Cryptanalytics I and II (Friedman &
>Callimahos, Callimahos & Friedman) is much more complete, readable,
>and useful than Military Cryptanalysis I-IV (Friedman). However,
>Mil. Cryptanalysis IV has some material that's presumably covered
>in Mil. Cryptanalytics III (still mostly classified, Callimahos) --
>so you can't just dump one set and concentrate on the other. If
>your budget is short, I'd get Military Cryptanalytics first.
Thanks for the info, Jim.
I have the Dobbs crypto CD with the Freidman volumes 1-4 on it.
I wish, now, that the Callimahos volumes were included, too.
I'm still trying to find some of the crypto stuff that has been recently
declassified. The NSA site gives a huge list of what has been turned
over to archives, but those documents don't seem to be available on-line
at NARA yet.
Joe
------------------------------
From: [EMAIL PROTECTED] (Jaime Suarez)
Subject: Re: Bad Test of Steve Reid's SHA1
Date: Sat, 31 Jul 1999 04:01:19 +0200
Reply-To: [EMAIL PROTECTED]
[...]
>
>For "abc" I get 672533D0 EBB3B826 353EBF7D 4B51FE4F 26D5BAAF where I
>think I should be getting A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D.
>
>Admittedly, it has been a long time since I last compiled a program in
>C. I plan to use C to turn the code into a .dll that I may call from
>my current development platform, SAS. I enter the text to be encrypted
>without the quotes. It appears that I have to press <enter> after that
>text, followed by a <ctl>z and another enter.
[...]
>Any suggestions you have would be appreciated.
Try to enter abc and then press CTRL-Z or whatever your system uses to mark
an end of file. Otherwise you are probably hashing abc+Enter.
If your program can hash files you can also write a file wich contains abc
and ends just after 'c'.
I had exactly the same problem yesterday :-)
--
Jaime Suarez Linux user #114.688
http://come.to/MundoCripto PGP Key id 0x8EE38D89
Backup not Found,(R) Reintentar, (A) Anular, (S) Sollozar amargamente
========================================================================
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Modified Vigenere cipher
Date: 01 Aug 1999 06:46:05 GMT
>Douglas A. Gwyn wrote:
>While early portions of Callimahos' edition
>were heavily based on Friedman's edition and don't add much, later
>portions add significant new material, and Callimahos' Part III (which
>is for the most part not available to the public) is based entirely
>on original material, most of it published in monographs and/or the
>NSATJ. The Callimahos series also has much additional material in
>its Appendices (Volume 2 of Parts I & II), expecially the Zendian
>problem, which is highly recommended practice for the student cryppie.
Thanks, Doug. I was, as you suspected, interested in finding out
what the Callimahos series offered that isn't in the Friedman.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Ariel Scolnicov <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: 01 Aug 1999 09:47:01 +0300
[EMAIL PROTECTED] writes:
[...]
>
> I think for the most part we can understand 'byte = octet'. For the
> few cases it is not you can specify. I think it would be prudent in
> any document to first specify what your definition of a byte is then
> continue. Or simply use octet or '8x1 binary matrix' or 'numbers in GF
> (256)' or ...
Unfortunately, I don't know of any computers with an instruction set
that makes dealing with GF(256) easy. Most modern computers can use
Z/256Z quite easy, but that's a totally different ring (and it's not
even a field). For instance, in GF(256), 1+1=0.
[followups set to groups where GF(256) could conceivably be
on-topic]
--
Ariel Scolnicov |"GCAAGAATTGAACTGTAG" |[EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ NEW IMPROVED URL!
72 Pinhas Rosen St. |Tel: +972-3-7658520 (Main office)`--------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 http://3w.compugen.co.il/~ariels
------------------------------
From: "donald tees" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sat, 31 Jul 1999 21:42:25 -0400
[EMAIL PROTECTED] wrote in message <7nvkc9$l7m$[EMAIL PROTECTED]>...
>
>> Oh really. I'm using 5-bit baudot code on a 12-bit CPU with 6-bit
>> characters. An 8-bit byte is useless to me. _*YOUR*_ definition of a
>> byte is not, and never will be definitive. It is probably based on
>your
>> lack of experience with CPU architectures.
>
>But most (around 90%) of public processors are octet based. Most
>microcontrollers and desktop computers use that convention. For
>example if you hooked up a serial port to your processor and a x86 what
>is the length of a character? ...
>
Five, six, seven, eight or nine bits, as a rule. Seldom find 10 any more.
Eight seldom. Seven by standard. Not eight.
------------------------------
From: [EMAIL PROTECTED] (Gallicus)
Subject: Re: ? PGP, RSA and ElGamal ?
Date: Sun, 25 Jul 1999 11:14:08 GMT
On Sat, 24 Jul 1999 13:34:05 GMT, [EMAIL PROTECTED] (Gallicus) wrote:
>As you see, the other party needs a = 765 (secret exponent).
I got it at last !
The sender of the message needs to know the value 949, not how it has been
computed (2 ^ 765 mod 2579).
765 is actually receiver's secret key.
Receiver's public key is p = 2579, alpha = 2 and beta = 949.
System works as with RSA.
Gallicus.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: bits and bytes
Date: 1 Aug 1999 12:00:40 GMT
According to Douglas A. Gwyn <[EMAIL PROTECTED]>:
> "char" type must be able to accurately represent EITHER 0..255 OR
> -127..127
I would like to insist on that point: the range is -127..127, not
-128..127. This is for computers that store signed types with a sign
bit and the absolute value; this was the case for the PDP-11 (I think,
correct me if I am wrong). This is rare nowadays since it makes addition
and substraction a bit more complicated, and it also means that there is
a 'negative 0' that is not equal to 0 in memory.
What ANSI says (according to K&R and other sources) is that the integer
types may represent any number in the following ranges:
char 0 127
signed char -127 127
unsigned char 0 255
short -32767 32767
unsigned short 0 65535
int -32767 32767
unsigned int 0 65535
long -2147483647 2147483647
unsigned long 0 4294967295
When you cast a value from a type to another, if the value may be
represented in both types, then it is conserved. Otherwise the result is
undefined. When you add or substract or multiply or whatever two integer
values, the two values are first promoted: the rules here depend on
the actual sizes of the types.
If one operand is 'unsigned long', then the other is converted to
'unsigned long'.
Otherwise, if one operand is 'long' and the other is 'unsigned int',
the 'unsigned int' is converted to 'long' if a 'long' can represent any
value hold by an 'unsigned int'; otherwise both operands are converted
to 'unsigned long int'.
Otherwise, if one operand is 'long', the other is converted to 'long'.
Otherwise, if one operand is 'unsigned int', the other is converted to
'unsigned int'.
Otherwise, both operands are converted to 'int'.
[this is from the K&R, 2nd edition]
Special notes:
-- A char is either a signed char or an unsigned char, not a third and
different type. Usually, a char is signed, but on some platforms (the
MacIntosh for instance) the char is unsigned (by tradition). If you want
a signed char, say it explicitely.
-- What happens on overflow for signed types is undefined. Some
processors have the ability to test the overflow and produce an
exception if needed (the Intel x86 can do that ['into' opcode] and some
compilers use that to test the result of each operation). A portable code
should not depend on what happens on overflow.
-- For unsigned types, it is specified that on overflow, the result is
truncated modulo a power of two. This is exactly what we need for most
cryptographic applications.
Back to crypto now. If you want to implement an algorithm in really
portable C (which is somehow needed if you target embedded systems),
you should use unsigned integer types, and bitwise 'and' operations
to truncate each result, like that: (x + y) & 0xffffffffUL. Note the
'UL': according to the standards, '0xffffffff' (2^32-1) may not be
representable by anything else than an unsigned long. Good compilers are
smart enough to avoid this operation if it is not necessary (gcc, and
its msdos version djgpp, is smart enough; so is the Sun compiler for
Solaris, and the DEC C compiler on Alpha stations; other compilers I
have not checked).
You might also use bit fields. This is a feature of C rarely used, and
therefore not very optimized in many compilers. However, if you want
to be portable, that is pretty convenient. If you seek absolute speed,
you will produce a more hardware-aware version.
The most often encountered problem of portability is related to
endianness: I mean, many programmers make some assumptions about the
layout of variables into memory, and then write four chars and read one
unsigned int, believing that they would get the first byte as least
significant byte of the unsigned int. This is a terrible mistake, as
this means that this code will not work on MacIntosh, Sun stations,
PalmPilot and other things. Moreover, this reduces readability of the
code. The above coders usually claim that they do this for speed, but
this is irrelevant: Intel x86 and m680x0 have opcodes to byteswap large
integers, and Alpha and PowerPC can read memory in both endianness, on a
per-opcode basis.
To sum up: if you want portable code, do not even try to guess how
integer variables are represented in memory, and what are their sizes.
A portable code can be fast and yet readable. If you require absolute
speed (I mean, something like twice faster than portable code), then you
may produce a second version, that makes any hack you want, but this
version will never be a good sample code. And even then, the endianness
inherent to the algorithm is irrelevant (I insist on this because
some of the AES candidates use the little endian representation since
"it will be faster on the PC"; but this implies some sort of mental
gymnastic that gives me headaches -- I really prefer big endian, as far
as human reading is concerned).
--Thomas Pornin
(please mail me a copy of any answer -- I will be offline for a few weeks)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: SCOTT19U CONTEST UPDATE
Date: Sun, 01 Aug 1999 14:03:22 GMT
For those who lack the ablility to solve hard problems the Gloat
contest is down to 40 bits even Dave or Little Tommy boy ought
to be able to handle it by know by just doing a boring search.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
