Cryptography-Digest Digest #961, Volume #9 Sat, 31 Jul 99 20:13:07 EDT
Contents:
Re: Americans abroad/Encryption rules? (JPeschel)
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: Between Silk and Cyanide (Xcott Craver)
Re: What the hell is XOR? (Xcott Craver)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(wtshaw)
Re: Looking for RC4 alternative ([EMAIL PROTECTED])
Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide] (Jim Gillogly)
Re: How Big is a Byte? (was: New Encryption Product!) ("Trevor L. Jackson; III")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(John Savard)
Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide] (John
Savard)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
([EMAIL PROTECTED])
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Americans abroad/Encryption rules?
Date: 31 Jul 1999 21:57:42 GMT
>Lincoln Yeoh writes, in part:
>How about a foreigner with PGP visiting USA and then trying to erm leave?
>
>Land of the free. Maybe. Maybe not. Maybe "it's the veil pulled over your
>eyes..." ;).
>
>Cheerio,
Nope, the rule applies to citizens of the "land of the free."
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sat, 31 Jul 1999 16:40:42 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Roger) wrote:
> 1010 0101
>
> NEW !!! URL:
>
> http://members.xoom.com/enigma67/pages/index.htm
>
>
> VISIT "THE REVELATION"
>
> HIGHLIGHTS:
>
> ANCIENT EGYPTIAN LIGHT BULB
>
> LUCIFERIC SYMBOLS IN GOVERNMENT CENTER WASHINGTON D.C. , AVEBURY,
> ENGLAND
> AND CYDONIA MARS
>
> THE PLANETARY GRID AND CROP CIRCLES
>
> THE NEW WORLD ORDER
>
> Visit "The Revelation"
>
You've got to be kidding.
--
It is fine and dandy to choose to serve the government. It is fine
and dandy to obtain government services. It is still another thing
to find some in the crypto field have been serviced by government,
with contemplations of how they might do it better in the future.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Between Silk and Cyanide
Date: 31 Jul 1999 22:21:44 GMT
In article <7ngbf5$hf4$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
> You might be interested to know that Marks' antagonist in Holland,
>Herr Giskes, wrote a book after the war about his role in the British
>failure in that country. It was reprinted by Bantam Books in 1982
>under the title, London Calling North Pole.
Thanks! I'm totally going to nab it when I return to school.
As for Silk and Cyanide, I was unprepared for the one one-liner
per line writing style, but I definitely consider it a must-read.
It also helps to illustrate the difference in mindset and
knowledge as little as 55 years ago. Marks banged his brain
trying to find a letter equivalent of a one-time pad, and
says he got some respect for independently discovering it.
Today, it doesn't seem like that much of a discovery, just
doing addition in a different congruence class.
Hey, which reminds me: has anyone else (in particular, anyone
who read the book) hit upon using a Huffman table for a pencil-
and-paper code, in order to disguise a OTP or substitution
cipher as a transposition one? This would be a neat thing to
put in a kid's book on codes and ciphers, a table which lets
you convert to bits, operate on the bits, and convert back
to roman letters with roughly the same message size as the
plaintext and with letter frequencies of natural language.
From what I remembered of childhood, aabab SUCKED because of
the 5-fold symbol rate increase. A Huffman table would have
been almost magical, both for the compression and for the
prefix-free properties. It would also be better for semagrams.
-Scott
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: What the hell is XOR?
Date: 31 Jul 1999 21:57:10 GMT
Spud <[EMAIL PROTECTED]> wrote:
>I was reading "Applied Cryptography" by Bruce Schneier and I really don't
>get the XOR function. Help, please! Thanks.
>
>PS -- I'm not a computer newbie so you don't have to dilute any
>explainations with "easy words".
If you're not a computer newbie, then you might prefer a C
program. The XOR symbol in C is '^'. You'll also see other
bitwise operations below: '&' is bitwise AND, and << shifts
a number's binary digits one digit to the left, effectively
multiplying it by two (much like shifing a decimal number
one digit to the left multiplies it by 10.) >> shifts right.
That stuff isn't important, just used to convert the numbers
and such, but it is there for you to pick apart if you want.
#include <stdio.h>
void main(void)
{
unsigned char f, s, r,
first[9], second[9], result[9];
int i,j;
printf("Enter two 8-bit binary numbers:\n\n");
scanf( "%8s %8s", first, second );
for(f=s=0, i=0; i<8; i++) { /* convert string to # */
f = (f<<1) + (first[i] - '0');
s = (s<<1) + (second[i] - '0');
}
r = f^s; /* r == XOR of first and second input */
for( i=0,j=128; i<8; i++,j<<=1) /* convert # to string */
result[i] = '0' + (r&j)/j;
printf("\n\n %s\n^%s\n---------\n %s\n\n", first, second, result );
}
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sat, 31 Jul 1999 16:38:34 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Robert Stonehouse) wrote:
>
> The word 'byte' is an artificial word, introduced by IBM in 1964
> specifically to denote the 8-bit character used in System/360. IBM's
> definition is the definitive one.
Well, at least it describes an *8*-bit byte. A definitive term is one
that is by definition, definitive; so, be sure to specify your terms
whenver they might not be understood. The same applies alternately to the
term *word*; be specific as opposed to being presumptive.
IBM? Who are they(anymore)?
--
It is fine and dandy to choose to serve the government. It is fine
and dandy to obtain government services. It is still another thing
to find some in the crypto field have been serviced by government,
with contemplations of how they might do it better in the future.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Looking for RC4 alternative
Date: 31 Jul 1999 22:12:09 GMT
In article <7nvmuv$e6f$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> In article <7nt2ss$fc5$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> > In the line:
> > t = (S[i] + S[j]) mod 256
> > the 'a+b' operation could be replaced by 'a-b', 'b-a' or
> > 'a XOR b' with presumably the same result.
>
> I'm not sure this is a good idea. All of your proposed alternatives
> have the property that t=0 when i=j; this is not true of the original
> RC4, and might make some attack slightly easier (I don't know). More
> analysis would seem to be prudent before making this change.
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.
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).
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide]
Date: Sat, 31 Jul 1999 16:11:53 -0700
Xcott Craver wrote:
> Hey, which reminds me: has anyone else (in particular, anyone
> who read the book) hit upon using a Huffman table for a pencil-
> and-paper code, in order to disguise a OTP or substitution
> cipher as a transposition one? This would be a neat thing to
> put in a kid's book on codes and ciphers, a table which lets
> you convert to bits, operate on the bits, and convert back
> to roman letters with roughly the same message size as the
> plaintext and with letter frequencies of natural language.
In 1964 a member of the American Cryptogram Association suggested
the "Compactocrat": the idea was to take ordinary English and
condense it so that it would just barely convey enough information
to the recipient. He referred to Shannon and discussed the idea in
terms of reducing redundancy. In principle this would be dangerous,
since the code clerk on the far side might not be as smart as the
clerk on the near side.
In 1983 another member, Larry Loen, proposed the "Compressocrat", which
does what you're suggesting: he started with a ternary encryption of
the alphabet, with ETAON getting two trits each, IRSHD getting three,
PFCUMWY getting four, BGVKQ getting five, and XJZ getting six, using a
fixed alphabet. They were then re-encrypted into 26 letters with a
keyed alphabet. This worked well for compressing English and squeezing
out redundancy, and was tried for a few times before getting dropped
through lack of problem submissions from the members. It made an
interesting and unusual solving challenge -- unlike most classical-
flavored ciphers, it was far easier to solve from front to back than
vice versa, so you needed to get some early insight.
--
Jim Gillogly
Trewesday, 8 Wedmath S.R. 1999, 22:51
12.19.6.7.6, 11 Cimi 14 Xul, Second Lord of Night
------------------------------
Date: Sun, 01 Aug 1999 19:25:52 -0400
From: "Trevor L. Jackson; III" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >On 30 Jul 1999, Patrick Juola wrote:
> >
> >> In article <[EMAIL PROTECTED]>,
> >> <[EMAIL PROTECTED]> wrote:
> >> >On Thu, 29 Jul 1999, John Savard wrote:
> >> >> Zero may be my first counter state, but it is not the number
> >> >> associated with the first item or event. As there are times when
> >> >> reserving a storage location for element zero of an array makes sense,
> >> >> and other times when it does not, because of the purpose to which the
> >> >> array will be put, flexibility is useful...but, on the other hand,
> >> >> having to specify this every time is wasteful too. Starting with
> >> >> element zero at least allows both option with, at worst, a slight
> >> >> waste of storage, which is probably worth it to make one's program
> >> >> easy to understand and document, and avoid unnecessary offset
> >> >> arithmetic.
> >> >
> >> >The problem with this is that array[0] is the first item.
> >>
> >> Only in C and its descendants; in Fortran, if I recall properly, array(1)
> >> is the first item. In Pascal, I can define an array to start and finish
> >> at any ordinal position -- and if I'm using a Real Language(tm) I can
> >> define arrays based on any durn-fool index scheme I want. (I just
> >> *love* the associative arrays available in /bin/awk.)
> >
> >I'm sorry. I thought we were discussing off by one errors and the
> >differences between counting and addressing, not your bias against C. Yes,
> >I was assuming C but the C usage comes from the natural methods of most
> >assembly languages and is very logical when you think about it.
>
> Interesting statement; I've been programing in C professionally since
> quite possibly before you touched your first computer -- and here I'm
> accused, irrelevantly, of an anti-C bias.
>
> My feelings about C are beside the point; I'm simply stating that the
> array semantics in C are a matter purely of *convention* and aren't any
> more natural or intuitive -- and in fact, to a traditionally trained
> mathematician are *less* natural/intuitive -- than one-based indexing
> or any other method you like. C arrays are just thinly disguised pointers,
> which again aren't particularly natural or intuitive; they just happened
> to be convenient for Thompsen and Richie. Whether I like C or not,
> I can certainly recognize that the zero-based indexing conflicts with
> standard mathematical practice and is difficult to present to students.
>
> You seem to be making the common mistake of believing that the
> structures in your first or preferred language are somehow less
> arbitrary than the structures in other languages. 'Tain't so,
> dude.
>
> >> >The reason this
> >> >is a problem is that in computer addressing the address refers to the next
> >> >item in memory (i.e. the item that starts at array[0]).
> >>
> >> No, the reason for this is that the semantics of C-style arrays are
> >> defined as syntactic sugar over a pointer access. Which is one of
> >> the most serious security/reliability holes in C/Unix.
> >
> >Yes, C arrays come very nearly directly from (or at least have a lot in
> >common with) assembly language. And arrays are pointers in C. However, I
> >really think you're exaggerating when you try to claim that C's array
> >syntax is a security or a reliability hole in either C or Unix.
>
> I stand by my statement. Two words : finger bug.
>
> > The
> >improper use of C array syntax can cause said holes but then most C
> >programmers have gotten used to the "it starts at 0" concept.
>
> Of course, one can get used to anything in time -- why should one
> have to work that hard to master arcana?
>
> > Would you
> >also say it's a major flaw with assembly language?
>
> Yes -- although assembly language itself has so many other major flaws
> that it's hard to know where to begin cataloguing them. The main one,
> of course, being that assembly language is so damn hard to write
> *because* it follows the conventions of the machine instead of conventions
> useful for thinking about the problem at hand.
>
> If I needed to make a graph of financial data covering the years 1950-1999,
> it would make much more sense in the context of that problem to
> be able to use an array indexed from 1950 to 1999, inclusive, with
> compiler support to prevent out-of-bounds accesses. Which C notably
> fails to provide.
While C does not provide bounds checking that lack is irrelevant to the issue of
the flexibility of arrary indexing. By a trivial initialization you can achieve
any array index range you wish. *Use* the language rather than fighting it. The
equivlance of pointers and arrays in C can be slippery, or it can be useful.
Given an array of suitable size (50 slots in your example), create a pointer with
the appropriate offset.
financial_data_t _table[ 50 /* literal used for illustration only */ ], *table =
table + 1950 /* same here*/;
With this construction you can utilize raw years to access the data. Note that
this problem exists in multiple forms when dealing with time. A language that
permitted accessing an array with CCYY and also with YY indexes would make many
these data structures easier to handle. Any OO language, and C++ in particular
supports this.
>
>
> >Should we all start
> >having our assembly language programs use pointers to arrays that start
> >one byte sooner that the array just so we can say the item 1 is at array:
> >+ 1?
>
> No, we should stop writing assembly language programming. No one does
> large projects in assembly any more for a very good reason. The
> compiler is usually a better assembly language programmer than you are
> and doesn't make careless mistakes in translation.
>
> >Now, if you want to discuss this rationally rather that show your bias
> >against C I'd be happy to.
>
> "If all you have is a hammer, the entire world looks like a nail."
> Again, I'm not especially biased against C -- but I've been using it
> enough to be well aware of its weaknesses, and array indexing is,
> sho 'nuff, one of the big ones.
>
> >PS Off by one errors occur in more languages than just C and kin.
>
> Yes. But typically many fewer of them.
At this point you sound like Pournelle. he stated in print (Byte Magazine) that
he was not biased against C, but that he'd investigated many buggy programs and
found that they were all written in C. He recommended BASIC.
> The pointer-based semantics of C arrays encourages lots of
> errors : off-by-one errors, overrun screws, smashing the stack,
> unexpected aliasing, and so forth. Most of the major security holes
> in Unix -- or at least the publicized ones -- are related in some
> fashion or another to the array semantics. Array semantics, esp.
> w.r.t. multidimensional arrays, are probably the hardest part of C
> to teach to a student and the easiest part to screw up (and often the
> hardest bugs to find and fix).
>
> The various bondage and domination languages -- Pascal, Ada, &c. --
> specifically implement arrays as *packaged* memory blocks, which
> allows greater flexibility (and hence greater intuitiveness) in
> calling as well as better ability to catch and trap errors.
Only if the packaging matches your personal biases and/or the problem domain.
Flexibility in this regard is to be prized over dogmatism. Definable sematics is
more often abused than used properly, but it does permit efficient, robust, and
maintainable implementations.
> This,
> in my view, doesn't make up for the *rest* of the officious SE crap
> one has to put up with in order to program in Ada, but if I had the
> ability to pick and choose features in designing my own ideal
> language, I would definitely use Ada- or Pascal-style array semantics
> in preference to C. And general associative arrays in preference
> to either if I had good compiler support.
>
> -kitten
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sat, 31 Jul 1999 23:58:32 GMT
Martin Ambuhl <[EMAIL PROTECTED]> wrote, in part:
>"Mr. Leo Yanki" wrote:
>> [EMAIL PROTECTED] (Guenther Brunthaler) wrote:
>> >... "byte" ... can have ANY number of bits
>> A byte has exactly eight bits and can have 256 different values. A general
>> term for any size collection of bits is "binary number". Please don't
>> attempt to confuse people by trying to spread your personal redefinitions
>> of commonly used technical terms.
>I'm afraid you are showing your lack of experience. The fact is that G.
>Brunthaler is correct. Your incorrect idea that "byte" means an octet
>is a redefinition IBM tried to force on the computer world with the
>introduction of the IBM 360. Isn't it nice to know that you are in
>intellectual thrall to IBM?
Actually, the word "byte" was invented by IBM, even if Dr. Knuth and
DEC later used that term to refer to small units of computer storage
other than the 8-bit byte.
Not just IBM, but now pretty well all microcomputer makers use the
term "byte" in this way, and data storage media are _sold_ by the
byte.
1.44 Mb formatted capacity floppy disks, anyone?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Pencil-and-paper compression algorithms [Re: Between Silk and Cyanide]
Date: Sun, 01 Aug 1999 00:00:42 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>Xcott Craver wrote:
>> Hey, which reminds me: has anyone else (in particular, anyone
>> who read the book) hit upon using a Huffman table for a pencil-
>> and-paper code, in order to disguise a OTP or substitution
>> cipher as a transposition one? This would be a neat thing to
>> put in a kid's book on codes and ciphers, a table which lets
>> you convert to bits, operate on the bits, and convert back
>> to roman letters with roughly the same message size as the
>> plaintext and with letter frequencies of natural language.
>In 1983 another member, Larry Loen, proposed the "Compressocrat", which
>does what you're suggesting: he started with a ternary encryption of
>the alphabet, with ETAON getting two trits each, IRSHD getting three,
>PFCUMWY getting four, BGVKQ getting five, and XJZ getting six, using a
>fixed alphabet. They were then re-encrypted into 26 letters with a
>keyed alphabet.
It may be noted that Ohaver's mutilation cipher - one which I've found
interesting - also has frequency-simulating behavior. (Gaines, and the
fractionation part of my web page. Likely documented on the ACA web
site, the Crypto Drop Box as well.)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [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 23:50:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Fri, 30 Jul 1999 12:14:44 -0400, [EMAIL PROTECTED] wrote:
>
> >Simply becuase a term is "commonly used" does not mean it has a
single
> >interpretation. Indeed, commonly used terms are often the most
easily
>
> True. But its good to cache commonly used terms as primary context.
>
> Now that we've defined byte to bits should we go on to definitions of
> Megabyte? ;).
>
Good point. A megabyte is 2^20 bytes so megabyte is not always 2^23
bits?
byte = octet = 8bits will keep you out of trouble for the most part and
remember to '%256' your code!
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: [EMAIL PROTECTED] (John Savard)
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Sun, 01 Aug 1999 00:06:46 GMT
[EMAIL PROTECTED] (Guenther Brunthaler) wrote, in part:
>Well, "byte" is simply short for "binary term" and nothing else.
I don't think that that is correct. Someone may have tried to retrofit
that false etymology on the term in print, though.
>It
>can have ANY number of bits, although on most machines it has 8 bits
>("binary digits").
It is true that the MIX machine can have a 6-bit or two-digit byte (an
imaginary machine used to illustrate algorithms in Knuth's Art of
Computer Programming series), and documentation on the 36-bit PDP-10
refers to its variable-size characters as byte.
>However, I know that on some older mainframes bytes also used to have
>just 6 bits.
But these machines, having been developed before the STRETCH came
along, called their 6-bit storage cells "characters", not bytes.
Otherwise, this is a fine post on a useful subject. But while there
are attested usages of the term "byte" for things other than an octet,
it is not at all clear that they are necessarily correct.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
