Dear Douglas, I've got it. The index is shared but the stacks are different. Many thanks for your help! On Sat, Feb 13, 2021 at 5:28 PM Dmitry Belyavskiy <dbelyavs@xxxxxxxxxx> wrote: > Many thanks! > > Will try. > > On Sat, Feb 13, 2021 at 4:54 PM Douglas E Engert <deengert@xxxxxxxxx> > wrote: > >> >> The last line: >> RSA_set_ex_data(rsa, rsa_idx, k11); >> >> sets the pointer to the allocated k11 structure into the rsa key at index >> rsa_idx >> OpenSSH has allocated an rsa_index, to allow it to store OpenSSH data in >> any rsa key. >> The stack allows different components to also hang their own data on any >> key. >> (Note when the index was allocated, a free routine to free a k11 >> structure was added.) >> >> The rsa_idx is the index into a stack in each RSA structure. >> The stack allows multiple components add data to a key. >> >> Running under a debugger might help show how this works. >> This is one of the hardest features of OpenSSL to understand. >> >> On 2/13/2021 9:37 AM, Dmitry Belyavskiy wrote: >> > Dear Douglas, >> > >> > Sorry, I don't understand how it works. >> > >> > The RSA_get_ex_new_index allocates an index in the internal openssl >> table. This index is a global variable. >> > >> > Then on loading a particular key we use a function pkcs11_rsa_wrap that >> sets a pointer to a pkcs11_key structure identifying that particular key. >> > >> https://github.com/openssh/openssh-portable/blob/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L486-L508 >> > < >> https://github.com/openssh/openssh-portable/blob/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L486-L508 >> > >> > >> > The internal openssl implementation that is used for this purpose uses >> a stack. >> > So basically all the _set_ex_data functions put a pointer to some data >> in stack on position with idx: >> > >> https://github.com/openssl/openssl/blob/c8c6e7438c03b2fc24e7ead460feeaef04911fb4/crypto/ex_data.c#L369-L388 >> > < >> https://github.com/openssl/openssl/blob/c8c6e7438c03b2fc24e7ead460feeaef04911fb4/crypto/ex_data.c#L369-L388 >> > >> > >> > (see the definition of OPENSSL_sk_set for details >> > >> https://github.com/openssl/openssl/blob/c8c6e7438c03b2fc24e7ead460feeaef04911fb4/crypto/stack/stack.c#L392-L399 >> > < >> https://github.com/openssl/openssl/blob/c8c6e7438c03b2fc24e7ead460feeaef04911fb4/crypto/stack/stack.c#L392-L399 >> >) >> > >> > I think, it an easily be checked just by adding a 2nd RSA key to >> regress/agent-pkcs11.sh test >> > >> > On Sat, Feb 13, 2021 at 4:13 PM Douglas E Engert <deengert@xxxxxxxxx >> <mailto:deengert@xxxxxxxxx>> wrote: >> > >> > You are partially right. >> > The rsa_idx, and ec_key_idx should not be set to 0, but should be >> set >> > using RSA_get_ex_new_index() as is done later in: >> > >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L471 >> > < >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L471 >> > >> > >> > rsa_idx = RSA_get_ex_new_index(0, "ssh-pkcs11-rsa", >> > >> > This then allows for multiple components to store data in a key. >> > The index is not of the key, but of extra data that can be stored >> in a key. >> > Thus every key can have its own "ssh-pkcs11-rsa" with different >> data. >> > >> > The ec_key_idx is set in: >> > >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L587 >> > < >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L587 >> > >> > >> > >> > >> https://www.openssl.org/docs/man1.1.1/man3/RSA_get_ex_new_index.html < >> https://www.openssl.org/docs/man1.1.1/man3/RSA_get_ex_new_index.html> >> > and is also in OpenSSL-1.0.2. >> > >> > OpenSC/libp11 examples start here: >> > https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L399 < >> https://github.com/OpenSC/libp11/blob/master/src/p11_rsa.c#L399> >> > >> > https://github.com/OpenSC/libp11/blob/master/src/p11_ec.c#L155 < >> https://github.com/OpenSC/libp11/blob/master/src/p11_ec.c#L155> >> > >> > >> > On 2/13/2021 8:22 AM, Dmitry Belyavskiy wrote: >> > > Dear Douglas, >> > > >> > > Everything is fine with methods. But I'm speaking about the >> variables rsa_idx and ec_key_idx, sorry for being unclear. >> > > They serve as handles in a global OpenSSL table and identify a >> pkcs11_data associated with a particular key, don't they? >> > > >> > > On Sat, Feb 13, 2021 at 3:07 PM Douglas E Engert < >> deengert@xxxxxxxxx <mailto:deengert@xxxxxxxxx> <mailto:deengert@xxxxxxxxx >> <mailto:deengert@xxxxxxxxx>>> wrote: >> > > >> > > These lines are for METHODS, i.e. RSA_METHOD and >> EC_KEY_METHOD. RSA keys can share an RSA_METHOD, >> > > and EC keys can share an EC_KEY_METHOD. A method can be >> copied, for example an OpenSSL engine >> > > for using PKCS11, would then provide the routines in the >> method to not use the default software version >> > > of RSA signature or decrypting operations, but use PKCS11 to >> have these operations done on the token or smart card. >> > > So for RSA keys on the token, all these keys would share a >> copied and modified RSA_METHOD PKCS11 method >> > > where the rsa_idx in these keys is used to point to key >> specific data such as PkCS11 slot and KeyIDs. >> > > >> > > >> > > >> > > On 2/12/2021 10:31 AM, Dmitry Belyavskiy wrote: >> > > > Hello, >> > > > >> > > > Do I correctly understand that there can't be more than >> one key of each >> > > > type of PKCS#11? >> > > > >> > > > The lines >> > > > >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L191-L196 >> > < >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L191-L196 >> > >> > > < >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L191-L196 >> > < >> https://github.com/openssh/openssh-portable/blame/1bb130ed34721d46452529d094d9bbf045607d79/ssh-pkcs11.c#L191-L196 >> >> >> > > > seem to use the global variables for RSA/ECDSA >> pkcs11-related data >> > > > structures. >> > > > >> > > > Many thanks! >> > > > >> > > >> > > -- >> > > >> > > Douglas E. Engert <DEEngert@xxxxxxxxx <mailto: >> DEEngert@xxxxxxxxx> <mailto:DEEngert@xxxxxxxxx <mailto:DEEngert@xxxxxxxxx >> >>> >> > > >> > > _______________________________________________ >> > > openssh-unix-dev mailing list >> > > openssh-unix-dev@xxxxxxxxxxx <mailto: >> openssh-unix-dev@xxxxxxxxxxx> <mailto:openssh-unix-dev@xxxxxxxxxxx >> <mailto:openssh-unix-dev@xxxxxxxxxxx>> >> > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev < >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev> < >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > <https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>> >> > > >> > > >> > > >> > > -- >> > > Dmitry Belyavskiy >> > >> > -- >> > >> > Douglas E. Engert <DEEngert@xxxxxxxxx <mailto: >> DEEngert@xxxxxxxxx>> >> > >> > >> > >> > -- >> > Dmitry Belyavskiy >> >> -- >> >> Douglas E. Engert <DEEngert@xxxxxxxxx> >> >> > > -- > Dmitry Belyavskiy > -- Dmitry Belyavskiy _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
