Re: [opensc-devel] ID of cryptographic objects
Viktor TARASOV:
> Aktiv Co. Aleksey Samsonov wrote:
>> Viktor TARASOV:
>>> Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
>>>
> It's commited ...
Thanks, good work.
--- /trunk/src/libopensc/pkcs15-pubkey.c (revision 3818)
+++ /trunk/src/libopensc/pkcs15-pubkey.c (revision 3820)
@@ -70,5 +70,5 @@
static const struct sc_asn1_entry c_asn1_gostr3410key_attr[] = {
- { "value", SC_ASN1_PATH, SC_ASN1_TAG_SEQUENCE |
SC_ASN1_CONS, 0, NULL, NULL },
+ { "value", SC_ASN1_PATH, SC_ASN1_TAG_SEQUENCE |
SC_ASN1_CONS, 0, NULL, NULL },
{ "params_r3410", SC_ASN1_INTEGER, SC_ASN1_TAG_INTEGER, 0,
NULL, NULL },
;)) Those space characters were deliberately solution, but let it be.
Also I'm going to do some changes for GOST key, if you don't mind.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Aktiv Co. Aleksey Samsonov wrote:
> Viktor TARASOV:
>> Aktiv Co. Aleksey Samsonov wrote:
>>> Viktor TARASOV:
>>
It's commited ...
>>> Thanks, but some remarks:
>>>
>>> Potencial memory leaks (see /* */):
>>
>> Thanks for your code revision. I'll be more attentive.
>>
>> Considering the 'SC_ERROR_OUT_OF_MEMORY' error,
>> IMHO, it's quiet dangerous to regroup the allocations,
>> then, if at least one pointer is not valid,
>> try to liberate the allocated memory without verifying of every
>> particular pointer.
>> src/pkcs15init/pkcs15-rtecp.c +529
>> src/pkcs15init/pkcs15-rtecp.c +542
>> src/libopensc/card-rutoken.c +1143
>> ...
>
> What do you mean by "quiet dangerous to regroup the allocations"?
>
> src/pkcs15init/pkcs15-rtecp.c:
> 496: sc_rtecp_genkey_data_t data;
> ...
> 523:data.u.rsa.modulus = calloc(1, data.u.rsa.modulus_len);
> 524:data.u.rsa.exponent_len = key_info->modulus_length / 8
> / 2;
> 525:data.u.rsa.exponent = calloc(1, data.u.rsa.exponent_len);
> 526:if (!data.u.rsa.modulus || !data.u.rsa.exponent)
> 527:{
> /* 1. data.u.rsa.modulus == VALID_PTR; data.u.rsa.exponent == NULL */
> /* 2. data.u.rsa.modulus == NULL; data.u.rsa.exponent == NULL */
> /* 3. data.u.rsa.modulus == NULL; data.u.rsa.exponent == VALID_PTR */
> 528:free(data.u.rsa.modulus); /* if
> data.u.rsa.modulus == NULL then no effect, else free mem */
> 529:free(data.u.rsa.exponent); if
> data.u.rsa.exponent == NULL then no effect, else free mem */
> /* data is local variable */
> SC_FUNC_RETURN(card->ctx, 0,
> SC_ERROR_OUT_OF_MEMORY);
> }
>
> http://www.opengroup.org/onlinepubs/7990989775/xsh/calloc.html:
> RETURN VALUE
> Upon successful completion with both nelem and elsize non-zero,
> calloc() returns a pointer to the allocated space. If either nelem or
> elsize is 0, then either a null pointer or a unique pointer value that
> can be successfully passed to free() is returned. Otherwise, it
> returns a null pointer and sets errno to indicate the error.
>
> http://www.opengroup.org/onlinepubs/7990989775/xsh/free.html:
> DESCRIPTION
> If ptr is a null pointer, no action occurs.
Thanks. I've been wrong.
Kind wishes.
--
Viktor Tarasov
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Viktor TARASOV:
> Aktiv Co. Aleksey Samsonov wrote:
>> Viktor TARASOV:
>
>>> It's commited ...
>> Thanks, but some remarks:
>>
>> Potencial memory leaks (see /* */):
>
> Thanks for your code revision. I'll be more attentive.
>
> Considering the 'SC_ERROR_OUT_OF_MEMORY' error,
> IMHO, it's quiet dangerous to regroup the allocations,
> then, if at least one pointer is not valid,
> try to liberate the allocated memory without verifying of every
> particular pointer.
> src/pkcs15init/pkcs15-rtecp.c +529
> src/pkcs15init/pkcs15-rtecp.c +542
> src/libopensc/card-rutoken.c +1143
> ...
What do you mean by "quiet dangerous to regroup the allocations"?
src/pkcs15init/pkcs15-rtecp.c:
496: sc_rtecp_genkey_data_t data;
...
523:data.u.rsa.modulus = calloc(1, data.u.rsa.modulus_len);
524:data.u.rsa.exponent_len = key_info->modulus_length / 8 / 2;
525:data.u.rsa.exponent = calloc(1, data.u.rsa.exponent_len);
526:if (!data.u.rsa.modulus || !data.u.rsa.exponent)
527:{
/* 1. data.u.rsa.modulus == VALID_PTR; data.u.rsa.exponent == NULL */
/* 2. data.u.rsa.modulus == NULL; data.u.rsa.exponent == NULL */
/* 3. data.u.rsa.modulus == NULL; data.u.rsa.exponent == VALID_PTR */
528:free(data.u.rsa.modulus); /* if
data.u.rsa.modulus == NULL then no effect, else free mem */
529:free(data.u.rsa.exponent); if
data.u.rsa.exponent == NULL then no effect, else free mem */
/* data is local variable */
SC_FUNC_RETURN(card->ctx, 0,
SC_ERROR_OUT_OF_MEMORY);
}
http://www.opengroup.org/onlinepubs/7990989775/xsh/calloc.html:
RETURN VALUE
Upon successful completion with both nelem and elsize non-zero, calloc()
returns a pointer to the allocated space. If either nelem or elsize is
0, then either a null pointer or a unique pointer value that can be
successfully passed to free() is returned. Otherwise, it returns a null
pointer and sets errno to indicate the error.
http://www.opengroup.org/onlinepubs/7990989775/xsh/free.html:
DESCRIPTION
If ptr is a null pointer, no action occurs.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Aktiv Co. Aleksey Samsonov wrote: > Viktor TARASOV: >> It's commited ... > > Thanks, but some remarks: > > Potencial memory leaks (see /* */): Thanks for your code revision. I'll be more attentive. Considering the 'SC_ERROR_OUT_OF_MEMORY' error, IMHO, it's quiet dangerous to regroup the allocations, then, if at least one pointer is not valid, try to liberate the allocated memory without verifying of every particular pointer. src/pkcs15init/pkcs15-rtecp.c +529 src/pkcs15init/pkcs15-rtecp.c +542 src/libopensc/card-rutoken.c +1143 ... Kind wishes, -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Viktor TARASOV:
> Aktiv Co. Aleksey Samsonov wrote:
>> Viktor TARASOV:
>>> Hi,
>> Hi
Hi,
>>> Nevertheless, IMHO, it would be nice, for the cryptographic objects (and
>>> maybe for the others)
>>> to have the possibility of some unique ID calculated from the object
>>> itself, as it was discussed in thread:
>>> 'CKA_ID and pkcs15 ID' 05.09.2005 13:34 .
>>>
>>> The idea is to have a choice of method to calculate the ID:
>>> - SHA1 of the modulus (Mozilla style),
>>> - SHA1 of public key (recommended by RFC2459)
>>> - or the actual one byte ID (default).
>>> Then use some additional profile option to indicate the method to be
>>> used.
>>>
>>>
>>> Any objection if I implement it?
>> I think, this is a true idea.
>
> It's commited ...
Thanks, but some remarks:
Potencial memory leaks (see /* */):
1) sc_pkcs15_pubkey_from_prvkey:
579:pubkey = (struct sc_pkcs15_pubkey *) calloc(1, sizeof(struct
sc_pkcs15_pubkey));
...
584:switch (prvkey->algorithm) {
...
595: and 616:arr[ii].dst->data = malloc(arr[ii].src->len);
if (!arr[ii].dst->data)
return SC_ERROR_OUT_OF_MEMORY; /*
free(arr[XX].dst->data); free(pubkey) */
...
627:default:
sc_error(ctx, "Unsupported private key algorithm");
return SC_ERROR_NOT_SUPPORTED; /* free(pubkey) */
...
2) sc_pkcs15_pubkey_from_cert:
615:pubkey = (struct sc_pkcs15_pubkey *) calloc(1, sizeof(struct
sc_pkcs15_pubkey));
...
658:SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, "BIO new memory
buffer error"); /* free(pubkey) */
...
662:SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, "X509 parse error");
/* BIO_free(mem); free(pubkey) */
...
666:SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, "Get public key
error"); /* (if (pkey) free(EVP_PKEY_free(pkey);); X509_free(x);
BIO_free(mem); free(pubkey) */
...
669:pubkey->u.rsa.modulus.data = malloc(pubkey->u.rsa.modulus.len);
pubkey->u.rsa.exponent.len = BN_num_bytes(pkey->pkey.rsa->e);
pubkey->u.rsa.exponent.data =
malloc(pubkey->u.rsa.exponent.len);
if (!pubkey->u.rsa.modulus.data ||
!pubkey->u.rsa.exponent.data)
SC_TEST_RET(ctx, SC_ERROR_OUT_OF_MEMORY, "Cannot
allocate key components"); /* free(pubkey->u.rsa.modulus.data);
free(pubkey->u.rsa.exponent.data); ;EVP_PKEY_free(pkey); X509_free(x);
BIO_free(mem); free(pubkey) */
if (BN_bn2bin(pkey->pkey.rsa->n,
pubkey->u.rsa.modulus.data) != pubkey->u.rsa.modulus.len)
SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, "BN to BIN
conversion error"); /* !!! */
if (BN_bn2bin(pkey->pkey.rsa->e,
pubkey->u.rsa.exponent.data) != pubkey->u.rsa.exponent.len)
SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, "BN to BIN
conversion error"); /* !!! */
Also (style, mix tab/space character):
src/pkcs15init/pkcs15-lib.c:1397
src/pkcs15init/pkcs15-lib.c:1477
src/pkcs15init/pkcs15-lib.c:1393
src/libopensc/pkcs15.h:491: struct sc_pkcs15_pubkey **__out__);
src/libopensc/pkcs15-pubkey.c:655
and:
pkcs15-pubkey.c: In function 'sc_pkcs15_pubkey_from_cert':
pkcs15-pubkey.c:677: warning: comparison between signed and unsigned
pkcs15-pubkey.c:679: warning: comparison between signed and unsigned
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Aktiv Co. Aleksey Samsonov wrote: > Viktor TARASOV: >> Hi, > > Hi > >> Nevertheless, IMHO, it would be nice, for the cryptographic objects (and >> maybe for the others) >> to have the possibility of some unique ID calculated from the object >> itself, as it was discussed in thread: >> 'CKA_ID and pkcs15 ID' 05.09.2005 13:34 . >> >> The idea is to have a choice of method to calculate the ID: >> - SHA1 of the modulus (Mozilla style), >> - SHA1 of public key (recommended by RFC2459) >> - or the actual one byte ID (default). >> Then use some additional profile option to indicate the method to be >> used. >> >> >> Any objection if I implement it? > > I think, this is a true idea. It's commited ... > Furthermore > http://www.opensc-project.org/opensc/browser/trunk/src/pkcs15init/profile.c#L564: > > > idx = id->value[id->len-1]; /* choice file ID */ > it may be a surprise to use. ... probably, a little bit too fast. Thank you. I will explicitly look at the impact on the file index . For me (Oberthur) the files indexes were corrects. By the way, IMHO, file index and ID have to be completely dissociated. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Small bug + possible bug (or by design?)
Martin Paljak wrote: > On 10.11.2009, at 17:02, Mats Andersson wrote: > >> Specific feedback/question about EF(DIR) file usage: It could be useful to >> be able to “by config” inject new AIDs of known applications (i.e. into apps >> in dir.c) which comply with PKCS15 but that uses EF(DIR) to point to app >> (whether it’s multiple apps or just non-standard DF). Something planned? >> Comment? >> > > It would be useful indeed. Especially as there are some extra AID-s already > and this has been asked by people as well. > > When saying 'inject new AIDs', do you mean only the EF(DIR) content, or the real support of the multiple PKCS15 applications -- initialize, erase, destination AID when creating new objects, ... ? AFAIS, actually the 'core' pkcs15init code, as well as card specific pkcs15init part, are not designed for multiple applications, its take into consideration only 'PKCS15-AppDF' . (Also, the pkcs15 tools have no AID argument, framework-pkcs15 is not conscious of multiple applications, .. ) Am I wrong ? -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Small bug + possible bug (or by design?)
Hi. On 10.11.2009, at 17:02, Mats Andersson wrote: > This is in stock opensc-0.11.11. > > Smallish bug: (tried mailing b...@opensc-project.org but it failed) > pkcs15.c:760: > Usage of strstr() inverted (works anyway since it’s || and the contents > of the if() is mostly harmless, it will mostly be entered of course :-)) Thanks for noticing, fixed. > By design? > pkcs15-syn.c:131: > Is it “by design” that if builtin_enabled is true and a list is given > that it still scans ALL emulators, eventhough the config lists only a few? > (specifically is it “by design” that the second if() on line 147 is not > an “else if()”?). My first thought was that this config option was to > specifically only include a few of the builtins (and/or “external”)? No, mistake. Corrected as well in r3819 > Specific feedback/question about EF(DIR) file usage: It could be useful to be > able to “by config” inject new AIDs of known applications (i.e. into apps in > dir.c) which comply with PKCS15 but that uses EF(DIR) to point to app > (whether it’s multiple apps or just non-standard DF). Something planned? > Comment? It would be useful indeed. Especially as there are some extra AID-s already and this has been asked by people as well. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fwd: Small bug + possible bug (or by design?)
Hi, some feedback I got to bugs@, could you have a look? -- Weitergeleitete Nachricht -- Betreff: Small bug + possible bug (or by design?) Datum: Dienstag 10 November 2009 Von: Mats Andersson An: "b...@opensc-project.org" This is in stock opensc-0.11.11. Bug: pkcs15.c:760: Usage of strstr() inverted (works anyway since it's || and the contents of the if() is mostly harmless , it will always be entered of course) pkcs15-syn.c:131: Is it "by design" that if builtin_enabled is true and a list is given that it still scans ALL emulators, eventhough the config lists only a few? (specifically is it "by design" that the second if() on line 147 is not an "else if()"?). Specific feedback about EF(DIR) file usage: It could be useful to be able to "by config" inject new AIDs of known applications (i.e. into apps in dir.c) which comply with PKCS15 but that uses EF(DIR) to point to app (whether it's multiple apps or an "unknown" app). Thanks for a fun project! Cheers, /Mats ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
