Cryptography-Digest Digest #496, Volume #12 Mon, 21 Aug 00 12:13:01 EDT
Contents:
Re: blowfish problem (Richard Bos)
Re: Bytes, octets, chars, and characters (Richard Bos)
Re: Bytes, octets, chars, and characters (Dan Pop)
Re: Bytes, octets, chars, and characters (Dan Pop)
Does this app work? ("CiPHER")
Re: Lehmann Primality Test (David A Molnar)
Re: CRC? (Mark Wooding)
Re: Hidden Markov Models on web site! ("Douglas A. Gwyn")
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: blowfish problem ("Douglas A. Gwyn")
Re: blowfish problem ("Douglas A. Gwyn")
Re: Bytes, octets, chars, and characters (Paul Schlyter)
Re: Bytes, octets, chars, and characters (John Winters)
Re: blowfish problem ("Douglas A. Gwyn")
Re: blowfish problem ("Douglas A. Gwyn")
Re: 1-time pad is not secure... ("Douglas A. Gwyn")
Re: Bytes, octets, chars, and characters (Richard Herring)
Re: Simple cipher based on SHA-1 ([EMAIL PROTECTED])
Re: Lehmann Primality Test ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Richard Bos)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Mon, 21 Aug 2000 14:07:36 GMT
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Richard Bos wrote:
>
> > "Michael Will" <[EMAIL PROTECTED]> wrote:
> >
> > > After all these years I see there's always something new to learn.
> > > I should go check my K&R to see if I should have known this from the
> > > very start. (Yes, the original. The one we had to carry to school
> > > uphill in the snow both ways, etc.)
> >
> > No, you shouldn't. It's quite possible that the word byte is used
> > differently in K&R. However, that doesn't matter in the least, because
> > since 1989, the C language has been defined by the ISO standard, not by
> > K&R.
>
> No. There isn't one C language.
>
> There is ISO 1989 C and there is K&R C. I have and use compilers of both
> flavors. This millennium even.
Of course you have; last millennium there wasn't even any electricity to
run your computer on.
Even so, if you refer to the C language on comp.lang.c, we'll assume you
refer to ISO C (currently, C89 or C99 depending on context). If you want
K&R C, you need to specify that.
Richard
------------------------------
From: [EMAIL PROTECTED] (Richard Bos)
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Mon, 21 Aug 2000 14:07:35 GMT
[EMAIL PROTECTED] (John Savard) wrote:
> On Fri, 18 Aug 2000 03:59:04 +0100, David Hopwood
> <[EMAIL PROTECTED]> wrote, in part:
>
> >The use of
> >the word "character" to mean anything other than a unit of text (such as
> >a symbol, letter, etc., or possibly a control code), should be strenuously
> >resisted; characters are *not* units of storage.
>
> This is true _now_, with such things as UTF-8.
>
> However, in the past, it had been customary to refer to a six-bit area
> in a computer's memory, where such an area was the span of memory
> occupied by a character of a text, as a character.
>
> The term byte did not come into general use until computers stored
> characters in 8-bit areas.
This is completely wrong. You would do well to read, say, the Jargon
File.
Richard
------------------------------
From: [EMAIL PROTECTED] (Dan Pop)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 21 Aug 2000 14:13:58 GMT
In <[EMAIL PROTECTED]> "Clark S. Cox III"
<[EMAIL PROTECTED]> writes:
> I was under the impression that a word was 16-bits on a 16-bit
>machine, 32 on a 32-bit machine, etc.
In an ideal world, this is how it should be. However, some companies
chose to preserve their terminology when they upgraded their hardware,
so a word remained a 16-bit entity on the VAX and 386.
>And that in C/C++, 'int' usually corresponded to a word.
On most current implementations, an int corresponds to a 32-bit entity,
regardless of the word size. On the newer 64-bit processors, int is still
32-bit and long is (usually) 64-bit.
Dan
--
Dan Pop
CERN, IT Division
Email: [EMAIL PROTECTED]
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
------------------------------
From: [EMAIL PROTECTED] (Dan Pop)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 21 Aug 2000 14:20:56 GMT
In <8nqjkq$fq5$[EMAIL PROTECTED]> [EMAIL PROTECTED] (John Winters) writes:
>Definitely not - a word is the natural size of number for manipulation
>of the machine - sometimes a little hard to pin down. The misconception
>that a word is two bytes comes from the every-computer-is-a-PC-running-DOS
>brigade.
It's even older than that. It was first introduced by the PDP-11.
The VAX, a 32-bit machine that predates the PC, had 16-bit words
"inherited" from its predecessor, the PDP-11.
Dan
--
Dan Pop
CERN, IT Division
Email: [EMAIL PROTECTED]
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
------------------------------
From: "CiPHER" <cgoth[hatespam]@hotmail.com>
Subject: Does this app work?
Date: Mon, 21 Aug 2000 15:59:49 +0100
Reply-To: "CiPHER" <cgoth[hatespam]@hotmail.com>
Just wondering, does this Apocalypso program (
http://newdata.box.sk/2000/apocalypso.zip ) actually do 'what it says on
the tin'?
I have tried it, and it certainly encrypts the contents, I'm just uncertain
as to whether the algorithms specified are true or not.
---
Marcus
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Lehmann Primality Test
Date: 21 Aug 2000 14:40:16 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
> ChenNelson <[EMAIL PROTECTED]> wrote:
>> I know the theoretical *upper* limit is 1/2, but a few trial runs on
>> my computer seem to indicate an average value much lower than this.
> I was recently at a talk which mentioned that Landrock, Damga^*rd, and
> Pomerance had investigated the average case for Rabin-Miller. Perhaps
> that kind of analysis would shed light on the Lucas-Lehmann case.
> or perhaps the bibliography for the paper would have pointers.
> Unfortunately I don't know the exact reference.
> -David
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: CRC?
Date: 21 Aug 2000 15:17:44 GMT
Mack <[EMAIL PROTECTED]> wrote:
> For full 160bit SHA-1 will beat out a 64 bit CRC for correction rate
> but lose badly on speed. When only using 64 bits of SHA-1 it will
> lose badly on both. It isn't designed for it. It is easy to find
> strings that match for a CRC but none will differ in certain ways that
> are representative of communication errors. ie. burst errors.
The above sounds confused to me.
Note that, if the probability of the SHA hashes of two messages having t
bits the same is other than 2^t then this is a cryptographic weakness in
SHA which should be investigated. Many applications are expecting SHA
to behave like a random function; the above would be a failure to do
this.
CRCs, depending on the polynomial, can detect certain classes of common
communication errors with probability 1. A secure hash like SHA has no
such classes of `special' errors: it works exactly as well on any sort
of input. (Again, if this weren't the case, we'd have a failure to
behave like a random function.)
Note that, in my experience, MD4 can be faster than a 32-bit CRC.
MD4 is a failed attempt at a cryptographic hash function -- it's
possible to construct malicious inputs which give the same hash value.
I think it'll work very well as a simple checksum.
A while ago, I posted a cycle-count comparison between ARM
implementations of MD4 and a table-driven CRC. MD4 wins on cycles per
byte on large chunks of data, although CRC will be a win if your
messages are short.
-- [mdw]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hidden Markov Models on web site!
Date: Mon, 21 Aug 2000 14:22:20 GMT
John Savard wrote:
> ... I did not understand such matters as Baum-Welch estimation
> well enough to attempt to describe them, ...
Basically, all that matters (unless you have to implement it)
is that it runs forward and backward through the observed
output using the actual transitions to successively refine an
initial estimate of the HMM parameters, and the algorithm has
been proved to be stable and convergent. The result is a set
of parameters for the HMM for which the observed output is at
least as likely as for any other set of parameters. That's
an example of Maximum Likelihood Estimation, which is widely
used in data analysis. Maximum-Likelihood methods generally
fit the observed data *too* tightly, but it's a reasonable
criterion that is mathematically tractable, and in practice it
often produces good results.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Bytes, octets, chars, and characters
Date: Mon, 21 Aug 2000 14:25:50 GMT
fvw wrote:
> Ok, I'm confused now. I though a word was always 2 bytes on whatever
> architecture you happen to be living?
Not even close. A "word" originally was the collection of bits
accessed from memory all at the same time, typically 12 to 64 bits.
It has no necessary relationship to "byte" other than when bytes
are supported, they tend not to span multiple words.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Mon, 21 Aug 2000 14:30:04 GMT
"Trevor L. Jackson, III" wrote:
> Check how many currently shipping compilers have a K&R switch.
That's provided solely as a convenience, to compile ancient code
with less likelihood of problems than if standard-conforming C
has been assumed. "K&R" does not denote a sufficiently tightly
specified language to use it as a standard, which is why there
was a C standards group formed in the first place. In fact, not
even the PDP-11 UNIX C compiler written by Ritchie and Reiser
fully conformed to the specs in "K&R" 1st edition, nor did PCC
which was the main basis for porting C to other platforms for
several years.
For developing *new* C code, you are better off following the C
standard.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Mon, 21 Aug 2000 14:33:48 GMT
"Trevor L. Jackson, III" wrote:
> Sure it can. The C programs that were written with C compilers on machines
> with CHAR_BIT < 8 are still C programs. They just aren't C99 programs.
They might be programs that do not strictly conform to the C standard
(any version), but it sounds like the actual situation is that the
*implementation* does not conform to the C standard (any version).
In many contexts, it is misleading or worse to call that a "C"
implementation, especially when conformance to applicable standards
is a product requirement (as it often is in contracts).
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 21 Aug 2000 16:29:44 +0200
In article <[EMAIL PROTECTED]>,
Clark S. Cox III <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>> <8nq0uk$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>>> playte, chawmp (on a 32-bit machine), word (on a 16-bit machine),
>>> half-word (on a 32-bit machine).
>>
>> Ok, I'm confused now. I though a word was always 2 bytes on whatever
>> architecture you happen to be living?
>
> I was under the impression that a word was 16-bits on a 16-bit
> machine, 32 on a 32-bit machine, etc.
Yep -- a word is X bits on an X-bit machine, that's the rule.
But in the Wintel world, thus rule seems to have been replaced by
the "rule" that "a word is 16 bits" -- even on 32-bit Wintel computers!!
> And that in C/C++, 'int' usually corresponded to a word.
Only if the word is at least 16 bits. Standard C resuires that a
short must be at least 16 bits, and an inte must be at least as large
as a short. Thus, on 8-bit microcomputers, where the very first
microcomputer C compilers appeared in the early 1980'ies, an int was
16-bit even though the word size of the computer was 8 bits.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (John Winters)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 21 Aug 2000 16:29:22 +0100
In article <8nrds8$jsv$[EMAIL PROTECTED]>, Dan Pop <[EMAIL PROTECTED]> wrote:
>In <8nqjkq$fq5$[EMAIL PROTECTED]> [EMAIL PROTECTED] (John Winters) writes:
>
>>Definitely not - a word is the natural size of number for manipulation
>>of the machine - sometimes a little hard to pin down. The misconception
>>that a word is two bytes comes from the every-computer-is-a-PC-running-DOS
>>brigade.
>
>It's even older than that. It was first introduced by the PDP-11.
>The VAX, a 32-bit machine that predates the PC, had 16-bit words
>"inherited" from its predecessor, the PDP-11.
Ah, I know 16 bit words are older than that - it was the misconception
that I was talking about.
John
--
John Winters. Wallingford, Oxon, England.
The Linux Emporium - the source for Linux CDs in the UK
See http://www.linuxemporium.co.uk/
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Mon, 21 Aug 2000 14:40:53 GMT
"Trevor L. Jackson, III" wrote:
> Is it your position that programs written in compliance with C89 are
> not C?
With exceedingly rare exception, if a program strictly conforms
to the 1989 C standard it also conform sto the 1999 C standard.
------------------------------
Crossposted-To: comp.lang.c
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: blowfish problem
Date: Mon, 21 Aug 2000 14:39:15 GMT
"Trevor L. Jackson, III" wrote:
> > > out =3D malloc((inLen * 2 + 1) * sizeof(char));
> > > /* a char could be more than 1 byte */
> > No, a char is always one byte in C.
> No it's not.
I am unaware of *any* C implementation for which sizeof(char)
is other than 1. Within the context of defining what C is,
a "byte" is the unit of addressability (as you said) of at
least 8 bits, and type "char" is required to occupy precisely
one byte. (I proposed otherwise during development of the
initial C standard, but Dennis Ritchie said that that was
always his intent, so it became harder to get support for any
proposal to the contrary.) Certainly, all versions of the C
standard have always required sizeof(char)==1.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Mon, 21 Aug 2000 14:51:45 GMT
Tim Tyler wrote:
> It amuses me to think that some people feel they can completely dismiss
> the idea that the universe is deterministic on the basis of our current
> knowledge of physics.
Excuse me, but (1) you have confused (non)determinism with fundamental
randomness; and (2) as a "disciple" of Einstein (my Master's thesis
directly followed up on Einstein's approach toward a unified field
theory), nobody could be less sympathetic to the notion of fundamental
randomness -- however, I *am* a scientist, and when something has been
thoroughly demonstrated to be really true of the physical world, I
have to accept it. We probably don't have an optimal *explanation* of
the phenomenon, but we *do* have an accurate understanding of its
practical consequences.
> I tentatively suggest calling it a day. Perhaps if new arguments can
> be offered that would be useful -
The "new arguments" would be presented to you as a student of quantum
physics. I agree it is a waste of bandwidth to continue the argument
until then.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 21 Aug 2000 15:49:09 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Clark S. Cox III
([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> > <8nq0uk$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
> > >playte, chawmp (on a 32-bit machine), word (on a 16-bit machine),
> > >half-word (on a 32-bit machine).
> >
> > Ok, I'm confused now. I though a word was always 2 bytes on whatever
> > architecture you happen to be living?
> I was under the impression that a word was 16-bits on a 16-bit
> machine, 32 on a 32-bit machine, etc.
Terminology varies. In some 32-bit architectures, 16 and 32 bits are
halfword and word respectively; in others they are word and doubleword
or word and longword.
>And that in C/C++, 'int' usually corresponded to a word.
Usually, but not necessarily, it corresponds to whatever is the
hardware's most "natural" representation of integers.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Simple cipher based on SHA-1
Date: Mon, 21 Aug 2000 15:45:09 GMT
In article <[EMAIL PROTECTED]>,
Janne Tuukkanen <[EMAIL PROTECTED]> wrote:
> I'm newbie on the field, so be patient ;-)
>
> Is this worth anything:
>
> 160 bit key is created from pass phrase using SHA-1.
>
> First 64 (or what ever) bits of plaintext are XORed with
> (say for instance least significant) 64 bits from the key.
>
> The 64 bits used from the key are replaced by the
> ciphered 64 bits.
>
> New key is produced for the next block from the key using SHA-1.
>
> And so on...
>
> If the key is understood as 'state', there should always be
> at least 96 secret bits in it, and recovery of those even
> when there is known plaintext should be somewhat difficult.
> Other hand the ciphered 8 bytes are used for the next hash, so
> other documents ciphered with the same key could not be
> opened when the first one's plaintext is known.
>
> Ok, I believe this is somewhat weak (and I hope someone will
> gently point me the principles of the weaknesses of the algorithm),
> but _how_ weak? If we are living in the world of 1GHz PIII's, what
> kind of time scale it would take to break this (msecs? secs? hours?
> days? weeks? ...)
With a known plaintext you can get 128 bits of the state between two
encryptions. Also collisions in 96-bit state can be problematic.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Lehmann Primality Test
Date: Mon, 21 Aug 2000 15:46:23 GMT
In article <8nrb3i$ah0$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <8nq397$v4a$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
> > >
> > > Does anyone know the actual average fraction of composites that
will
> > > falsely indicate "prime" with the Lehmann primality test?
> > >
> > > Lehmann test: take a random a, compute a^((p-1)/2) mod p. If that
> > > value is 1 or p-1, then output "prime."
> > >
> > > I know the theoretical *upper* limit is 1/2, but a few trial runs
on
> > > my computer seem to indicate an average value much lower than
this.
> >
> > if 'p' is prime then a^(p-1) mod p will be 1. This is a similar
test
> > (actually the same test). This is also a variation of Fermats
theorem
> > and not very reliable.
>
> You know, Tom, one of these days you might stop posting
misinformation.
> But I tend to doubt it.
>
> The test is *very* reliable for even moderately sized integers.
> See the Kim & Pomerance paper that I already quoted.
I have also read that the RM test was more reliable then Fermats, which
is why I said that.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
