Le 09/12/2011 07:30, Hunter William a écrit : > On 08 December 2011 00:41 Douglas E. Engert wrote: >> With regards to the original problem of a short serial number >> being the issue, the problem may be that some code is comparing >> the MAX_CONTAINER_NAME_LEN as binary and not as a string. >> We may have in OpenSC some field that is not initialized to null, >> foe example the WCHAR wszGuid [MAX_CONTAINER_NAME_LEN + 1]; >> and this may be the problem. >> >> Can you try and make sure this is initialized before the call? >> > The problem here lies in the serialize_guid code which insists that > the input data length must be at least 16 - which makes sense if > it wants to convert it to a GUID style string.
In my mind the task of serializer is to produce a 'canonical' GUID string and it's not it's matter to pad/complete the missing bytes -- this task belongs to get_guid(). MAX_CONTAINER_NAME_LEN is defined in cardmod.h as 39. For serializer the minimal acceptable length of output string is 39. This length is sufficient to acquire canonical GUID string with string closing '\0'. Prepared by get_guid() the input array for serializer is initialized with 'zeros'. > However, given that it seems that the key container is not a true > GUID, but just a string that needs to be unique among other key > containers on the system, perhaps we could use a simpler solution. > > Perhaps taking the last 8 bytes of the serial number and the last > 8 bytes of the ID (pre-padding both with 0x00 or 0xFF if too short). > Or even fold the serial number and ID into 8 bytes if too long, so > that all the information is used. This should be unique enough in > all but the most pathological cases? As for me: - if ID is long, then we can consider that it's not consequential number, and is in fact a hash or random. And so we can consider as sufficiently unique the 16 bytes of this number. - if ID is short, then concatenated with serial number it can be considered as unique. > However, I can see the first bug report when someone manages to > find a serial number/ID clash - so my opinion is that it's probably > worth just using a hash from the beginning. I would not be so pessimistic, imho, it's difficult to find the clash of card serials, it will be more difficult to find the clash of ID/serial. Finally, I do not have many technical reasons to defend one or other manner to compose the binary data for GUID. The only my consideration is that it has not be depending on the build configuration. We can integrate some hash procedure into OpenSC and use in get_guid(). If it'll be SHA1, it could be used also in other places of OpenSC that are currently in '#ifdef OPENSSL'. > Viktor, what do you think? > > Cheers, > Will Kind regards, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
