Cryptography-Digest Digest #864, Volume #9 Sun, 11 Jul 99 02:13:04 EDT
Contents:
Re: How Big is a Byte? (was: New Encryption Product!) (Jim Gillogly)
Re: Short Key and Short Data -- XOR ??? (Nicol So)
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day (William Tanksley)
Benfords law for factoring primes? ("Blank")
Re: Kryptos article (JTong1995)
Re: Short Key and Short Data -- XOR ??? (Randy Given)
Help with RNG Stats (Clinton Begin)
Re: Scramdisk: Security flaw in VxD? (Anime Rokly)
Re: How Big is a Byte? (David A Molnar)
Re: Can Anyone Help Me Crack A Simple Code? (John Wasser)
Re: How Big is a Byte? (was: New Encryption Product!) (David Eppstein)
Re: How Big is a Byte? (was: New Encryption Product!) (Dennis Ritchie)
Re: New Encryption Product! (humor) ("Kurt Mueller")
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sat, 10 Jul 1999 16:26:53 -0700
Sorry to quote John's whole message, but I couldn't see an easy trim,
since it all looks relevant. However, we've had this discussion
before, and Doug is correct. The PDP-10, for example, had 36-bit
words and its documentation and opcodes discussed 9-bit bytes. I
still have a manual at work and can quote from it as needed. ANSI's
C spec says a byte is "the unit of data storage large enough to hold
the basic character set of the execution environment" (sec. 3.4).
K&R (pre-ANSI) says "The size is given in unspecified units called
'bytes', which are the same size as a char." K&R defines "char" as
"a single byte, capable of holding one character in the local character
set." As Doug says, this is precisely why the term "octet" is used
ubiquitously in IETF for 8-bit objects. Since John brought up 360s,
I did a Web search and turned up an interesting historical article
on 360 design at http://www.fee.co.uk/ibm360.htm :
Even the size of a Byte of data had to be agreed. We all now
understand that a Byte is 8 bits + 1 parity but at the start
of this project there were financial pressures to reduce the
size of a Byte down to 6 or even 4 bits so reducing the number
of circuits used in the computer.
Of course, nobody disagrees that bytes are usually 8 bits on modern
machines, most of which (for our sins) are Intel boxes running a
Microsoft OS.
[EMAIL PROTECTED] wrote:
>
> Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> : It would have been funnier if it were right. A byte need not have
> : exactly 8 bits, although that is such a common misconception that
> : it is used in labeling disk drives, etc. That's why in technical
> : work, such as Internet packet specifications, we prefer the term
> : "octet" when we mean precisely 8 bits.
>
> That reminds me of a letter to Byte magazine, wherein a reader protested
> that the use of the term "byte" to describe a storage unit containing 8
> bits was _incorrect_, because the "official" definition of a byte was
> something that could take between 64 and 100 values.
>
> Of course, that fellow had been reading the definition of "byte" found in
> Donald E. Knuth's description of the MIX computer, not realizing that it
> was not intended as a general definition of the term.
>
> However, AFAIK, that is the *only* place the term byte has ever been used
> to describe anything other than an (ahem) octet, and it is arguably
> incorrect (the proper term would be "character", which indeed could be 6
> bits, 8 bits, 16 bits, two digits, or whatever on different computers) as
> the term byte was coined and defined, with a definition that made no
> provision for the term referring to any other quantity of storage...
>
> in "System/360 Principles of Operation".
>
> However, I have heard that the term "byte" may have been used earlier than
> this - again to designate 8 bits of storage - in the manuals for the
> STRETCH computer.
>
> Thus, I'm not sure that the common definition of a byte, as 8 bits the way
> a foot is 12 inches, is necessarily wrong. But I do have to admit that
> some authorities could argue it the other way: since "byte" belonged to a
> family of terms including "halfword" and "word", and since not all
> computers have a word length of 32 bits, by implication a byte is also a
> flexible unit.
>
> John Savard
--
Jim Gillogly
Trewesday, 17 Afterlithe S.R. 1999, 22:56
12.19.6.6.5, 3 Chicchan 13 Tzec, Eighth Lord of Night
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Short Key and Short Data -- XOR ???
Date: Sat, 10 Jul 1999 19:39:03 -0400
Randy Given wrote:
>
> I have a short set of data (4 to 6 bytes) that I need
> to encrypt symmetrically using a short key (2 to 8 bytes).
> Is there anything better than XOR for this small of a
> data set?
I'm not sure if I understand what you meant by "symmetrically". I can
think of several reasonable interpretations. For every one of them,
there is definitely something better than just XOR'ing with the key.
You didn't say what your application is. If personal safety or large
sums of money is at stake, you should get expert help. If you're doing
it mostly for fun, there are several obvious things you can try to
improve on the simple XOR solution.
1. Use a good pseudorandom number generator to expand the key into more
key bits. (By the way, the keys in your application are really quite
short. You can't expect much security from them, especially the shorter
ones. I hope your application doesn't require a high level of
security.)
2. Use a more complicated function than XOR to combine the (expanded)
key bits with the plaintext.
3. Have multiple rounds of processing (for diffusion, if not for other
reasons).
Have fun.
Nicol
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
Reply-To: [EMAIL PROTECTED]
Date: Fri, 09 Jul 1999 21:29:30 GMT
On Thu, 8 Jul 1999 19:09:03 +0100, Toby Kelsey wrote:
>In article <7lst5f$cts$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
>>In theory the OTP is truly the only secure method.
>Really?
No, not really. OTP is the only "perfectly secure" algorithm. Perfect
security has a formal definition which happens to coincide with its common
meaning, but many other algorithms are "secure".
>I intercept your OTP encoded message, for which I know the plaintext to
>be either "Yes" or "No". The ciphertext is 2 characters long......
You've found a good break for a (silly) system. The correct system would
have either specified a padding or used compression to reduce those
messages to one bit.
>So much for "theoretically unbreakable".
It is. You didn't break the OTP.
>The OTP allows any same-length decrypted message to be equally likely,
>but requires a key the same length as the message. You can devise
>methods which have shorter keys and still allow many possible decrypted
>messages. The OTP is only "simpler" and "more secure" because the
>algorithmic complexity is hidden in the RNG and its testing. There is
>less latitude for error in the encryption implementation, but more
>reliance is placed on the quality of the RNG and the secure channel.
*Simple*? It's not simple, except perhaps in the sense that you don't
have to do a complicated translation to make plaintext into cyphertext.
But there's nothing hidden in the RNG. It's any arbitrary RNG you want.
>The bottom line is, I would not feel safer just knowing a OTP was being
>used to encrypt my messages.
Just knowing? I would be downright suspicious. If that's all they told
me.
>Toby
--
-William "Billy" Tanksley
------------------------------
From: "Blank" <[EMAIL PROTECTED]>
Subject: Benfords law for factoring primes?
Date: Sun, 11 Jul 1999 00:11:14 GMT
Has anyone looked into using Benfords ( prob first digit D = log 1+1/D ) law
to sort the lists of potential factors for brute force prime cracking? Do
observable primes obey Benfords law. Its late here and my quickly hacked
little VB pgm seems to say no.
I
------------------------------
From: [EMAIL PROTECTED] (JTong1995)
Subject: Re: Kryptos article
Date: 11 Jul 1999 01:04:15 GMT
>By the way, has part 3 turned out to be just a double transposition?
>There was some indication of that in some of the postings I saw.
I thought that all transpositions acted as a group, in that a double (or
triple) transposition could be represented as a single transposition of a
different pattern.
Jeffrey Tong [EMAIL PROTECTED]<Jeffrey Tong>
PGP 5 Key available for download at WWW.PGP.COM Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1
------------------------------
From: [EMAIL PROTECTED] (Randy Given)
Subject: Re: Short Key and Short Data -- XOR ???
Date: 11 Jul 1999 02:05:08 GMT
>1. Use a good pseudorandom number generator to expand the key into more
>key bits. (By the way, the keys in your application are really quite
>short. You can't expect much security from them, especially the shorter
>ones. I hope your application doesn't require a high level of
>security.)
It doesn't. There are many things I know which have strong
security with much longer keys. This limitation is trying to
get the best bang-for-the-buck with a minimal set. No doubt
that the "security" is laughable.
Thanks for your suggestions!
Randy Given
[EMAIL PROTECTED]
http://members.aol.com/GivenRandy
public key at http://members.aol.com/GivenRandy/pgpkey.asc
------------------------------
From: Clinton Begin <[EMAIL PROTECTED]>
Subject: Help with RNG Stats
Date: Sun, 11 Jul 1999 02:18:27 GMT
Hi all,
I need the opinion of a math genius or two. Below are the DIEHARD
results for my random number generator. I would like to use this RNG
in a cryptography application. Is there anyone out there able to give
me a general reaction (opinion) to the results below?
I ran the test 8 times (1 to 8 below). The 8 (9MB) files I used for
the tests were generated one after the other after seeding the RNG
once. In my actual application I am planning on reseeding the RNG
often, using a combination of output feedback and random input from the
user (mouse, keyboard latency etc.). I will rerun the tests once I get
all that working.
Diehard Summary Results
# of # of
KSTEST of P-Values P-Values
Final < 0.01 > 0.99
P-Values (of 234) (of 234)
1 - 0.943501 0 4
2 - 0.994839 5 4
3 - 0.462992 2 2
4 - 0.681078 0 3
5 - 0.350489 1 3
6 - 0.302510 2 3
7 - 0.950813 2 3
8 - 0.763183 2 6
There were no 1s or 0s in the any p-values for any of the tests. A few
were pretty close though (see #2 above).
Thanks for any help.
Clinton
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Anime Rokly)
Crossposted-To: alt.security.pgp,comp.security.misc
Subject: Re: Scramdisk: Security flaw in VxD?
Date: Sun, 11 Jul 1999 01:28:19 GMT
[EMAIL PROTECTED] (Shaun Hollingworth) wrote:
>Nope. I said:
>"sniff!"
That message was two months old!
--
"Anime Rokly" better known as [EMAIL PROTECTED]
01234 56789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte?
Date: 11 Jul 1999 02:01:43 GMT
In sci.crypt Jim Gillogly <[EMAIL PROTECTED]> wrote:
> 'bytes', which are the same size as a char." K&R defines "char" as
> "a single byte, capable of holding one character in the local character
> set." As Doug says, this is precisely why the term "octet" is used
> ubiquitously in IETF for 8-bit objects. Since John brought up 360s,
[snip of useful article cite and quote]
> Of course, nobody disagrees that bytes are usually 8 bits on modern
> machines, most of which (for our sins) are Intel boxes running a
> Microsoft OS.
So when Microsoft adopts Unicode as the "local character set",
does this mean all bytes become 16 bits in length?
-David
------------------------------
From: John Wasser <[EMAIL PROTECTED]>
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Sat, 10 Jul 1999 22:01:08 -0400
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <[EMAIL PROTECTED]>, mercury
<[EMAIL PROTECTED]> wrote:
> I have a "black box" which accepts ten digit codes. The black box
> understands these codes as meaning a color and a date. The black box
> these codes are for has a price tag of almost $100,000.00.
How much do you have to pay for each code?
Why have you bought six different codes for the same machine and the
same time period when you say that "they are treated identically"?
If they are treaded identically, why don't you enter the same code
six times?
My guess is that you have a piece of medical equipment like a
VISX eximer laser where the maker charges a fee ($250) for each
procedure. I suspect that each code is only good for a fixed
number of procedures.
------------------------------
From: [EMAIL PROTECTED] (David Eppstein)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 10 Jul 1999 20:12:24 -0700
Jim Gillogly <[EMAIL PROTECTED]> writes:
> Sorry to quote John's whole message, but I couldn't see an easy trim,
> since it all looks relevant. However, we've had this discussion
> before, and Doug is correct. The PDP-10, for example, had 36-bit
> words and its documentation and opcodes discussed 9-bit bytes.
It was even more complicated than that...the PDP-10 architecture
machines could address contiguous blocks of any number of bits within a
36-bit word, using what were called "byte pointers". On the systems I
used the most common length of a byte was 7 bits, stored 5 to a word.
Originally, only 2^18 words were addressable, so there were plenty of
bits left in a byte pointer for the byte size and offset. But at some
point, DEC extended the architecture to allow for a larger memory size.
In order to use byte pointers with extended memory, you needed either
two-word byte pointers or a special "one-word global byte pointer"
format that only allowed certain byte sizes and offsets.
I remember having lots of fun making all the pointer arithmetic work in
a C compiler I was working on at the time...I don't remember whether
it used 8 or 9 bit bytes, probably 9.
Anyway, this pretty conclusively demolishes the original poster's
contention that Knuth is the only source to refer to something other
than an octet as a "byte".
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sun, 11 Jul 1999 04:33:54 +0100
Reply-To: [EMAIL PROTECTED]
David Eppstein wrote (after quoting and referencing):
>
> Anyway, this pretty conclusively demolishes the original poster's
> contention that Knuth is the only source to refer to something other
> than an octet as a "byte".
The earliest reference to the term I have in hand is "Planning a
Computer System", ed. Werner Buchholz, McGraw-Hill, 1962.
It is about the IBM Stretch project, which culminated in the
IBM 7030 machine. The first reference in the book to the word
is in a chapter parts of which were taken from a paper
by Blaaw, Brooks, Buchholz in IRE Transactions on Electronic
Computers, v. EC-8#2, June 1959. The chapter is entitled
"Natural Data Units", but the word "byte" first occurs on p. 39
in a table just after the sections adapted from the 1959 paper;
it is then explained:
"Byte" denotes a group of bits used to encode a character, or
the number of bits transmitted in parallel to and from input-
output units. A term other than 'character' is used here
because a given character may be represented in different
applications by more than one code, and different codes
may use different numbers of bits (i.e. different byte sizes.)
.... (The term is coined from 'bite', but respelled to avoid
accidental mutation to 'bit.')"
Later, on p. 65, the authors (here Bemer and Buchholz) explain
that the 8-bit byte was chosen for the Stretch for a list
of five reasons which I won't retype, but are summarized
by the first: "its full capacity of 256 characters was considered
to be sufficient for the great majority of applications."
They also liked the power-of-two length, and the fact that
two BCD digits would fit conveniently within.
Dennis
------------------------------
From: "Kurt Mueller" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: New Encryption Product! (humor)
Date: Sun, 11 Jul 1999 00:22:34 -0400
Yes, I knew that a byte isn't always
8 bits, but I was playing off the common
misconception and commonly accepted
definition.
--
_____________________
Kurt Mueller
[EMAIL PROTECTED]
PGP encrypted mail highly preferred! DH preferred! Get my keys at:
http://www.bigfoot.com/~wwww
Signed. Sealed. Delivered.
Douglas A. Gwyn wrote in message <[EMAIL PROTECTED]>...
>Kurt Mueller wrote:
>> Philip Koopman wrote in message <[EMAIL PROTECTED]>...
>> >Not to mention, you wouldn't have enough bits -- it is well known that
>> >there are only 8 bits of data in a byte ;-)
>> I had to read that twice to get it, then I laughed.
>
>It would have been funnier if it were right. A byte need not have
>exactly 8 bits, although that is such a common misconception that
>it is used in labeling disk drives, etc. That's why in technical
>work, such as Internet packet specifications, we prefer the term
>"octet" when we mean precisely 8 bits.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 11 Jul 1999 05:00:36 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
** 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
******************************
