JSS on Mac OS X
Hello, I am looking for the jss4.dylib (on mac os x), but I can't find it. I've just found each jss dependencies inside the firefox installation folder. I need to use this library with java and jni. I am new on mac os x development. Is it possible and easy to compile jss sources to generate the dylib file? Many thanks. Best regards, Matthieu -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing GPG public and private keys in NSS
On 28 mar, 15:28, Robert Relyea wrote: > On 03/28/2011 05:32 AM, Superpacko wrote: > > > > > > > > > On 23 mar, 14:40, Robert Relyea wrote: > >> On 03/23/2011 06:24 AM, Superpacko wrote:> Well, so i 've been told that i > >> shuld be able to extract the MPI as > >>> bytes and pass it to NSS since GPG original key format is PEM, i > >>> should be able to use MPIs data as raw bytes. > >> If it's really PEM (which should be a printable string), then you should > >> be able to pull out the Base 64 portion and pass it to the NSS atob > >> routine: > > >> ATOB_ConvertAsciiToItem() > > >> It will return a secItem which has a date and a length. This secitem is > >> DER data. > > >> bob > > >> PEM is an ascii file in which all the data outside specific wrappers: > >> ( - BEGIN x > >> -), > >> (-- END xxx ) > >> are ignored. Inside the wrappers is base 64 encoded binary. Base 64 > >> takes the 27 letters of the alphabet, both upper and lower case, with > >> the 10 digits, plus and / and assigns each a value between 0 and 64. The > >> binary blob is then considered a long binary integer. That integer is > >> converted to base 64 using those printable digits. The encoding used 4 > >> base 64 digits to encode 3 binary bytes (base 64 is 6 bits per value) > > >> The PEM base64 pem data is DER data, so the nss der functions should > >> work for them, once you've decoded the base 64. > > >> bob > > >>> The thing is that the only function i found that takes unsigned char* > >>> as argument is PK11_MakeKEAPubKey, and when i try to encrypt using > >>> that key, i get error 8178 (BAD KEY) > >>> So is there a way to import a public and private key with raw bytes? > >>> so far i've seen that most functions need SECKEYPrivateKeyInfo and > >>> stuff like that. > > Thanks for the help, im going to try to extract this information from > > the key stored in the MPIs. > > Is there a way to import an RSA key from external source that is not > > DER encoded nor KEA? > > Do you mean an RSA public key or an RSA private key? > > bob > > > > > > > > > otherwise im gonna have to build a custom PK11_MakeRSAPubKey to create > > a SECKEYPublicKey from raw bytes, filling the > > modulusItem.data = modulusData; > > modulusItem.len = modulusLen; > > exponentItem.data = exponentData; > > exponentItem.len = exponentLen; > > > with the info from the raw bytes. > > > thanks again! For both, since im gonna have to encrypt and decrypt. By now im strugling with encryption so public key is the priority. Thanks! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing GPG public and private keys in NSS
On 03/28/2011 05:32 AM, Superpacko wrote: > On 23 mar, 14:40, Robert Relyea wrote: >> On 03/23/2011 06:24 AM, Superpacko wrote:> Well, so i 've been told that i >> shuld be able to extract the MPI as >>> bytes and pass it to NSS since GPG original key format is PEM, i >>> should be able to use MPIs data as raw bytes. >> If it's really PEM (which should be a printable string), then you should >> be able to pull out the Base 64 portion and pass it to the NSS atob routine: >> >> ATOB_ConvertAsciiToItem() >> >> It will return a secItem which has a date and a length. This secitem is >> DER data. >> >> bob >> >> PEM is an ascii file in which all the data outside specific wrappers: >> ( - BEGIN x -), >> (-- END xxx ) >> are ignored. Inside the wrappers is base 64 encoded binary. Base 64 >> takes the 27 letters of the alphabet, both upper and lower case, with >> the 10 digits, plus and / and assigns each a value between 0 and 64. The >> binary blob is then considered a long binary integer. That integer is >> converted to base 64 using those printable digits. The encoding used 4 >> base 64 digits to encode 3 binary bytes (base 64 is 6 bits per value) >> >> The PEM base64 pem data is DER data, so the nss der functions should >> work for them, once you've decoded the base 64. >> >> bob >> >> >> >> >> >> >> >>> The thing is that the only function i found that takes unsigned char* >>> as argument is PK11_MakeKEAPubKey, and when i try to encrypt using >>> that key, i get error 8178 (BAD KEY) >>> So is there a way to import a public and private key with raw bytes? >>> so far i've seen that most functions need SECKEYPrivateKeyInfo and >>> stuff like that. > Thanks for the help, im going to try to extract this information from > the key stored in the MPIs. > Is there a way to import an RSA key from external source that is not > DER encoded nor KEA? Do you mean an RSA public key or an RSA private key? bob > otherwise im gonna have to build a custom PK11_MakeRSAPubKey to create > a SECKEYPublicKey from raw bytes, filling the > modulusItem.data = modulusData; > modulusItem.len = modulusLen; > exponentItem.data = exponentData; > exponentItem.len = exponentLen; > > with the info from the raw bytes. > > thanks again! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing GPG public and private keys in NSS
On 23 mar, 14:40, Robert Relyea wrote: > On 03/23/2011 06:24 AM, Superpacko wrote:> Well, so i 've been told that i > shuld be able to extract the MPI as > > bytes and pass it to NSS since GPG original key format is PEM, i > > should be able to use MPIs data as raw bytes. > > If it's really PEM (which should be a printable string), then you should > be able to pull out the Base 64 portion and pass it to the NSS atob routine: > > ATOB_ConvertAsciiToItem() > > It will return a secItem which has a date and a length. This secitem is > DER data. > > bob > > PEM is an ascii file in which all the data outside specific wrappers: > ( - BEGIN x -), > (-- END xxx ) > are ignored. Inside the wrappers is base 64 encoded binary. Base 64 > takes the 27 letters of the alphabet, both upper and lower case, with > the 10 digits, plus and / and assigns each a value between 0 and 64. The > binary blob is then considered a long binary integer. That integer is > converted to base 64 using those printable digits. The encoding used 4 > base 64 digits to encode 3 binary bytes (base 64 is 6 bits per value) > > The PEM base64 pem data is DER data, so the nss der functions should > work for them, once you've decoded the base 64. > > bob > > > > > > > > > The thing is that the only function i found that takes unsigned char* > > as argument is PK11_MakeKEAPubKey, and when i try to encrypt using > > that key, i get error 8178 (BAD KEY) > > So is there a way to import a public and private key with raw bytes? > > so far i've seen that most functions need SECKEYPrivateKeyInfo and > > stuff like that. Thanks for the help, im going to try to extract this information from the key stored in the MPIs. Is there a way to import an RSA key from external source that is not DER encoded nor KEA? otherwise im gonna have to build a custom PK11_MakeRSAPubKey to create a SECKEYPublicKey from raw bytes, filling the modulusItem.data = modulusData; modulusItem.len = modulusLen; exponentItem.data = exponentData; exponentItem.len = exponentLen; with the info from the raw bytes. thanks again! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On Sun, Feb 13, 2011 at 5:20 AM, Eddy Nigg wrote: I can see how DANE could be useful with CA issued certificates. The above is a non-starter (at least for me) and rather dangerous for any third party relying on it. But those are my opinions at least if and until this gets implemented anywhere and I can prove my point. Er, it is no more dangerous than DV, and quite possibly less so. DNSSEC is simply another way of asserting a verifiable chain of signatures. The registrar (acting under ICANN authority) accepts a public key token from the domain owner (which claim it has already authenticated) which can be used to verify the authoritative signature on the DNS responses. This is an order of magnitude more secure than DV alone, as it gets targeted DNS attacks out of the picture, and permits the domain owner to assert his own key without having to give anyone other than ICANN his information or pay anyone other than ICANN for the privilege of operating his system and domain. Remember, the state's subjects are the CA's peers. They aren't simply subjects of the CA, as they have sovereign right to ignore anything that the CA attempts to command or demand. Following from this, if the individual CA has no power, the conglomeration of CAs has no power either. If this were the only mechanism used to authenticate the connection, I would be leery of transacting business. Identity CAs are perfect for telling me who someone is. Identity CAs are not perfect, however, for telling me I can't talk to a site just because that site has decided to keep its owner's state identity hidden. In transactions with the site, a red X should appear on the submit button. If it's clicked, a dialog much like "Hey, you're about to send information to a site which DOES NOT PROVIDE STATE IDENTITY INFORMATION. If you are wronged by the owner or operator of this site, your LEGAL RECOURSE WILL BE LIMITED. Continue?" would be appropriate. DANE will solve one of the main problems with the current Identity CA model: that DV certificates are issued under the same trust anchors as state identity (OV/EV) certificates, with no standardized means of determining if the state identity of the enrollee can be known to legal process. At least with DANE you'll know that you're getting the ICANN-authoritative key for the domain, rather than a minimally-verified DV cert which may or may not have been issued to the correct entity. -Kyle H-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
