Re: Diffie algorithm in openssl: and Java
Thanks matt for looking at this. below are the details
json from C with openSSL
{
prime:
B01DBDE7823A696F13EEFDE810DF2A010ED8BA919186029BEECCF2F0454CE85CA3E3FFD0EB3A578F80C28930AD98559D57605E37BFE2B1BD3C6D6C7657384F4DDFF45D57C59EF2DEADAF7605A1EB36A5D5007162F026E5AE161F489C8C79A5AD10C40FC7B914CDD85EE8A493307EE183194655D5190A3B7D8B45036E56E0C653,
basegenerator: 2,
size: 1024,
publickey:
829DE389D7731F6CB1C92B92965E119FFCBAE433C5B19B5C262623FD5EA6F2D53EFAD3195372B7C746DB376C3739CBC03BE7614183F658E059F02FF8C463051E3684424BE8F3F96353275201D8B8154DED3A5152DD04EBD55C0EC20544F975EEEB703B3085C174C761712AC83EACF8507895571E1F076876F26162504D75EF11
}
JSON with JAVA
{
prime:
178011905478542266528237562450159990145232156369120674273274450314442865788737020770612695252123463079567156784778466449970650770920727857050009668388144034129745221171818506047231150039301079959358067395348717066319802262019714966524135060945913707594956514672855690606794135837542707371727429551343320695239,
basegenerator:
1740682075324020951858119801235234365386044907945613509784958310405999534884558231478515974089409507253077970949157594923683005742524387610370844734671801488761181030830437549851909834726015504946913294880833954923138536164648264460849230407872181895056496097769368017749273708962006689187956744210730,
size: 1024,
publickey:
154098060632197825972569070553594673213907981120204558893455132154488920498286340180930009617674527453058248409146259055129616519883338912429359077804301589391083095780370584174889589223725092053310001148182587778315708960959816212553890780658697750126252666385136330617189340099488509957293788029153796583284280546893194823052732368554200517384648060949814219845513312636361799960550824305241776726569729968117653644039260346804354135691237238964153781814300021332541328282477027772784043832083697573459487287571520026609334964134811373470209956613009283464376018849091639198208244682804180475479662224652170610412421382256896232908714139611606796633319949985382724877107919957408909942743414340389890006834786464852247662337830546584844189278383274479199021252090407963572739286575933788241737975537671923484277171204499262529715278092506505239752566691287452373502190399117732855968397767896906732126573639005461407592315315318920060328019073971670048355762952267750188451524151795498747866082848788789357672209810743252483
}
Kindly let me know if you need anything else. even I can share my
implementation (both Java and C)
Regards,
Azhar
On Sun, Mar 17, 2013 at 1:10 PM, Matt Caswell fr...@baggins.org wrote:
On 16 March 2013 22:29, azhar jodatti azhar...@gmail.com wrote:
Matt,
No reason as such for using low level interface.I just want to get it
done. Do you see any issues with low level interface? or any issues with my
code?
In addition, the server and client works over REST API's, hence I am
using JSON format to pass the parameter over the wire.
The low-level interface will *work*, its just *better* to use the high
level interface. The high level interface is less tightly coupled to the
specifics of any one particular algorithm (you would be able to reuse much
of your code if you needed to use ECDH instead of DH at some point in the
future). In general the high level interface also hides much of the
complexity of working with specific algorithms.
Can you supply a sample of the JSON format that you are using to pass
parameters and public keys?
Matt
Re: Diffie algorithm in openssl: and Java
1) The C version is in hex while the java version is in decimal. Is this
intentional? When you are reading in the values are reading them correctly
(i.e. as hex or as decimal as required)
Yes. it was intentional. I am taking care of this.
2) Is this sample from the *same* key exchange? The parameters are
different which are obviously going to cause it to fail.
When I run both programs it calculates the params (p,g,pk) every time on
execution . that's the reason both key values are different. That won't
make any such difference :) right?
3) Its not actually necessary to pass the full parameters every time you
exchange keys. This can be agreed up front, e.g. RF5114 defines a set of
standard well known parameters which can be used off the shelf. OpenSSL
has built-in support for these.
I need to look into this. Do you mean the hard coded prime and base
generator numbers at client and server? how about public key?
Regards,
Azhar
On Mon, Mar 18, 2013 at 3:22 PM, Matt Caswell fr...@baggins.org wrote:
On 18 March 2013 06:26, azhar jodatti azhar...@gmail.com wrote:
Thanks matt for looking at this. below are the details
json from C with openSSL
{
prime:
B01DBDE7823A696F13EEFDE810DF2A010ED8BA919186029BEECCF2F0454CE85CA3E3FFD0EB3A578F80C28930AD98559D57605E37BFE2B1BD3C6D6C7657384F4DDFF45D57C59EF2DEADAF7605A1EB36A5D5007162F026E5AE161F489C8C79A5AD10C40FC7B914CDD85EE8A493307EE183194655D5190A3B7D8B45036E56E0C653,
basegenerator: 2,
size: 1024,
publickey:
829DE389D7731F6CB1C92B92965E119FFCBAE433C5B19B5C262623FD5EA6F2D53EFAD3195372B7C746DB376C3739CBC03BE7614183F658E059F02FF8C463051E3684424BE8F3F96353275201D8B8154DED3A5152DD04EBD55C0EC20544F975EEEB703B3085C174C761712AC83EACF8507895571E1F076876F26162504D75EF11
}
JSON with JAVA
{
prime:
178011905478542266528237562450159990145232156369120674273274450314442865788737020770612695252123463079567156784778466449970650770920727857050009668388144034129745221171818506047231150039301079959358067395348717066319802262019714966524135060945913707594956514672855690606794135837542707371727429551343320695239,
basegenerator:
1740682075324020951858119801235234365386044907945613509784958310405999534884558231478515974089409507253077970949157594923683005742524387610370844734671801488761181030830437549851909834726015504946913294880833954923138536164648264460849230407872181895056496097769368017749273708962006689187956744210730,
size: 1024,
publickey:
154098060632197825972569070553594673213907981120204558893455132154488920498286340180930009617674527453058248409146259055129616519883338912429359077804301589391083095780370584174889589223725092053310001148182587778315708960959816212553890780658697750126252666385136330617189340099488509957293788029153796583284280546893194823052732368554200517384648060949814219845513312636361799960550824305241776726569729968117653644039260346804354135691237238964153781814300021332541328282477027772784043832083697573459487287571520026609334964134811373470209956613009283464376018849091639198208244682804180475479662224652170610412421382256896232908714139611606796633319949985382724877107919957408909942743414340389890006834786464852247662337830546584844189278383274479199021252090407963572739286575933788241737975537671923484277171204499262529715278092506505239752566691287452373502190399117732855968397767896906732126573639005461407592315315318920060328019073971670048355762952267750188451524151795498747866082848788789357672209810743252483
}
Kindly let me know if you need anything else. even I can share my
implementation (both Java and C)
So a few things strike me about this:
1) The C version is in hex while the java version is in decimal. Is this
intentional? When you are reading in the values are reading them correctly
(i.e. as hex or as decimal as required)
2) Is this sample from the *same* key exchange? The parameters are
different which are obviously going to cause it to fail.
3) Its not actually necessary to pass the full parameters every time you
exchange keys. This can be agreed up front, e.g. RF5114 defines a set of
standard well known parameters which can be used off the shelf. OpenSSL
has built-in support for these.
Matt
Re: [openssl-users] Validation error on generated csr
Hi Erwann
What you have to do it hash your data, prepare an X509_SIG object, set
its algor to SHA1 (with NULL parameters), and fill the digest part
with your hash result. Then transform it into DER, and sign it with
CKM_RSA_PKCS mechanism.
Thanks a lot for the explanation. However, I can't find any
documentation about how to setup this X509_SIG object and then transfer
it into DER. The structure seems to look as follows:
typedef struct X509_sig_st
{
X509_ALGOR *algor;
ASN1_OCTET_STRING *digest;
} X509_SIG;
EVP_DigestFinal(ctx,buf,buf_len);
gives me a character buffer buf, containing the digest, but I seem to
have to encode this to ASN1_OCTET_STRING.
Can anybody quickly tell me the required functions or point me to an
example of how to do this?
Kind regards
Tim
On 03/15/2013 03:10 PM, Erwann Abalea wrote:
Bonjour,
Le 15/03/2013 14:07, Tim Tassonis a écrit :
Hi
I am trying to generate a csr in a c program by having the signing
part done by pkcs11 calls, and while I get no errors, the resulting
csr fails upon validation:
$ openssl req -verify -in wltx.csr
verify failure
2948:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too
long:.\cry
pto\asn1\asn1_lib.c:150:
2948:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object
header:.\c
rypto\asn1\tasn_dec.c:1306:
2948:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested
asn1 error:.\
crypto\asn1\tasn_dec.c:381:Type=X509_SIG
2948:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:.\crypto\asn
1\a_verify.c:215:
-BEGIN CERTIFICATE REQUEST-
MIICvjCCAagCAQAwezELMAkGA1UEBhMCQ0gxEzARBgNVBAcTClJhcHBlcnN3aWwx
[...]
BBXO9brFuXld13VuE2xg+VnJ8vo3L7/SCC5ufEJaeSUOvQ==
-END CERTIFICATE REQUEST-
What is RSA signed is the direct SHA1 of the request, without the X509
encapsulation.
Below is the function that generates the csr, it always succeds, but
as mentioned, the csr is still invalid
char *gen_csr(char *key_name, struct s_ekva **key_attrs)
{
[...]
inl=ASN1_item_i2d((void
*)req-req_info,buf_in,ASN1_ITEM_rptr(X509_REQ_INFO));
p = buf_in;
outl=EVP_PKEY_size(pkey);
buf_out = malloc(outl);
sign_mechanism.mechanism = CKM_SHA1_RSA_PKCS;
sign_mechanism.pParameter = NULL;
sign_mechanism.ulParameterLen = 0;
rv = p11-C_SignInit(session, sign_mechanism, prvkey);
if (rv != CKR_OK) {
return NULL;
}
rv = p11-C_Sign(session, p,inl, buf_out, outl);
if (rv != CKR_OK) {
return NULL;
}
You're feeding the PKCS#11 library with the request (the part to be
signed), while specifying a CKM_SHA1_RSA_PKCS mechanism. The library
doesn't know it's signing a CSR, and will SHA1 hash the data and RSA
sign it.
What you have to do it hash your data, prepare an X509_SIG object, set
its algor to SHA1 (with NULL parameters), and fill the digest part
with your hash result. Then transform it into DER, and sign it with
CKM_RSA_PKCS mechanism.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Diffie algorithm in openssl: and Java
On 18 March 2013 12:15, azhar jodatti azhar...@gmail.com wrote: 2) Is this sample from the *same* key exchange? The parameters are different which are obviously going to cause it to fail. When I run both programs it calculates the params (p,g,pk) every time on execution . that's the reason both key values are different. That won't make any such difference :) right? The parameters p, q and g need to be the same on both sides of the exchange. The values for this can be agreed in advance. You do not need to calculate them every time. If the two parties in the exchange are using different parameters then it will not work. Each side will have different private keys, and hence different public keys. You *can* generate the parameters every time - it will work as long as both sides are using the same p, q and g values - but there is no reason to do so. I also just noticed that in your JSON sample there is only one prime number provided. There are in fact two required: p and q. 3) Its not actually necessary to pass the full parameters every time you exchange keys. This can be agreed up front, e.g. RF5114 defines a set of standard well known parameters which can be used off the shelf. OpenSSL has built-in support for these. I need to look into this. Do you mean the hard coded prime and base generator numbers at client and server? how about public key? The values p, q and g can be hard coded at client and server. The private/public keys can also be static on both sides of the exchange - but if you do so then bear in mind that the agreed on secret will be the same every time. More likely you will want to use ephemeral mode - one side (usually the server) can have a static private/public key, whilst the client will use a new one every time. This will ensure that a new secret is agreed each time. One other point to make here is that it looks very much like you are designing your own protocol rather than implementing a well defined one. This is fraught with security risksit is very easy to make a mistake - and is generally a bad idea. Use standardised approaches where ever possible. In particular note that the diffie-hellman implementation in use here provides a raw shared secret at the end. Standardised protocols normally define a process for turning that shared secret into something which can be used as a key (typically by passing the secret, along with other data through some message digest). E.g. see RFC 2631 Matt
libcrypto.a linking problem?
I'm unable to build Git 1.8.1.3 with libcrypto. I've compiled and built OpenSSL with the same LDFLAGS and CPPFLAGS as below. I also have a `/etc/ld.so.conf.d/sandbox.conf` file which loads `/sandbox/builds/lib` as a library path for LD_LIBRARY_PATH. $ uname -a Linux kosuna 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 athlon i686 GNU/Linux $ LDFLAGS=-L/sandbox/builds/lib CPPFLAGS=-I/sandbox/builds/include ./configure --prefix=$PREFIX [...] $ make /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': dso_dlfcn.c:(.text+0x1b): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x31): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x3b): undefined reference to `dlclose' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': dso_dlfcn.c:(.text+0x3c1): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x4a0): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': dso_dlfcn.c:(.text+0x521): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x600): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': dso_dlfcn.c:(.text+0x678): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x6e8): undefined reference to `dlclose' dso_dlfcn.c:(.text+0x72d): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': dso_dlfcn.c:(.text+0x7e1): undefined reference to `dladdr' dso_dlfcn.c:(.text+0x849): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': dso_dlfcn.c:(.text+0x8aa): undefined reference to `dlclose' collect2: error: ld returned 1 exit status make: *** [git-imap-send] Error 1 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
Hello kapetr, I have successfully time-stamped with TSA server https://www.postsignum.cz/DEMOTSA/TSS_user/; (u: demoTSA, p: demoTSA2010), using 2 Time-stamp clients: 1. Adobe Reader 10.1.3 2. Serbian Post Time-stamp client: http://www.ca.posta.rs/download/Time-Stamp%20klijent%20aplikacija%20Poste%20v1.2.zip PostSignum TSA server is Thales (nCipher). Thales (nCipher) time stamp server can be configured to choose three locations where TAC (Time Attribute Certificate) V2 attribute certificate will be stored: 1. CertificateChoices1 with ESSCertID (compatibility mode) The Time Attribute Certificate is encoded in the CHOICE [1] field in the CertificateChoices and the SHA-1 hash of the TAC is stored in the ESSCertID. 2. CertificateChoices2 with ESSCertID (RFC3369 3852) This option puts the Time Attribute certificate into the CHOICE [2] field in the CertificateChoices and sets the CMS version of the Time Stamp Token to 4 (because a V2 attribute certificate is present). Note: Adobe Acrobat time-stamping support rejects CMS V4 as a bad version number. If you are using Adobe Acrobat time-stamping, Thales recommend continuing to use an older option that is Acrobat-compatible until a fix from Adobe is made available. 3. SignerAttribute (RFC3126 ETSI) This option puts the entire TAC into a signed attribute. In this case, the hash of the TAC is not included in the ESSCertID because it would be redundant and RFC3126 requires it not to be present. This option also adds the SigningTime signed attribute (redundant but required by the RFC) and the SignaturePolicyId signed attribute. The policy is NULL because a time-stamp token already must include a PolicyID in the TSTInfo. My conclusion is that PostSignum TSA server is configured with the first of the above options 1. CertificateChoices1 with ESSCertID (compatibility mode). When Thales (nCipher) time-stamp server is configured that way, OpenSSL is unable to read TSA response. For example: --- C:\Program Files\OpenSSL-Win32\binopenssl ts -reply -in postsignum-Response.tsr -text Using configuration from C:\Program Files\OpenSSL-Win32\bin\openssl.cfg 608:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:.\crypto\asn 1\tasn_dec.c:1320: 608:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:.\c rypto\asn1\tasn_dec.c:382:Type=X509 608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 er ror:.\crypto\asn1\tasn_dec.c:712:Field=cert, Type=PKCS7_SIGNED 608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 er ror:.\crypto\asn1\tasn_dec.c:752: 608:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error :.\crypto\asn1\tasn_dec.c:580:Field=d.sign, Type=PKCS7 608:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 er ror:.\crypto\asn1\tasn_dec.c:752:Field=token, Type=TS_RESP C:\Program Files\OpenSSL-Win32\bin --- Administrator of PostSignum TSA can solve the problem with OpenSSL in 2 ways: 1. To configure TAC: 3. SignerAttribute (RFC3126 ETSI), or 2. Exclude TAC from certificate list. He can use this option to support time-stamp client software that cannot decode the TAC. This option is required if you must support SUN jarsigner. SUN Jarsigner cannot decode the TAC and cannot support time-stamp tokens that include the TAC in the certificate list. Useful link: http://www.ietf.org/mail-archive/web/pkix/current/msg14787.html Dragan -- View this message in context: http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tp43128p44380.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Validation error on generated csr
On Mon, Mar 18, 2013, Tim Tassonis wrote:
Hi Erwann
What you have to do it hash your data, prepare an X509_SIG object, set
its algor to SHA1 (with NULL parameters), and fill the digest part
with your hash result. Then transform it into DER, and sign it with
CKM_RSA_PKCS mechanism.
Thanks a lot for the explanation. However, I can't find any
documentation about how to setup this X509_SIG object and then
transfer it into DER. The structure seems to look as follows:
typedef struct X509_sig_st
{
X509_ALGOR *algor;
ASN1_OCTET_STRING *digest;
} X509_SIG;
EVP_DigestFinal(ctx,buf,buf_len);
gives me a character buffer buf, containing the digest, but I seem
to have to encode this to ASN1_OCTET_STRING.
Can anybody quickly tell me the required functions or point me to an
example of how to do this?
Well you can use the ASN1 code for this but for a single digest you can just
manually prepend the necessary encoding. The fips code does this to avoid
having to include the ASN1 module. The relavant data is in
fips/rsa/fips_rsa_sign.c in any FIPS branch (and the master branch).
For example for SHA1 it is:
static const unsigned char sha1_bin[] = {
0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a,
0x05,
0x00, 0x04, 0x14
};
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Validation error on generated csr
Hi Stephen
Thanks a lot, that did the trick, the verify now returns ok.
Kind regards
Tim
On 03/18/2013 02:26 PM, Dr. Stephen Henson wrote:
On Mon, Mar 18, 2013, Tim Tassonis wrote:
Hi Erwann
What you have to do it hash your data, prepare an X509_SIG object, set
its algor to SHA1 (with NULL parameters), and fill the digest part
with your hash result. Then transform it into DER, and sign it with
CKM_RSA_PKCS mechanism.
Thanks a lot for the explanation. However, I can't find any
documentation about how to setup this X509_SIG object and then
transfer it into DER. The structure seems to look as follows:
typedef struct X509_sig_st
{
X509_ALGOR *algor;
ASN1_OCTET_STRING *digest;
} X509_SIG;
EVP_DigestFinal(ctx,buf,buf_len);
gives me a character buffer buf, containing the digest, but I seem
to have to encode this to ASN1_OCTET_STRING.
Can anybody quickly tell me the required functions or point me to an
example of how to do this?
Well you can use the ASN1 code for this but for a single digest you can just
manually prepend the necessary encoding. The fips code does this to avoid
having to include the ASN1 module. The relavant data is in
fips/rsa/fips_rsa_sign.c in any FIPS branch (and the master branch).
For example for SHA1 it is:
static const unsigned char sha1_bin[] = {
0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a,
0x05,
0x00, 0x04, 0x14
};
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Fwd: Diffie algorithm in openssl: and Java
On 18 March 2013 12:15, azhar jodatti azhar...@gmail.com wrote: 2) Is this sample from the *same* key exchange? The parameters are different which are obviously going to cause it to fail. When I run both programs it calculates the params (p,g,pk) every time on execution . that's the reason both key values are different. That won't make any such difference :) right? The parameters p, q and g need to be the same on both sides of the exchange. The values for this can be agreed in advance. You do not need to calculate them every time. If the two parties in the exchange are using different parameters then it will not work. Each side will have different private keys, and hence different public keys. . p,q and g are same at both the end. let me tell how i am doing. I am generating p,g and q at client. then I am generating private and public key with these params. I am sending these p,g,q and public key to server and hence server using same p,g and q to generate its private and public key. server generates secret key with client public key and returns its public key. client in turn use the server public key to generated its secret key. I am generating parameter when user logs in and stays till user logout. next time when he logs in the same procedure will happen. You *can* generate the parameters every time - it will work as long as both sides are using the same p, q and g values - but there is no reason to do so I don't think i understood you completely here. but I am ok by generating parameters every time as long as it works :) I also just noticed that in your JSON sample there is only one prime number provided. There are in fact two required: p and q. well, I think other prime number is g and not q. other prime number is base generator i.e g in above JSON sample. 3) Its not actually necessary to pass the full parameters every time you exchange keys. This can be agreed up front, e.g. RF5114 defines a set of standard well known parameters which can be used off the shelf. OpenSSL has built-in support for these. I need to look into this. Do you mean the hard coded prime and base generator numbers at client and server? how about public key? The values p, q and g can be hard coded at client and server. The private/public keys can also be static on both sides of the exchange - but if you do so then bear in mind that the agreed on secret will be the same every time. More likely you will want to use ephemeral mode - one side (usually the server) can have a static private/public key, whilst the client will use a new one every time. This will ensure that a new secret is agreed each time. Yes, I would love to see at least this working. I will try this today, however I still prefer dynamic values over static. :) ;) One other point to make here is that it looks very much like you are designing your own protocol rather than implementing a well defined one. This is fraught with security risksit is very easy to make a mistake - and is generally a bad idea. Use standardised approaches where ever possible. In particular note that the diffie-hellman implementation in use here provides a raw shared secret at the end. Standardised protocols normally define a process for turning that shared secret into something which can be used as a key (typically by passing the secret, along with other data through some message digest). E.g. see RFC 2631 I don't feel i am trying to design my own protocol. at least it won't look so for me :) I want to use symmetric key encryption and for that I need a same secret key at both the ends at run time. Who else does this better than Diffie Hellman? :) :) Matt
Re: Diffie algorithm in openssl: and Java
On 18 March 2013 15:05, azhar jodatti azhar...@gmail.com wrote: I also just noticed that in your JSON sample there is only one prime number provided. There are in fact two required: p and q. well, I think other prime number is g and not q. other prime number is base generator i.e g in above JSON sample. No, g is the generator and I don't believe there is a requirement for it to be prime. In fact your Java version of your JSON has a generator which is clearly NOT prime - it is an even number. You are missing a parameter from your JSON. One other point to make here is that it looks very much like you are designing your own protocol rather than implementing a well defined one. This is fraught with security risksit is very easy to make a mistake - and is generally a bad idea. Use standardised approaches where ever possible. In particular note that the diffie-hellman implementation in use here provides a raw shared secret at the end. Standardised protocols normally define a process for turning that shared secret into something which can be used as a key (typically by passing the secret, along with other data through some message digest). E.g. see RFC 2631 I don't feel i am trying to design my own protocol. at least it won't look so for me :) I want to use symmetric key encryption and for that I need a same secret key at both the ends at run time. Who else does this better than Diffie Hellman? :) :) Diffie Hellman is the algorithm, the protocol is about how you implement and use that algorithm, e.g. taking a ridiculous example you can use the diffie-hellman algorithm and then make it insecure by transmitting the private key in the clear in the protocol!! See the top answer here: http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology Also: http://www.cse.chalmers.se/edu/year/2012/course/TDA601/Project/Presentations06/9.pdf And: Cryptographic protocols and algorithms are difficult to get right, so do not create your own http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/crypto.html Matt
Re: openssl-user - UTF8 characters in configuration file
Viktor and others, thanks for the tips. I found that by using OpenSSL 1.0.1e I've been able to create the UTF8 format fields, such as: 71:d=5 hl=2 l= 3 prim: OBJECT:commonName 76:d=5 hl=2 l= 6 prim: UTF8STRING:Róót However, creating the subjectAltName is not following the same pattern. In the root_dir_sect I've assigned CN (and a custom OID) to the same value I've assigned to commonName in root_ca_distinguished_name: [ new_oid_section ] myOIDSN = myOIDLongName, 1.2.3.4 [ root_ca_distinguished_name ] countryName = US stateOrProvinceName = MA commonName = Róót emailAddress= r...@abc.com organizationName= abc [ root_ca_extensions ] basicConstraints= CA:true subjectAltName = email:copy,URI: http://xyz.com.test/,dirName:root_dir_sect# [ root_dir_sect ] C = us O = abc OU = orgUnit CN = Róót 1.2.3.4 = Róót Using an ASN1 parsing tool I found that the commonName in Subject contains the C3B3 (accented o) I expected. However within subjectAltName, the dirName field the value is expanded to C3+83C2+B3 for each occurrence of accented o. CN=Róót, 2.3.4=Róót I must have also assigned the custom OID incorrectly as the preceding 1. is truncated. Any comments are greatly appreciated. Thanks John Rasmussen IBM DataPower From: Viktor Dukhovni openssl-us...@dukhovni.org To: openssl-users@openssl.org, Date: 03/15/2013 12:06 PM Subject:Re: openssl-user - UTF8 characters in configuration file Sent by:owner-openssl-us...@openssl.org On Fri, Mar 15, 2013 at 09:44:13AM +0100, Zbyn?k Krej??k wrote: I tried this some 2yrs ago what seemed to work (at least wins showed the strings in cert correctly) in [ req ] ... distinguished_name = req_distinguished_name attributes = req_attributes string_mask = utf8only utf8 = yes FWIW with OpenSSL 1.0.1e just string_mask is sufficient, but utf8 is neither sufficient nor necessary. $ cat foo.cnf [ req ] distinguished_name = dn prompt = no string_mask = utf8only [ dn ] countryName = US stateOrProvinceName = New York localityName= New York organizationName= Example Corp commonName = mail.example.com [ v3_req ] extendedKeyUsage= serverAuth, clientAuth $ openssl req -new -config foo.cnf -reqexts v3_req -key key.pem | openssl asn1parse 0:d=0 hl=4 l= 335 cons: SEQUENCE 4:d=1 hl=3 l= 247 cons: SEQUENCE 7:d=2 hl=2 l= 1 prim: INTEGER :00 10:d=2 hl=2 l= 101 cons: SEQUENCE 12:d=3 hl=2 l= 11 cons: SET 14:d=4 hl=2 l= 9 cons: SEQUENCE 16:d=5 hl=2 l= 3 prim: OBJECT:countryName 21:d=5 hl=2 l= 2 prim: PRINTABLESTRING :US 25:d=3 hl=2 l= 17 cons: SET 27:d=4 hl=2 l= 15 cons: SEQUENCE 29:d=5 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 34:d=5 hl=2 l= 8 prim: UTF8STRING:New York 44:d=3 hl=2 l= 17 cons: SET 46:d=4 hl=2 l= 15 cons: SEQUENCE 48:d=5 hl=2 l= 3 prim: OBJECT:localityName 53:d=5 hl=2 l= 8 prim: UTF8STRING:New York 63:d=3 hl=2 l= 21 cons: SET 65:d=4 hl=2 l= 19 cons: SEQUENCE 67:d=5 hl=2 l= 3 prim: OBJECT:organizationName 72:d=5 hl=2 l= 12 prim: UTF8STRING:Example Corp 86:d=3 hl=2 l= 25 cons: SET 88:d=4 hl=2 l= 23 cons: SEQUENCE 90:d=5 hl=2 l= 3 prim: OBJECT:commonName 95:d=5 hl=2 l= 16 prim: UTF8STRING:mail.example.com ... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Diffie algorithm in openssl: and Java
From: owner-openssl-us...@openssl.org On Behalf Of azhar jodatti Sent: Saturday, 16 March, 2013 14:00 I am working on application which has android and iPhone client. Both the client talk to my server which is written in JAVA. I am using JCE implementation of DH algorithm and X509EncodedkeySpec for generating public and private key. code below X509EncodedKeySpec x509Spec = new X509EncodedKeySpec(this.clientPublicKey); PublicKey pk = kf.generatePublic(x509Spec); (I assume this is on the server, kf is a KeyFactory.getInstance(DH) and this.clientPublicKey contains client DH public key in X509-ki form.) In spite of the name, that doesn't generate a key, it only converts it from an external form (X509) to an internal form JCE can use directly. DH key(pair) generation is done with a KeyPairGenerator.getInstance(DH). It can use parameters from several sources; which are you using? for iPhone client I wrote a C programme which makes use of openSSl implementation of DH algorithm. The problem I am facing is when I generate DH params (prime,generator,pulickey) at client and pass them to server to calculate server's public and secret key, my server (JAVA) throws invalidKeySpecification exception. below are steps. //client is DH *client. //also tried with 1024 bits and DH_GENERATOR_5 DH_generate_parameters_ex(client,512,DH_GENERATOR_2,NULL); You don't need to generate new parameters each time, as I said before. And for secure sizes it's usually rather costly/slow to do so. If you do generate new parameters, the server side Java *must* use parameters sent by the client as input to server KeyPairGenerator. OTOH DH-512 is almost certainly not secure. I don't understand all the math, but the authorities I trust say that discrete-log (DH) is only a few bits better than factoring (RSA), and RSA-512 is fallen. 2. then generating DH public and private key DH_generate_key(client) That is actual key generation, like KeyPairGenerator.generate. when I pass these (prime,generator,publickey ) generated keys to server which is written in JAVA , It won't work. server (JAVA) throws invalidKeySpecification exception. Then you're not doing what I described. See next. One more point I would like to mention here is, When I use DHPublicKeySpec instead of X509EncodedKeySpec at server (JAVA) it won't throw invalidKeySpecification exception. snip rest Those are different data formats. X509EncodedKeySpec is correct if you have a DH public key (or other public key) *in X.509 SubjectPublicKeyInfo format* which Openssl calls PUBKEY and can do with no additional code. In another email you show that you are using a JSON format with separate fields (which you didn't mention before), which contains the same data as X.509-keyinfo but is not even remotely the same format, so for your format yes DHPublicKeySpec is correct. See other response for more about parameters and key values. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Diffie algorithm in openssl: and Java
From: owner-openssl-us...@openssl.org On Behalf Of Matt Caswell Sent: Monday, 18 March, 2013 09:17 On 18 March 2013 12:15, azhar jodatti azhar...@gmail.com wrote: 2) Is this sample from the *same* key exchange? The parameters are different which are obviously going to cause it to fail. When I run both programs it calculates the params (p,g,pk) every time on execution . that's the reason both key values are different. That won't make any such difference :) right? The parameters p, q and g need to be the same on both sides of the exchange. The values for this can be agreed in advance. You do not need to calculate them every time. And I would advise against doing so, because generating parameters is costly. But see below about q. If the two parties in the exchange are using different parameters then it will not work. Each side will have different private keys, and hence different public keys. You *can* generate the parameters every time - it will work as long as both sides are using the same p, q and g values - but there is no reason to do so. This isn't clear. Each side chooses keys (x,y) using the parameters, which as you say must be the same. With parameters the same, the *key* values if chosen properly (randomly) will be different. If the parameters are (wrongly) different, the key values will overwhelmingly be chosen different also, but even if they are accidentally the same or x is forced the same, exchange doesn't work. And see next about q. I also just noticed that in your JSON sample there is only one prime number provided. There are in fact two required: p and q. No. *DSA* uses p,q,g. DH requires p,g which effectively determines q, but DH computation doesn't use q and standard formats don't have it. DH can use l which is the *size* of q thus the (max) entropy of the agreement. It is sometimes convenient to use DSA parameters as DH parameters by ignoring q except optionally its size. And possibly relevant here, the standard Suncle JCE provider actually uses DSA paramgen for DH and thus imposes the DSA size restrictions on DH -- 512 to 1024 in steps of 64 -- although they aren't required by any standard I know of. I don't recall if JCE also restricts *existing* (received) params; I'll test when I have some time. I do recall you can get around this by using BouncyCastle instead. But just using 1024 is easy and fine. 3) Its not actually necessary to pass the full parameters every time you exchange keys. This can be agreed up front, e.g. RF5114 defines a set of standard well known parameters which can be used off the shelf. OpenSSL has built-in support for these. Or 2412 (Oakley) or others. There are actually two issues here: - you don't need to *generate* new parameters every time. If you do, you must send them. Sending in standard X509-ki format is often the easiest way (and JCE does by default) but not the only way. - if you reuse parameters, you don't *need* to send them, but it can be useful if you do because both parties can check they agree and something hasn't gotten misconfigured or out of sync. I need to look into this. Do you mean the hard coded prime and base generator numbers at client and server? how about public key? The values p, q and g can be hard coded at client and server. The private/public keys can also be static on both sides of the exchange - but if you do so then bear in mind that the agreed on secret will be the same every time. More likely you will want to use ephemeral mode snip I would suggest configured rather than hard-coded -- but the important point is fixed/static/long-term versus new each time. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_OP_NO_TLSv1_1 doesn't seem to disable TLS 1.1 and above protocols on Openssl 1.0.1e
Hi, The application I am working on should not support TLS 1.1 and above protocols. I am using SSL_CTX_set_options( ctx, SSL_OP_NO_TLSv1_1); to disable the same after creating the SSL context. But it doesn't seem to disable the TLS1.1 and TLS1.2 protocols Code Snippet: SSL_CTX *c = SSL_CTX_new(SSLv23_method()); SSL_CTX_set_options( c, SSL_OP_NO_TLSv1_1); Can someone please let me know if I am missing anything? Santhosh
Re: Diffie algorithm in openssl: and Java
On 18 March 2013 21:02, Dave Thompson dthomp...@prinpay.com wrote:
I also just noticed that in your JSON sample there is only one
prime number provided. There are in fact two required: p and q.
No. *DSA* uses p,q,g. DH requires p,g which effectively determines
q, but DH computation doesn't use q and standard formats don't have
it. DH can use l which is the *size* of q thus the (max) entropy
of the agreement. It is sometimes convenient to use DSA parameters
as DH parameters by ignoring q except optionally its size.
Not entirely correct. I've just been digging into this when I saw your
email. PKCS 3 does not use q for DH:
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL }
However, the newer X9.42 DOES require q to be present:
DomainParameters ::= Sequence {
p INTEGER, -- odd prime, p = jq+1
g INTEGER, -- generator, g^q = 1 mod p
q INTEGER, -- prime factor of p-1
j INTEGER OPTIONAL, -- cofactor, j=2
validationParms ValidationParms OPTIONAL
}
ValidationalParms ::= Sequence {
seed BITSTRING, -- seed for prime generation
pGenCounter INTEGER, -- parameter verification
}
However, it seems that OpenSSL does not support the X9.42 version.
From the notes on the dhparam man page:
OpenSSL currently only supports the older PKCS#3 DH, not the newer X9.42
DH.
All the OpenSSL built-in RFC5114 domain parameters are also defined in terms of
p, q and g.
However, you are correct that the DH computation does not use q,
although I do not
know whether JCE requires it to be specified (not having used JCE).
Matt
Re: Diffie algorithm in openssl: and Java
On 18 March 2013 21:44, Matt Caswell fr...@baggins.org wrote: However, you are correct that the DH computation does not use q, although I do not know whether JCE requires it to be specified (not having used JCE). One other point on this - X9.42 describes an optional validation procedure which does use q. From RFC2631 (based on X9.42): The following algorithm MAY be used to validate a received public key y. 1. Verify that y lies within the interval [2,p-1]. If it does not, the key is invalid. 2. Compute y^q mod p. If the result == 1, the key is valid. Otherwise the key is invalid. The primary purpose of public key validation is to prevent a small subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static mode is used, this check may not be necessary. See also [P1363] for more information on Public Key validation. Matt
RE: libcrypto.a linking problem?
Hello, Are you linking with libdl.so? (-ldl) -Tom Thomas Floodeen, Jr. Mentor Graphics BSD 720.494.1133 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of zero modulo Sent: Sunday, March 17, 2013 10:33 PM To: openssl-users@openssl.org Subject: libcrypto.a linking problem? I'm unable to build Git 1.8.1.3 with libcrypto. I've compiled and built OpenSSL with the same LDFLAGS and CPPFLAGS as below. I also have a `/etc/ld.so.conf.d/sandbox.conf` file which loads `/sandbox/builds/lib` as a library path for LD_LIBRARY_PATH. $ uname -a Linux kosuna 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 athlon i686 GNU/Linux $ LDFLAGS=-L/sandbox/builds/lib CPPFLAGS=-I/sandbox/builds/include ./configure --prefix=$PREFIX [...] $ make /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': dso_dlfcn.c:(.text+0x1b): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x31): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x3b): undefined reference to `dlclose' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': dso_dlfcn.c:(.text+0x3c1): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x4a0): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': dso_dlfcn.c:(.text+0x521): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x600): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': dso_dlfcn.c:(.text+0x678): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x6e8): undefined reference to `dlclose' dso_dlfcn.c:(.text+0x72d): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': dso_dlfcn.c:(.text+0x7e1): undefined reference to `dladdr' dso_dlfcn.c:(.text+0x849): undefined reference to `dlerror' /sandbox/builds/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': dso_dlfcn.c:(.text+0x8aa): undefined reference to `dlclose' collect2: error: ld returned 1 exit status make: *** [git-imap-send] Error 1 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cross-compilation problem FIPS enabled openssl
I suspect you need a export FIPS_SIG=path to openssl-fips/util/incore which embeds the signature in libcrypto. On 18/03/13 17:16, Abhijit Ray Chaudhury wrote: Hello, I am trying to cross compile FIPS compliant openssl module (openssl-fips-ecp-2.0.2.tar.gz) for linux armv4 pratform : I have used following script to setup the environment: === export MACHINE=armv4t export RELEASE=2.6.23 export SYSTEM=Linux export ARCH=arm export CROSS_COMPILE=/opt/gccarm-4.1.2/bin/ export HOSTCC=/usr/bin/gcc ./config -t Operating system: armv4t-whatever-linux2 Auto Configuring fipsonly Auto Configuring fipsonly Configuring for linux-armv4 /usr/bin/perl ./Configure linux-armv4 -Wa,--noexecstack no-bf no-camellia no-cast no-idea no-md2 no-md5 no-mdc2 no-rc2 no-rc4 no-rc5 no-ripemd no-seed = I could cross compile FIPS module to build cross compiled fipscanister.o. Now I want to create libcrypto.so for arm which will have incore fingerprint. In openssl source tree if I mention the fipscanister directory it builds libcrypto.a with embedded fipscanister.o. But while creating libcrypto.so it tries to build fips_premain_dso which is unnecessary for cross compilation scenario as it is a native binary just tries to load libcrypto.so to verify signature embedding in libcrypto.so is fine. All I need is a signature embedded libcrypto.so. Could you kindly help in this regard. Thanks in Advance, -Abhijit __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
