Cryptography-Digest Digest #530, Volume #12 Fri, 25 Aug 00 00:13:00 EDT
Contents:
Re: PGP Vulnerability (Stephen Early)
Re: PGP Vulnerability (Ornie Kamyl)
Re: Asymmetric Encryption Algorithms (DJohn37050)
Re: blowfish problem ("Spud")
Re: blowfish problem (Kaz Kylheku)
Re: blowfish problem ("Spud")
Re: blowfish problem ("Spud")
Re: blowfish problem (Dan Pop)
Re: A few big primes? (S. T. L.)
SHA-1 test request (S. T. L.)
Re: Bytes, octets, chars, and characters ("Trevor L. Jackson, III")
need help! ("John Utkke")
Re: PGP Vulnerability ("Ed Suominen")
Re: Bytes, octets, chars, and characters ("Bruce G. Stewart")
Re: Bytes, octets, chars, and characters (Benjamin Goldberg)
Re: SHA-1 test request (Paul Rubin)
Re: blowfish problem (Kaz Kylheku)
Re: SHA-1 program (cool!) (Benjamin Goldberg)
Re: blowfish problem (Eric Smith)
----------------------------------------------------------------------------
From: Stephen Early <[EMAIL PROTECTED]>
Subject: Re: PGP Vulnerability
Date: 25 Aug 2000 00:11:36 GMT
In article <[EMAIL PROTECTED]>,
Cheri & Mike Jackmin <[EMAIL PROTECTED]> wrote:
>Will this alter the fingerprint of the public key?
>
>http://www.securitywatch.com/newsforward/default.asp?AID=3690
No, it will not - nor will it prevent the key owner's signature on the
public key from verifying correctly.
Steve Early
------------------------------
From: [EMAIL PROTECTED] (Ornie Kamyl)
Subject: Re: PGP Vulnerability
Date: Fri, 25 Aug 2000 00:43:24 GMT
"Cheri & Mike Jackmin" <[EMAIL PROTECTED]> wrote:
>Will this alter the fingerprint of the public key?
>
>http://www.securitywatch.com/newsforward/default.asp?AID=3690
It seems to me that this comment from Bruce Schneier implies that this new
type of attack won't change the fingerprint:
>This tampered version of the certificate will remain unnoticed by anyone
>who doesn't manually examine the bytes...
Perhaps he'll notice this thread and comment.
Here's a more direct link to his message:
http://slashdot.org/articles/00/08/24/155214.shtml
--
"Ornie Kamyl" is actually 7354 268901 <[EMAIL PROTECTED]>.
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Asymmetric Encryption Algorithms
Date: 25 Aug 2000 01:27:11 GMT
DSA-2 will use larger numbers. IT should be released when SHA-2 is also.
Don Johnson
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 18:51:17 -0700
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Spud wrote:
> > > 5.2.4.2.1 Sizes of integer types <limits.h>
> > Aha, ... it quite happily settles the matter.
>
> Well, that's not really where it is determined, but since you
> kept rejecting the other explanations I'm glad that one
> finally convinced you.
No, I rejected things which were _not_ explanations. That was why I kept
asking.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Aug 2000 01:47:43 GMT
On 24 Aug 2000 16:52:05 -0700, Eric Smith <[EMAIL PROTECTED]>
rote:
>Is that really true? I know that the void * has to be able to
>store a value of any other pointer type.
According to C89, function pointers are excluded. I think this
has changed, but I'm too lazy to look it up.
> But is it really the case
>that a char * also has to be able to store a value of any other
>pointer type?
The types void * and char * are required to have the same representation.
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 19:01:58 -0700
[snips]
"Richard Heathfield" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > You know, there is a difference between "It's not clear he's wrong, so
he
> > must be right" and "See, it says he's right, right there on page three."
>
> Agreed. Nevertheless, consider the practicality of the situation. You
> have a Usenet discussion with a member of the ANSI C committee, who
> gives an interpretation of the Standard with which you disagree.
That's just it - I was _not_ disagreeing with the underlying conclusion.
You know, I know, he knows, we all know, that sizeof(char) is 1, that main
returns int, and that chars and bytes are synonymous. The question was
simply one of how do we actually determine this from the document itself?
The only disagreement involved was my disagreeing with arguments that did
absolutely nothing to actually resolve the issue. For example, the comments
about memcpy; they didn't matter, because the requirements would have held
true in either case, so the introduction of memcpy added absolutely nothing
in answering the question.
>What is
> the correct course of action, if you cannot reach agreement with him?
In general? Assume he actually knows what he's talking about. I do, and I
did; I never once suggested that he was wrong about the results... simply
that _determining_ those results was something, up until Chris Torek piped
in, which neither I nor others seemed to be able to do.
> Had Doug Gwyn /not/ been a member of the ANSI committee, /or/ if you
> /were/ a member, I'd understand your objection.
>
> However, IMHO, what you've achieved is useful - you've managed to get a
> clarification of a point which had mildly worried some of us (me, for
> instance).
Yeah, well, as Dann pointed out, a strictly conforming program, at least
within the limits of the program itself, couldn't possibly tell the
difference, and as I pointed out, such an implementation would be bonheaded
in the extreme, so it's not like anyone was seriously suggesting that _not_
resolving this was going to cause world hunger or something. :)
At best it was an excercise in pedantics - seeing whether or not it could
actually be determined that something commonly held true _was_ in fact
determinably true; turns out, after much page-flipping and posting that yes,
it can be determined.
> > It
> > was the latter I was looking for. Chris Torek resolved the issue, by
> > pointint out something I'd totally managed to overlook - the very point
I'd
> > repeatedly asked for, namely, where in the standard it actually _says_
he's
> > right. It's 5.2.4.2.1, and I'll be stonkered if I can explain how I
missed
> > it. (I will, however, note in my own defense that it took a good three
days
> > for anyone else to come up with it. :) )
>
> Yes, I think it was a most useful discussion. And relatively polite,
> too. Are comp.lang.c's standards slipping? ;-)
Yes, well, I never *once* called that Heathfield fellow an addlepated nin...
oops. :)
------------------------------
From: "Spud" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Thu, 24 Aug 2000 19:03:55 -0700
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> It is all perfectly clear now. It's a terminology issue. The terms char,
byte,
> and character are synonyms, but we'll refrain from stipulating that fact
in the
> interest of ... pedantry?
Bingo. I stated, at least once, that this was, from my side at least,
purely an excercise in pedantry. :)
> If the referents are identical, why are there multiple terms that are not
defined
> to be synonymous?
Does seem a tad silly, don't it?
> If the referents are not identical, what are their distinguishing
characteristics?
------------------------------
From: [EMAIL PROTECTED] (Dan Pop)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: 25 Aug 2000 01:48:58 GMT
In <[EMAIL PROTECTED]> Eric Smith <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Chris Torek) writes:
>> The problem basically boils down to several things, some of which
>> are implied by the fact that memcpy() can be implemented in strictly
>> portable C code as:
>>
>> void *memcpy(void *dst0, const void *src0, size_t len) {
>> unsigned char *dst = dst0;
>> const unsigned char *src = src0;
>>
>> while (size--)
>> *dst++ = *src++;
>> return dst0;
>> }
>
>
>Is that really true? I know that the void * has to be able to
>store a value of any other pointer type. But is it really the case
>that a char * also has to be able to store a value of any other
>pointer type?
Yup. C89 says:
A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Other pointer types
need not have the same representation or alignment requirements.
Dan
--
Dan Pop
CERN, IT Division
Email: [EMAIL PROTECTED]
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: A few big primes?
Date: 25 Aug 2000 02:21:49 GMT
<<Cool. How do I do it?
New TI-92+ user :)>>
Look for the NTH, the Number THeory library, on ticalc.org. It's in BASIC, so
you can call it yourself. One thing that most people don't realize is that
TI-92+ calculators have built-in bignum capability (612 decimal digit
precision). Which is The Way It Should Be. I myself use heavily modified
snippets of NTH code in my TI-RSA program (that's right, 1024-bit RSA on a
calculator). But I won't be able to release that program until Sept. 20. Heh.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: SHA-1 test request
Date: 25 Aug 2000 02:25:27 GMT
Hi again, sci.crypt regulars.
I'm trying to improve/debug my SHA1.EXE program that I wrote in C, and I need
to make sure that it treats huge files properly. (It can be downloaded from
http://members.aol.com/stl137/download.html ) Could someone independently
(i.e. using a program known to be rock-solid for huge files; regular
certification doesn't seem to do this) find the hash of a 1,000,000,000 byte
file consisting of the character 'a' ? If such a hash agreed with my
SHA1.EXE's results, that would give me a huge boost of confidence in my
program's accuracy. I think that I'm using unsigned long longs correctly, but
I may have missed something.
Thanks.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
Date: Thu, 24 Aug 2000 22:30:28 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
mike burrell wrote:
> short short? wtf is a short short? get it out of there whatever it is.
After this comes short longs and long shorts -- a distinction everyone should
make. ;-)
------------------------------
From: "John Utkke" <[EMAIL PROTECTED]>
Subject: need help!
Date: Thu, 24 Aug 2000 21:44:55 -0700
I am a kid interested in cryptography can someone help me with this
encryption problem, here is what I am given in this exercise.
W=T, K=O, X=S
J ISKKXO WK NOBJAO
Thanks in advance.
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Subject: Re: PGP Vulnerability
Date: Thu, 24 Aug 2000 19:47:05 -0700
Personally, I'm switching to the GNU version of GPG as soon as it becomes
available in a Win98 build. See http://www.gnupg.org/gpa.html.
I don't my crypto to have key escrow capability.
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
"Ornie Kamyl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Cheri & Mike Jackmin" <[EMAIL PROTECTED]> wrote:
>
> >Will this alter the fingerprint of the public key?
> >
> >http://www.securitywatch.com/newsforward/default.asp?AID=3690
>
> It seems to me that this comment from Bruce Schneier implies that this new
> type of attack won't change the fingerprint:
>
> >This tampered version of the certificate will remain unnoticed by anyone
> >who doesn't manually examine the bytes...
>
> Perhaps he'll notice this thread and comment.
>
> Here's a more direct link to his message:
>
> http://slashdot.org/articles/00/08/24/155214.shtml
>
> --
> "Ornie Kamyl" is actually 7354 268901 <[EMAIL PROTECTED]>.
> 01234 56789 <- Use this key to decode my email address and name.
> Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: "Bruce G. Stewart" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 02:48:42 GMT
"Trevor L. Jackson, III" wrote:
>
> mike burrell wrote:
>
> > short short? wtf is a short short? get it out of there whatever it is.
>
> After this comes short longs and long shorts -- a distinction everyone should
> make. ;-)
Hey, c could free up a key word by using "signed signed" instead of
"unsigned".
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 03:29:06 GMT
Paul Schlyter wrote:
[snip]
> >
> > You've missed the most sensible reason: if you were to write a
> > compiler for a processor with 64-bit registers and no backward
> > compatibility issues and you made int a 64-bit type, how would you
> > map the 8-bit, 16-bit and 32-bit integers on the C89 standard types?
> >
> > If you make int a 32-bit type, the solution becomes obvious:
> >
> > char 8-bit
> > short 16-bit
> > int 32-bit
> > long 64-bit
>
> Java prescribes:
>
> byte 8-bit
> char 16-bit
> short 16-bit
> int 32-bit
> long 64-bit
>
> The reason for 16-bit chars are that Java always uses Unicode
> internally.
>
>
> In C though, the most common solution seems to be:
>
> char 8-bit
> short 16-bit
> int 32-bit
> long 32-bit
> (long long 64-bit)
>
> On 64-bit machines, one alternative could be:
>
> char 8-bit
> short short 16-bit
> short 32-bit
> int 64-bit
> long 128-bit
> long long 256-bit
It's too bad that integers weren't initially called int8, int16, etc,
with no "short" or "long" types. If that had been done, we wouldn't
have to worry about this type of problem now. Of course, we might then
have wanted a type word, hword, and dword *in addition* to specifically
refer to a machine register, half of a register, or two registers... but
unless I misrecall, some compilers have these defined.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: SHA-1 test request
Date: 25 Aug 2000 03:41:56 GMT
In article <[EMAIL PROTECTED]>,
S. T. L. <[EMAIL PROTECTED]> wrote:
>file consisting of the character 'a' ? If such a hash agreed with my
>SHA1.EXE's results, that would give me a huge boost of confidence in my
>program's accuracy. I think that I'm using unsigned long longs correctly, but
>I may have missed something.
Why are you using long longs for anything? SHA1 uses 32-bit operations.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Aug 2000 03:49:25 GMT
On Thu, 24 Aug 2000 19:01:58 -0700, Spud <[EMAIL PROTECTED]> wrote:
>The only disagreement involved was my disagreeing with arguments that did
>absolutely nothing to actually resolve the issue. For example, the comments
>about memcpy; they didn't matter, because the requirements would have held
>true in either case, so the introduction of memcpy added absolutely nothing
>in answering the question.
How so? If memcpy copied only half of every 16 bit byte in your example
implementation, due to characters being only 8 bits wide, then it would clearly
fail to be capable of copying the values of data objects which take advantage
of the full 16 bits.
Perhaps in your example implementation, *no* type uses more then 8 bits of any
16 bit byte. If that is the case, then, effectively, the C implementation has
*defined* bytes as being 8 bits wide. That these bytes are stored in wider
units of actual memory is irrelevant; storage bits that are not visible to the
C program effectively do not exist.
If your computer has two parity bits for each 8 bit byte, does that make your
byte size 10?
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: SHA-1 program (cool!)
Date: Fri, 25 Aug 2000 03:55:18 GMT
S. T. L. wrote:
[snip]
> Well, I've always made the crocky assumption in SHA1.C that the file
> length will be less than 2^32 bits, and the first word is
> automatically all zeroes. (Hence why I know absolutely that it will
> fail for files > 512MB). Otherwise, I think that I append the length
> properly.
>
> Perhaps I'll need to include a bignum library or make a clever hack so
> that I can deal with files that are over 2^32 bits. Argh. Thanks for
> everyone's help.
You do NOT need a bignum library to create any fixed size counter. To
make a 64 bit counter with 32 bit integers, do the following:
unsigned int counter_hi, counter_lo; /* int is 32 bits */
if( ++counter_lo == 0 ) ++counter_hi;
S.T.L. : I'll email you my implementation, since it would be rude to
send it here to the NG.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: 24 Aug 2000 21:05:58 -0700
Chris Torek <[EMAIL PROTECTED]> wrote:
> The problem basically boils down to several things, some of which
> are implied by the fact that memcpy() can be implemented in strictly
> portable C code as:
>
> void *memcpy(void *dst0, const void *src0, size_t len) {
> unsigned char *dst = dst0;
> const unsigned char *src = src0;
>
> while (size--)
> *dst++ = *src++;
> return dst0;
> }
I asked:
> Is that really true? I know that the void * has to be able to
> store a value of any other pointer type. But is it really the case
> that a char * also has to be able to store a value of any other
> pointer type?
[EMAIL PROTECTED] (Dan Pop) writes:
> Yup. C89 says:
>
> A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type. Other pointer types
> need not have the same representation or alignment requirements.
But pointers other than void * and char * can have different representation
and alignment requirements? If so, then the memcpy above can't be
guaranteed to work.
------------------------------
** 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
******************************
