Cryptography-Digest Digest #532, Volume #12 Fri, 25 Aug 00 07:13:01 EDT
Contents:
SSL implementation for client authentication ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("G Swaine")
Re: SHA-1 test request (Francois Grieu)
Re: Serious PGP v5 & v6 bug! (David Kennedy CISSP)
Re: Bytes, octets, chars, and characters (Casper H.S. Dik - Network Security
Engineer)
Re: Serious PGP v5 & v6 bug! ("Michel Bouissou")
Re: ADK Bug: Statement from cert.org. (Keith)
senders using the modified certificate have no way to detect the modification
without complicated manual inspection (Keith)
Re: Serious PGP v5 & v6 bug! (Keith)
Re: Serious PGP v5 & v6 bug! (Keith)
Re: blowfish problem (Richard Bos)
Re: The DeCSS ruling - Reverse engineering? (rot26)
Re: Bytes, octets, chars, and characters (AndyC)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: SSL implementation for client authentication
Date: Fri, 25 Aug 2000 08:11:10 GMT
Hi experts there out,
I am implementing a project in which I have to to a client authenticaton
in a IBM HTTP server.In generl can some one tell me how can I implement
the client authentication or which directives I put in.Please give me
the details and step procedure,and also do I need to generate the key
file database ,since I have read their can be only one instance of the
keyfile Db in the conf file(please clear).if possible I will be very
much obliged if you all can do so.
Thanks
Jagjit
IBM India
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "G Swaine" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 20:19:01 +1200
Reply-To: "G Swaine" <[EMAIL PROTECTED]>
"Paul Schlyter" <[EMAIL PROTECTED]> wrote ...
> John Savard <[EMAIL PROTECTED]> wrote:
> > Another way to consider the word length of a machine would be to see
> > what alignment restrictions apply to instructions. This makes a
> > System/360 a 16-bit machine, and even a Pentium an 8-bit machine;
> > while this is an unambiguous convention, it doesn't say anything
about
> > the power of the machine or the underlying architecture, so it
hasn't
> > been used.
>
> Using that as a criterion for the word length would have some weird
> effects: it would make the 68000 and 68010 16-bit CPU's, while the
> 68020 and later would be 8-bit CPU's......
The '020 required instructions to be on even addresses, AFAICR
--
Due to the amount of junkmail I've received in the past, this message
has bogus From and ReplyTo names and addresses. I can be contacted via
an intermediary : gem at gem win co nz. I would like to apologise to the
genuine respondents that this may inconvenience.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: SHA-1 test request
Date: Fri, 25 Aug 2000 10:33:00 +0200
[EMAIL PROTECTED] (S. T. L.) wrote:
> 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.
> Could someone (..post..) the hash of a 1,000,000,000 byte
> file consisting of the character 'a' ?
Test vestors for SHA1 have been independently cross-verified by
Jim Gillogly and myself on Aug 1998. Our focus was on messages
with bit length not a multiple of 8. The vectors include an example
over 2^32 bits, see my repost:
<http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=544748495&fmt=text>
As of your 10^9 times the byte 0x61, my implementation gives
D0F3E4F2 F31C665A BBD8F518 E848D5CB 80CA78F7
I second other comments that you should read the file once only.
As of computing the file length, I use something in the line of
unsigned long my_lenL, my_lenH, len; /* at least 32 bits */
/* update my_len with len, expressed in bytes */
my_lenL += len; /* update my_lenL */
if (my_lenL<len) ++my_lenH; /* update my_lenH */
/* enter the extra length vn (0..7) and my_len in the buffer W */
my_W[14] = (my_lenH<<3)|(my_lenL>>29);
my_W[15] = (my_lenL<<3)|vn;
I believe this is correct on any ANSI C platform: it is guaranteed
"unsigned long" performs arithmetic mod 2^k for some integer k at
least 32.
As of portability, I recommand that you test your C code on a
variety of environements, including big-endian and little-endian,
and with 16 bit ints.
Francois Grieu
------------------------------
From: David Kennedy CISSP <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 04:43:53 -0400
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
JL wrote:
>
> > Is it Ralf's opinion that manipulated keys do not reveal the
presence of
> > ADKs?
>
> Not from what I understand from what has been quoted.
>
> > If so, why do keys containing "legal" ADKs differ from manipulated
ones in
> > failing to announce the presence of the second key?
>
> "Legal" ADKs are signed by the key holder, not manipulated ones. But
PGP
> doesn't check whether sthey're signed or not, that's the bug.
>
If my test is accurate, a corrupted key will *not* generate any
obvious indications during either encryption or decryption.
I d/l'd the keys on Ralf' site. I imported A4 to my kering. There
were no indications in that process that the key included an ADK.
There were two sigs, one self-signed, one unknown. When I did a key
properties, I was able to see the ADK's listed and they included the
same key as the unknown sig.
I encrypted an arbitrary message to myself and the A4 key. I have the
box in Advanced Preferences checked. I did *not* reveive a warning I
was encrypting to an ADK. When I received the message, I saw the
normal dialog box listing the two keys the message was encrypted with.
The ADK was not listed.
Client: Eudora 3.05(32) on Win 98SE
PGP: 6.0.2 from NAI w/RSA (commercial version)
- --
Regards,
Dave Kennedy CISSP
Director of Research Services, ICSA.net http://www.icsa.net
Protect what you connect.
Look both ways before crossing the Net.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: When did you last back up your hard drive?
iQCVAwUBOaYxivGfiIQsciJtAQFdGgP/aQfSly++cE7aeMLbetleMTpaJw8UDScF
lOUUh91So1eWVhjwPAHYlxiFJS6NJ78R8MNsJ0o6S9Medlg/vvbbIf7PKMiNJNnw
YDtJ5aikf4dkf83dJKeom8Eefy64UG6FHsUfUYWRTg2GIl6LktjMN1pW59DQKdue
xCJiQJQOdRU=
=BnkT
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 08:51:09 GMT
[[ Reply by email or post, don't do both ]]
[EMAIL PROTECTED] (Paul Schlyter) writes:
>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
The most common 64 bit solution appears to be:
char 8-bit
short 16-bit
int 32-bit
long 64-bit
long long 64-bit
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 11:08:38 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
<[EMAIL PROTECTED]> a �crit dans le message :
8o3ris$92u$[EMAIL PROTECTED]
>
> have read Ralf's paper, please correct me if i mis-understand the
> following conclusion in the paper:
I had copied Ralf Senderek on one of the messages I posted to this
NG, and he sent me in return some precisions and corrections about
things that I had overlooked or misunderstood in my post.
Here are some interesting parts of the message that Ralf sent me,
reproduced here with his prior agreement:
(Ralf's words are preceded with *> and my previous message is
preceded with >>>
Previous quotes from messages from others are preceded with a higher
number of ">")
>>> > Aren't ADKs possible with RSA Public keys?
*> The manual states, that incoming ADKs must be DH-keys.
*> But that is definitely not true , use my key-F4 and you will see.
>>> I thought they were not possible, but reading
>>> http://senderek.de/security/key-experiments.html I learnt that I
>>> was mistaken and they seem to be actually possible when the RSA
>>> key has been generated under PGPv5 or PGPv6, because it will then
>>> use the v4 signature scheme that allows it, or even an existing
>>> RSA key made from PGP 2.6x (with a v3 signature scheme that
>>> doesn't support ADKs) could be "transformed" into a v4 one using
>>> PGPv5 or PGPv6, which would render it vulnerable to ADKs. This is
>>> my understanding of this part of the document, although the
>>> mechanism that will allow such a transformation from v3 to v4 is
>>> quite unclear to me.
*>This is not what I found out. I documented in my paper that PGPv5/6
*>create RSA-keys with Version-3 self-signatures.
*>I had created all V4-self-signatures on RSA-keys with GnuPG, a
software
*>which is so opposed to RSA that it uses V4-signatures even on
RSA-keys.
*>But who knows, maybe the next version of PGP will have this feature
as well.
>>> I don't expect RSA v3-signed keys that are simply imported into
>>> PGPv5 or PGPv6 to suddenly change into RSA v4-signed keys,
>>> because for this it would at least need that the key owner
>>> resigns the key (and would apparently result in the key ID and
>>> fingerprints to change).
*>That is correct.
>>> Maybe Ralf Senderek could give better explanations about the way
>>> a RSA v3-signed key could transform into a RSA v4-signed key...?
*>It's all in my paper. Look at the first picture and you will see
that
*>transforming RSA-V3 to RSA-V4 is not a big job. But note I haven't
found
*>a version of PGP which does the transformation automatically
*>during my resarch.
*>But that doesn't mean it cannot be done automatically. I simply
*>have not checked all possible ways to invoke PGP or pressed any
possible
*>button.
[...]
>>> Or replace PGP with GnuPG which, although it manages PGP's DH/DSS
>>> keys quite well, doesn't seem to understand PGP's additional
>>> "features" such as ADKs or supplementary revokers.
*> Are you sure? Do you have any evidence? Maybe they just ignore the
problem,
*> which as I showed isn't helpful. I do not recommend GnuPG for
encryption!
*>
*>Ralf.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBOaYpg47YarFcK+6PEQJW6QCfVHhDP4ZTYlvxi8f0MVNd73C/6rMAn1J1
ZdNubdkwOSdgzIlI571/O1Rc
=1/OV
=====END PGP SIGNATURE=====
------------------------------
From: Keith <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: ADK Bug: Statement from cert.org.
Date: Fri, 25 Aug 2000 02:16:48 -0700
Reply-To: "Keith" <[EMAIL PROTECTED]>
On Fri, 25 Aug 2000 00:26:05 -0700, Jeremy Bishop
<[EMAIL PROTECTED]> wrote:
>Move along folks, show's over.
Not until a independent full review of PGP and it's source code is
completed should anyone use this product. They only way to accomplish this
is for NAI to remove the "review gag order" on all users of PGP.
--
Best Regards,
Keith
=============================================================================
Where do you discover free software for Windows? Strongsignals DOT COM is a
great place to start: http://Strongsignals.com "If a man hasn't discovered
something that he will die for, he isn't fit to live." --Martin Luther King, Jr
PGP V5 & Above is a excellent UUENCODING Program!
============================================================================
------------------------------
From: Keith <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: senders using the modified certificate have no way to detect the modification
without complicated manual inspection
Date: Fri, 25 Aug 2000 02:30:33 -0700
Reply-To: "Keith" <[EMAIL PROTECTED]>
On Fri, 25 Aug 2000 04:43:53 -0400, David Kennedy CISSP
<[EMAIL PROTECTED]> wrote:
>I encrypted an arbitrary message to myself and the A4 key. I have the
>box in Advanced Preferences checked. I did *not* reveive a warning I
>was encrypting to an ADK. When I received the message, I saw the
>normal dialog box listing the two keys the message was encrypted with.
> The ADK was not listed.
Right, this is what so many people have missed in this whole affair.
You can't detect the ADK without manually checking every key. The other part
is that if someone already has an ADK attached to a key on a key ring it would
never seem that they have an rogue ADK and would have the ADK detection turned
off, because they would receive the annoying message every time they encrypted
to it. The ADK exploit is a disaster for companies that have employed ADK's and
their employees turn off the ADK notification feature.
>From cert.org advisory:
"Since a user's public key certificate is often widely distributed, an attacker
could make this modification to a specific copy of the certificate without the
legitimate user's knowledge. When a vulnerable version of PGP uses the
modified certificate for encryption, it fails to detect that the ADK is
contained in the unsigned portion of the certificate. Because PGP does not
report an invalid signature, senders using the modified certificate have no
______________________________________________
way to detect the modification without complicated manual inspection"
______________________________________________________________________
A full independent review of PGP and it's source code is required
to insure that no further exploits like the UNIX version random
generation problem and this newly discovered ADK exploit are
available. I don't believe a full review of PGP is too much to
ask.
--
Best Regards,
Keith
=============================================================================
Where do you discover free software for Windows? Strongsignals DOT COM is a
great place to start: http://Strongsignals.com "If a man hasn't discovered
something that he will die for, he isn't fit to live." --Martin Luther King, Jr
PGP V5 & Above is a excellent UUENCODING Program!
============================================================================
------------------------------
From: Keith <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 02:42:12 -0700
Reply-To: "Keith" <[EMAIL PROTECTED]>
On Fri, 25 Aug 2000 06:56:21 +0100, Howard
<F5op5.55$[EMAIL PROTECTED]> wrote:
>
>However as I said this is hardly covert, since all versions of PGP
>apparently warn the user that additional keys are present. Therefore this
>is not a "backdoor" but a potential security problem which would largely
>affect inexperienced users.
Howard here is the critical part from the CERT advisory. I know that reading
the original web page is complicated, but this will help you to understand what
I am talking about.
Please read the last sentence carefully:
>From cert.org
http://www.cert.org/advisories/CA-2000-18.html
"Since a user's public key certificate is often widely distributed, an attacker
could make this modification to a specific copy of the certificate without the
legitimate user's knowledge. When a vulnerable version of PGP uses the modified
certificate for encryption, it fails to detect that the ADK is contained in the
unsigned portion of the certificate. Because PGP does not report an invalid
signature, senders using the modified certificate have no way to detect the
modification without complicated manual inspection"
--
Best Regards,
Keith
=============================================================================
Where do you discover free software for Windows? Strongsignals DOT COM is a
great place to start: http://Strongsignals.com "If a man hasn't discovered
something that he will die for, he isn't fit to live." --Martin Luther King, Jr
PGP V5 & Above is a excellent UUENCODING Program!
============================================================================
------------------------------
From: Keith <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 02:44:14 -0700
Reply-To: "Keith" <[EMAIL PROTECTED]>
On Fri, 25 Aug 2000 06:56:21 +0100, Howard
<F5op5.55$[EMAIL PROTECTED]> wrote:
>No, and here I agree with you. But I for one haven't read anything from
>them as yet - and this news broke only yesterday (I think..). Have you
>contacted NIA and asked for a statement, or comment from them? Do you think
>it's a good idea to have their views before condemning so vociferously?
They have responded and concur with the original discovery by the
researcher that found this exploit. They will be releasing a update
to insure that the entire key along with any ADK's are protected by the
signature.
See http://www.cert.org/advisories/CA-2000-18.html
--
Best Regards,
Keith
=============================================================================
Where do you discover free software for Windows? Strongsignals DOT COM is a
great place to start: http://Strongsignals.com "If a man hasn't discovered
something that he will die for, he isn't fit to live." --Martin Luther King, Jr
PGP V5 & Above is a excellent UUENCODING Program!
============================================================================
------------------------------
From: [EMAIL PROTECTED] (Richard Bos)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 25 Aug 2000 10:17:40 GMT
Eric Smith <[EMAIL PROTECTED]> wrote:
> 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.
Yes, it can, because all objects can be accessed as if they were an
array of unsigned char. This implies that all objects are aligned on
char alignment or stricter, not looser.
Richard
------------------------------
From: rot26 <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling - Reverse engineering?
Date: Fri, 25 Aug 2000 10:30:30 GMT
Putting the debate of legality of reverse engineering (RE) aside, I just
wonder whether any such act of RE has actually taken place. Since it is
clearly stated on the paper "Cryptanalysis of Contents Scrambling
System" that analysis is based on "a piece of source code claiming to be
the css algorithms, and which have since been confirmed to interoperate
with the CSS system."
The point I want to make is that in order to write the paper the author
need not perform any decompilation, disassembly, or taking apart
physical components. Little doubt that DeCSS software is based on the
paper and I suspect little further info about the CSS algorithm is
required (i.e. not given on the paper), how is it that anyone would have
violated the law regarding RE?
rot26
===================
Reverse engineer it
After you buy
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: AndyC <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 11:31:06 +0100
On Fri, 25 Aug 2000, G Swaine wrote:
> The '020 required instructions to be on even addresses, AFAICR
That was a requirement of all 68k chips, IIRC.
AndyC
------------------------------
** 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
******************************
