Robert Relyea wrote > On 07/30/2013 06:37 PM, John wrote: >>> At this point I usually ask, what is it you are trying to do? usually >>> when I see someone trying to import or export keyblobs, they are coding >>> at the wrong level and we should be pushing more of whatever protocol >>> you are running into NSS. >> I'm developing a One Time Password software token and wanting to store >> the >> shared secret in the NSS database. At this point I'm inclined to think >> importing the shared secret using PK11_CreateGenericObject() is probably >> more appropriate, i.e. if I can get it to work. >> >> Can you recommend a better approach? > I would recommend against that. > > Let me get straight exactly what you are trying to do. > > You are taking a key in the clear (which you got from somewhere) and > importing it into softoken. > > Then you are running a derive function on the key to generate the output > you would give to the user (again in the clear)? > This resulting key isn't the also the key you are going to use to seed > the next 'generate key' is it? > Presumably you would also run a derive function on the original key to > 'increment it' or are you passing in some salt as part of the original > derive? > > You can see that why I'm a little reluctant to endorse your course of > action here. What we be best is if you had a means of distributing your > key that didn't involve sending it in the clear (like wrapping it with a > PBE at least). Also, I can see where a OTP needs to get the data to give > to the user (by it's nature it gets send over clear channels). So > extracting that key may make sense, or it may make sense to use the > internal key to to do cryptographic operation on plaintext to hand > derive the output bits of the OTP. In any case if you need to extract > the OTP key, PK11_CreateGenericObject() isn't going to help you, since > the key you want to extract is the user OTP data, which would be the > result of some derive operation. > > bob > > >> >> >> >> -- >> View this message in context: >> http://mozilla.6506.n7.nabble.com/Importing-a-symmetic-key-into-NSS-database-tp286642p286750.html >> Sent from the Mozilla - Cryptography mailing list archive at Nabble.com. > > > > -- > dev-tech-crypto mailing list
> dev-tech-crypto@.mozilla > https://lists.mozilla.org/listinfo/dev-tech-crypto > > smime.p7s (6K) > <http://mozilla.6506.n7.nabble.com/attachment/286891/0/smime.p7s> You're right - the OTP data is intrinsically a HMAC digest, which can be generated using NSS functions so there's no need to export the key. On a related topic, to support event-based OTP we would need to keep track of a counter and increment it each time a code is generated. We could store this counter in a separate sqlite database but would be cleaner, from an application perspective, if we could store it in the NSS database as well. We'd need to be able to extract the counter, increment it and then store it back in the NSS database. Is this possible? Regards, John -- View this message in context: http://mozilla.6506.n7.nabble.com/Importing-a-symmetic-key-into-NSS-database-tp286642p286974.html Sent from the Mozilla - Cryptography mailing list archive at Nabble.com. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
