Re: Cryptlib OpenPGP enveloping occasionally produces unreadable data

Lahiru Dissanayake <[email protected]> Tue, 24 Jun 2014 12:02:18 +0800
Newsgroups gmane.comp.encryption.cryptlib
Message-ID <CAHeAcfBHbU-iAUK8RP5v74-ivBAo5Ykf0-BsA_oQRL+7r6YMLQ@mail.gmail.com>
Hi Peter,

Unfortunately, the fix you suggested didn't seem to work when I tried it.

Just to confirm, the code block you changed belongs to the if condition
if( cryptStatusOK( status ) && !memcmp( dataSample, samplePtr, 16 ) )
at line 297, doesn't it?

In fact, this condition never evaluates to true when I run the test.

Regards,
Lahiru


On Mon, Jun 23, 2014 at 5:53 PM, Peter Gutmann <[email protected]>
wrote:

> Lahiru <[email protected]> writes:
>
> >I notice that when we perform openpgp enveloping, cryptlib occasionally
> >produces data that cannot be de-enveloped by itself. I've attached the
> code
> >for a test I wrote for this. When I run it, cryptlib gives
> >CRYPT_ERROR_BADDATA about 5-10 times out of a 1000.
>
> The problem occurs because some of the lower-level code used by cryptlib
> performs leading-zero truncation and some doesn't (specifically, PKCS #11
> drivers are erratic as to whether they do it or not, see the code comment
> in
> device/pkcs11_pkc.c).  cryptlib tries to compensate for the differences,
> but
> in this case it over-compensated (the fact that about one in 256 operations
> failed was the giveaway because 1/256 results will have a leading zero,
> what
> puzzled me was that I knew I'd addressed this issue, but it was being
> cancelled out in a second location that only occurred with PGP data).
>  Anyway,
> the fix is, in mechs/mech_pkwrap.c, line 297, to change the code block to:
>
>                 {
>                 status = krnlSendMessage( mechanismInfo->wrapContext,
>
> IMESSAGE_CTX_ENCRYPT, wrappedData,
>
> wrappedDataLength );
>                 if( cryptStatusOK( status ) )
>                         {
>                         const BYTE *dataPtr = mechanismInfo->wrappedData;
>                         int dataLength = wrappedDataLength;
>
>                         /* The PKC wrap functions take a fixed-length
> input and produce
>                            a fixed-length output but some of this can be
> leading-zero
>                            padding, so we strip the padding if there's any
> present */
>                         if( *dataPtr == 0 )
>                                 {
>                                 while( *dataPtr == 0 && dataLength > 16 )
>                                         {
>                                         dataPtr++;
>                                         dataLength--;
>                                         }
>                                 ENSURES( dataLength >= 16 );
>                                 memmove( mechanismInfo->wrappedData,
> dataPtr,
>                                                  dataLength );
>                                 memset( ( BYTE * )
> mechanismInfo->wrappedData + dataLength,
>                                                 0, wrappedDataLength -
> dataLength );
>                                 }
>                         mechanismInfo->wrappedDataLength = dataLength;
>                         }
>                 }
>
> Peter.
>

_______________________________________________
Cryptlib mailing list
[email protected] via Mail: [email protected]
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.