[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SDSI syntax
> There's another issue with the "canonical" encoding in SDSI - it's
>not possible to perform signature generation or signature verification
>in single pass through the SDSI object. This is because the verbatim
>representation includes a length field at the beginning of the
>octet-string.
I also started to worry about that given the propensity of the IETF for
deciding that everything is a nail when given a particular hammer they like.
Since we are merely using the canonical form for developing the hash value we
could use a self describing length format. After all there is no need for the
canonical form to be easy to convert from. It is merely the input to the hash
function. Plus since we are likely to be using an MD4 type digest where there is
a compressor fucntion and a chaining mechanism this does not need to introduce
inefficiency. We can perform the encoding step as we construct the values for
the compression block.
I would suggest we use the expansion 00 -> 00 00 and then use the sequence
00 FF as an end of block marker. That can be generated in a single pass by an
FSR without any backtracking. Then we are OK even if someone later comes along
with some derranged scheme which involves large and unwieldy chunks of text.
Compared to the time complexity of MD5/SHA I don't think we need to worry about
such a transformation. On the other hand space complexity worries me greatly. I
would like to be able to implement many crypto functions on smartcards with
crypto processors where memory may be at an extreeme premium.
> But I'm disappointed that the only thing we're talking about is the
>syntax. The semantics of SDSI bring up very large questions, and I can't
>say I'm fully satisfied with the design
My experience is that it is often necessary to discuss syntax before people
can move to discussion of semantics simply because they need a medium to
express their ideas
I think that the role of SDSI is potentialy simliar to that played by iKP
in the credit card format wars. The point of iKP was not the suggestion itself
but the fact that it solved enough of the problem to serve as a paradigm to
which all other proposals could be compared. Indeed there was no real technical
value in 1KP or 2KP in that Mastercard was intending from the start to do 3KP.
On the other hand these did play a critical role in breaking down the previously
established mindset.
Ralphs's point is well made in that maybe the semantics of SDSI are not quite
what we would like. That is something that we need to discuss further. It is
likely that the discussion will reveal many of the unspoken assumptions which
affect our view of the problem. It may be logical to describe systems in terms
of requrements which lead to an architecture which is realised in an
implementation but the mind often seems to work better in reverse. Experience of
use informs architecture and requirements. Often it is better to ask "what
problems can I solve with this technology" than atteempt to find a solution to
previously laid down assumptions.
Phill
References: