Ironclad Library?

Hi,

I just ran into a perplexing situation here. I have been using Ironclad for SHA256 and AES256 functions. Up to now I have been totally happy -- read: it seems internally consistent. But now, when using against encrypted products from a C implementation of these same functions, I can't get my Ironclad digests to agree with the C library versions.

On further investigation, the C library functions for SHA256 produce output consistent with published test vectors, while Ironclad SHA256 does not. Strangely, however, they do agree on the SHA256 sum of disk files. But on anything else -- byte vectors representing strings in memory, they depart wildly, with the C implementation producing apparently correct results. The C implementation is from PolarSSL.

Is anyone else using Ironclad? Is it being maintained? Has anyone else seen this deviant behavior?

Dr. David McClain

dbm@refined-audiometrics.com

Re: Ironclad Library?

David McClain <dbm@refined-audiometrics.com> writes:

> Hi,
>
> I just ran into a perplexing situation here. I have been using Ironclad for
> SHA256 and AES256 functions. Up to now I have been totally happy -- read: it
> seems internally consistent. But now, when using against encrypted products
> from a C implementation of these same functions, I can't get my Ironclad
> digests to agree with the C library versions.
>
> On further investigation, the C library functions for SHA256 produce output
> consistent with published test vectors, while Ironclad SHA256 does not.
> Strangely, however, they do agree on the SHA256 sum of disk files. But on
> anything else -- byte vectors representing strings in memory, they depart
> wildly, with the C implementation producing apparently correct results. The C
> implementation is from PolarSSL.
>
> Is anyone else using Ironclad? Is it being maintained? Has anyone else seen
> this deviant behavior?

I use ironclad, though not on LispWorks, and have not had any trouble
with SHA1 and MD5 digests of sequences, but I haven't tried SHA256 on
sequences.

Is there some example input & output I could check on my implementation
to see if I get the same problem?

Zach

Re: Ironclad Library?

Hi David,

Am 27.11.2011 um 01:16 schrieb David McClain <dbm@refined-audiometrics.com>:

> Hi,
> 
> I just ran into a perplexing situation here. I have been using Ironclad for SHA256 and AES256 functions. Up to now I have been totally happy -- read: it seems internally consistent. But now, when using against encrypted products from a C implementation of these same functions, I can't get my Ironclad digests to agree with the C library versions.
> 
> On further investigation, the C library functions for SHA256 produce output consistent with published test vectors, while Ironclad SHA256 does not. Strangely, however, they do agree on the SHA256 sum of disk files. But on anything else -- byte vectors representing strings in memory, they depart wildly, with the C implementation producing apparently correct results. The C implementation is from PolarSSL.
> 
> Is anyone else using Ironclad? Is it being maintained? Has anyone else seen this deviant behavior?

You have to be really really careful what type of vector you feed in. If you feed the wrong one there will be no error but wrong digest results!

Cheers,
Jochen

Re: Ironclad Library?

There is also the following paper on predicate dispatching :

"Predicate Dispatching in the Common Lisp Object System", Aaron Mark Ucko, AI Technical Report 2001-006.

Regards,

Tom
----------------------------------------------------------------
Thomas M. Hermann
Odonata Research LLC
http://www.odonata-research.com/
http://www.linkedin.com/in/thomasmhermann

On Wed, Nov 30, 2011 at 12:38 PM, Jochen Schmidt <js@crispylogics.com> wrote:

One possibility would be something like predicate dispatch. AFAIR Pascal Costanza did some work in that direction with his "Filtered Dispatch".

Am 30.11.2011 um 16:23 schrieb Martin Simmons <martin@lispworks.com>:

>
> Class names are always symbols in Common Lisp, so it isn't possible to
> specialize on compound types.
>
> --
> Martin Simmons
> LispWorks Ltd
> http://www.lispworks.com/
>
>
>>>>>> On Mon, 28 Nov 2011 02:36:20 -0700, David McClain said:
>>
>> Yep! That was the whole problem.. the giveaway was that it successfully performed a SHA2 sum on files, but not on my test vectors done in the listener.
>>
>> I wonder if there is a way to make CLOS more sensitive to compound types? Vector (of what?). It manages okay between strings, vectors, and lists. But no way to indicate sub-species of vectors in the outer type discrimination. [ I also fear that I'm aiming down the road to FPL, and that isn't what I want either.. .I like Lisp's flexibility. Guess I just need to be more careful.]
>>
>> - DM
>>
>> On Nov 26, 2011, at 17:32 PM, Jochen Schmidt wrote:
>>
>>>
>>> Hi David,
>>>
>>> Am 27.11.2011 um 01:16 schrieb David McClain <dbm@refined-audiometrics.com>:
>>>
>>>> Hi,
>>>>
>>>> I just ran into a perplexing situation here. I have been using Ironclad for SHA256 and AES256 functions. Up to now I have been totally happy -- read: it seems internally consistent. But now, when using against encrypted products from a C implementation of these same functions, I can't get my Ironclad digests to agree with the C library versions.
>>>>
>>>> On further investigation, the C library functions for SHA256 produce output consistent with published test vectors, while Ironclad SHA256 does not. Strangely, however, they do agree on the SHA256 sum of disk files. But on anything else -- byte vectors representing strings in memory, they depart wildly, with the C implementation producing apparently correct results. The C implementation is from PolarSSL.
>>>>
>>>> Is anyone else using Ironclad? Is it being maintained? Has anyone else seen this deviant behavior?
>>>
>>> You have to be really really careful what type of vector you feed in. If you feed the wrong one there will be no error but wrong digest results!
>>>
>>> Cheers,
>>> Jochen
>>>
>>>
>>
>> Dr. David McClain
>> dbm@refined-audiometrics.com
>