Re: [openssl-users] Re: having a lot of troubles trying to get AES-NI working
On Sat, Mar 16, 2013 at 01:16:23AM -0400, Ewen Chan wrote: > Okay then, here's another one of my infamous dumb questions. > > If that's the case, then why do we need the AES-NI instruction set? It's far from the first accelerated instruction set of dubious utility. ;) Marketing... etc. Actually, SSL / TLS performance is much more greatly increased by an RSA accelerator. If I were Intel I would have made that first, before AES-NI, because RSA signs and verifies consume a lot more resources and are a lot more vulnerable to DoS than AES. But, of course, RSA is more complex. The tech companies are not trying to make the best possible product, but the best product that's economically feasible, which is a slightly different goal. > If it's likely going to be storage and/or network bandwidth limited; > wouldn't the improvements made by introducing and incorporating the > AES-NI instruction set be kind of "wasted" in the sense that you can't > really use it to the fullest potential anyways? Amdahl's Law: the amount of overall improvement of performance by improving an area is proportional to the amount that area is executed. > If the storage/network I/O is going to be your bottleneck/limiting > factor, then regardless of whether you have AES-NI or not; you're > likely going to get the same answer in terms of speed. Yes! > Also, is that why (besides the fact that CBC can't be parallelized) > why it doesn't make sense or people really haven't spent too much time > or effort into trying to run AES encryption/decryption on GPGPUs? > Because it's already faster than anything else is capable of at the > moment? Like Erwann said, the memory transfers would likely cost more time than using AES-NI. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: having a lot of troubles trying to get AES-NI working
Okay then, here's another one of my infamous dumb questions. If that's the case, then why do we need the AES-NI instruction set? If it's likely going to be storage and/or network bandwidth limited; wouldn't the improvements made by introducing and incorporating the AES-NI instruction set be kind of "wasted" in the sense that you can't really use it to the fullest potential anyways? If the storage/network I/O is going to be your bottleneck/limiting factor, then regardless of whether you have AES-NI or not; you're likely going to get the same answer in terms of speed. (I actually copied the input file onto my SSD so as to try and eliminate that as the bottleneck; and then write the output to the same drive.) (haha...it feels like that the more questions I ask, the more confused I get...lol...) Also, is that why (besides the fact that CBC can't be parallelized) why it doesn't make sense or people really haven't spent too much time or effort into trying to run AES encryption/decryption on GPGPUs? Because it's already faster than anything else is capable of at the moment? On Sat, Mar 16, 2013 at 1:05 AM, Matthew Hall wrote: > On Sat, Mar 16, 2013 at 12:06:07AM -0400, Ewen Chan wrote: >> That's MUCH faster than I expect it to be (even with AES-NI) and the >> 888 MB/s is faster than any available storage host-bus interface we've >> got right now; so I want to make sure that I am not losing my marbles >> here in trying to make some sense out of this data. >> >> Thanks. > > Without AES-NI other still quite fast instructions are used from SSE, SSE2, > etc. So it is a boost but not the be-all end-all boost. > > In most cases the Core i7 will clobber most any storage device bar the very > most costly SSDs. It's an extremely powerful CPU. If this isn't screaming fast > enough, use GCM instead of CBC, and enjoy the multicore awesome thereof. ;) > > As fast at it is, 10 GBE will still do 1280 MiB / sec. But it should fill up > the 8 Gbps FC with no issues. > > Matthew. > __ > 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: [openssl-users] Re: having a lot of troubles trying to get AES-NI working
On Sat, Mar 16, 2013 at 12:06:07AM -0400, Ewen Chan wrote: > That's MUCH faster than I expect it to be (even with AES-NI) and the > 888 MB/s is faster than any available storage host-bus interface we've > got right now; so I want to make sure that I am not losing my marbles > here in trying to make some sense out of this data. > > Thanks. Without AES-NI other still quite fast instructions are used from SSE, SSE2, etc. So it is a boost but not the be-all end-all boost. In most cases the Core i7 will clobber most any storage device bar the very most costly SSDs. It's an extremely powerful CPU. If this isn't screaming fast enough, use GCM instead of CBC, and enjoy the multicore awesome thereof. ;) As fast at it is, 10 GBE will still do 1280 MiB / sec. But it should fill up the 8 Gbps FC with no issues. Matthew. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: having a lot of troubles trying to get AES-NI working
Do these number make sense or seem reasonable? (I'm running a Core i7 3930K that's been OC'd to 4.5 GHz up from the stock 3.2 GHz, running cygwin 1.7.17 on Windows 7 x64 Professional, with 64 GB of DDR3-1600) ~$ OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 50880991 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 14919708 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 3870779 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 981188 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 122920 aes-256-cbc's in 3.00s OpenSSL 1.0.1e 11 Feb 2013 built on: Tue Feb 12 15:42:44 CET 2013 options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: i686-pc-cygwin-gcc -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 271365.29k 318287.10k 330306.47k 334912.17k 335653.55k ~$ openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 108926706 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 29319700 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 7428178 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1863275 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 233116 aes-256-cbc's in 3.00s OpenSSL 1.0.1e 11 Feb 2013 built on: Tue Feb 12 15:42:44 CET 2013 options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: i686-pc-cygwin-gcc -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 580942.43k 625486.93k 633871.19k 635997.87k 636562.09k Am I to interpret the results as even with the AES-NI disabled, that I'm still abled to process at a minimum, 300 MB/s (for block sizes > 64 B) and that with AES-NI; it's only double that (~600-and-change MB/s)? And that for AES-128-CBC, with 8 kiB blocks, that I'm able to process it at 465 MB/s without AES-NI, and 888 MB/s with? That's MUCH faster than I expect it to be (even with AES-NI) and the 888 MB/s is faster than any available storage host-bus interface we've got right now; so I want to make sure that I am not losing my marbles here in trying to make some sense out of this data. Thanks. On Fri, Mar 15, 2013 at 5:23 AM, Erwann Abalea wrote: > On a PC under Linux, you can do a "cat /proc/cpuinfo" and look for "aes" in > the "flags". > On a PC under any OS, get the CPUID, and look for bit 25 of ECX. > That's not OpenSSL-related. > > > The use of OPENSSL_ia32cap environment variable allows you to alter the > CPUID result (only inside OpenSSL), and alter its behaviour. It's not > resistant to a reboot, it's only process dependant. > > Compare the following results: > > OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc > openssl speed -elapsed -evp aes-128-cbc > > > -- > Erwann ABALEA > > Le 15/03/2013 04:46, Ewen Chan a écrit : > > Does it matter whether it's ia32 or ia64 even for an x64 processor? > > Shouldn't there be some way for me to check whether AES is enabled or > being used (other than running a speed test) either in dmesg or /proc/ > or with openssl itself? I'm a little confused, and surprised/shocked > that there isn't a way to probe the status of whether the AES-NI is a) > present and b) enabled/utilized. > > re: OPENSSL_ia32cap=~0x202 > so forgive me for asking lots of dumb questions but that would be > $ set OPENSSL_ia32cap=~0x202 > $ export OPENSSL_ia32cap > > correct? > > And how do I re-enable it without having to reboot the system? What's > the value that I should be putting in on the right-hand-side of the > equal sign? > > Your help is much appreciated. > > Sincerely, > Ewen > > On Thu, Mar 14, 2013 at 7:35 PM, Dr. Stephen Henson > wrote: > > On Thu, Mar 14, 2013, Ewen Chan wrote: > > So this is a partial continuation from the discussion thread that I > started yesterday in regards t
question about salt
If I specify a salt, does the salt have to be ASCII or can they be Unicode? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: specifying the number of rounds that I would like to use with AES-192-CBC
So is the number of rounds set by Rijndahl or the AES spec? I'm confused. And is the number of rounds hard-coded into the OpenSSL source; or is it embedded somewhere else? On Fri, Mar 15, 2013 at 7:27 PM, wrote: > I don't know the interfaces to OpenSSL, but AES-192 specifies the number > of rounds. The approved AES algorithms specify a subset of Rijndahl > cipher whereby you can specify alternative numbers of rounds, key > sizes, and block sizes. > > Sincerely, > Steven J. Hathaway > >> There's a file that I want to encrypt using AES-192-CBC but with 19 >> rounds rather than the default 12-rounds. >> >> Is there a way for me to specify the number of rounds that I would >> like to use with the AES-192-CBC? (and override the algorithm >> defaults)? >> >> Is that something that I can within the openssl command itself (to >> encrypt a file) or is the process much more involved than that? And >> requires programming/scripting? >> __ >> 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: smime tool, binary and verify
> From: owner-openssl-us...@openssl.org On Behalf Of Dirk-Willem van Gulik
> Sent: Wednesday, 06 March, 2013 06:01
-dev added as a possible minor bug/enhancement, see end
> A simple
>
> echo foo | openssl smime -encrypt/sign | openssl smime
> -decrypt/verify
>
> works dandy. But was surprized to find that the verify breaks
> when '-binary' is used.
>
> Canonical example [snipped]
>
> Would like to understand why,
smime -sign defaults to -outform SMIME and no-nodetach, which
produces a multipart/signed aka "clear-signed" message.
Officially, the content of any SMIME message must be a MIME
entity with headers, and especially so for multipart/signed
since in that case it may need to be parsed by plain MIME
logic before getting to SMIME processing. OpenSSL doesn't
enforce this, although it does have option -text to add
minimal headers for text/plain, or check and remove such.
Also officially, as the man page says somewhat imprecisely,
SMIME content must be canonicalized, again especially so
for multipart/signed. "echo foo" on Unix does NL not CRLF,
and only CRLF is canonical for text in (S)MIME.
These requirements do not apply to PKCS7, which 'smime'
also supports with -out/inform PEM/DER. Even for SMIME,
non-text types can have different canonicalization rules,
which -binary apparently tries to handle, imperfectly.
But for multipart/signed, many "binary" types will need
transfer-encoding anyway, which OpenSSL doesn't handle.
Either SMIME or PKCS7 -sign -nodetach embeds the content
as-is with -binary and text-canonicalized without, and signs
the embedded version. -verify recognized embedded automatically
(does not need -nodetach), verifies the embedded version,
and outputs that even if -binary since we can't tell from
the message if/where sender canonicalization changed it.
SMIME -sign "detached" "attaches" content similarly as-is
with -binary and text-canonicalized without, and signs that.
SMIME -verify recognizes "detached", but (in multi_split)
always canonicalizes both parts before using them. For content
that was sent noncanonical (with -sign -binary or equivalent)
this changes the signed content, and verify fails.
Content that was canonical as sent (originally canonical
or canonicalized by sender) does verify and similarly
is output without determining if sender changed it.
PKCS7 -sign detached doesn't send the content at all;
you must do so, and provide it using -content on -verify,
and that content must be the canonicalized version if
-sign didn't specify -binary (which is rather fragile).
Also, looking at multi_split, I see confusing state that
may work poorly or wrong if (re)used for other multipart
types (specifically, with ~256 or more or 0 parts).
Per above I don't see any point in canonicalizing here:
content should have been canonicalized by the sender,
and if not then doing it here doesn't help (the message
has presumably already endured email) and may hurt;
signature pretty much has to be base64 and forcing
that base64 to CRLF (if not already) is useless.
I would suggest something more like:
BIO *bpart = NULL; *ret = sk_BIO_new_null();
while( (len=BIO_gets(bio,linebuf,max)) > 0 ){
state = mime_bound_check(linebuf,,,);
if( state==2 ) return 1; // end boundary
if( state==1 ){ // other boundary
bpart = BIO_new(BIO_s_mem());
BIO_set_mem_eof_return(bpart,0);
sk_BIO_push(*ret,bpart); // when "opened"
eol = 0;
}
else if(bpart){
#if canonicalize?
if(eol) BIO_write(bpart,"\r\n",);
eol = strip_eol(linebuf,&len/*decreased as needed*/);
if(len) BIO_write(bpart,linebuf,len);
#else
if(eol==2)BIO_write(,"\r\n",); else if(eol==1)BIO_write(,"\n",);
/*else nop*/
// or mildly tricky if(eol)BIO_write(,"\r\n"+2-eol, 2-eol));
eol = if linebuf ends with \r\n then 2
else if linebuf ends with only \n then 1 else 0;
// this could be a modified strip_eol() or just inline
if(len -= eol) BIO_write(,linebuf,len);
#endif
}
// else prologue data, discard
}
return 0; // EOF without proper end boundary
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Private key passphrase: salt question
>From: owner-openssl-us...@openssl.org On Behalf Of Evan Brown >Sent: Wednesday, 13 March, 2013 11:02 >openssl genrsa -aes256 -out private.pem 2048 >Am I correct in my understanding that OpenSSL adds a salt >to the passphrase that I specify when this command runs? >How is the salt computed and where is it stored for use later >in the key decryption process? Does OpenSSL calculate the salt >again from the passphrase when I decrypt the key? For PEM(ish) encrypted privatekey files, OpenSSL uses one random value for both salt and IV, and stores it in PEM header. Decryption uses this stored value as both salt and IV. __ 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: Wednesday, 13 March, 2013 13:44 >I was trying to implement the diffie Hellman algorithm in Java >which makes use of JCF and as well as in c with openssl... I assume you mean JCE, or maybe JCA. JCF is completely unrelated. >I am able to get this work in respective languages I.e Java - Java >and C-C works fine . Generates the DH parameters and other stuffs quit well. >Since my server is in Java and client is in C, I was trying to use >openssl generated keys with Java as other part of component which is not >working at all. Java keeps giving me invalid key specification exception... What exactly are you trying to do? Your client and server, or other parties, should NEVER share a DH privatekey; they must share parameters (the group definition prime P and generator G) and exchange publickeys that use the same parameters. There are two usual ways of doing this: 1: parameters are distributed in advance, each party generates keypair (possibly certified), and they exchange at least public values (y) and optionally also duplicate parameters (especially if using certificates). 2: one party (in SSL/TLS the server) sends publickey containing parameters and public value (which may be generated in advance or transient); other party uses parameters to generate and send public value (usually transient). Openssl stores DH parameters in PKCS3 format, and since 1.0.0 can store DH privatekey in PKCS8 clear (really privkeyinfo) or encrypted and DH publickey in "PUBKEY" (X509 pubkeyinfo), both of which include parameters. JCE as far as I can see can't handle DH parameters alone, but can handle PKCS8 clear as PKCS8EncodedKeySpec and X509-keyinfo as X509EncodedKeySpec. (JCE handles only the DER forms; converting DER to/from PEM isn't hard, but openssl does it easily for free.) For 2 above Java responder can simply read the peer's publickey, and copy the parameters to generate its "self" keypair. For 1 you can either (create and) use a dummy publickey to transmit the parameters or you can write your own code to do PKCS3 -- or some other format. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: specifying the number of rounds that I would like to use with AES-192-CBC
I don't know the interfaces to OpenSSL, but AES-192 specifies the number of rounds. The approved AES algorithms specify a subset of Rijndahl cipher whereby you can specify alternative numbers of rounds, key sizes, and block sizes. Sincerely, Steven J. Hathaway > There's a file that I want to encrypt using AES-192-CBC but with 19 > rounds rather than the default 12-rounds. > > Is there a way for me to specify the number of rounds that I would > like to use with the AES-192-CBC? (and override the algorithm > defaults)? > > Is that something that I can within the openssl command itself (to > encrypt a file) or is the process much more involved than that? And > requires programming/scripting? > __ > 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: possible Bug in OpenSSL - rfc 3161 - TSA service
for those who don't read openssl-dev Original Message Subject:[openssl.org #3016] openssl ts fix Date: Wed, 13 Mar 2013 16:13:31 +0100 From: Peter Sylvester via RT Reply-To: openssl-...@openssl.org CC: openssl-...@openssl.org Hi, I have "weakend" the Esscertid logic a bit. Only the signer certficate is checked and it must be in the first Esscertid. This resolves issues when TSAs add attribute certs etc. Since RFC 3161 does not require a client to check anything else than the presence of the signer cert (and even is is badly written), I think the verification of a "chain" in the ess was not appropriate logic. regards
Re: possible Bug in OpenSSL - rfc 3161 - TSA service
On 13.03.2013 01:19, kap...@mizera.cz wrote: Dne 12.3.2013 20:36, Walter H. napsal(a): Hello, I found the following: http://tsa.postsignum.cz:444 do you have account by this TSA ? No. if there is a need to have an account; then this page is not conforming to any RFC - HTTP 400 is not an indicator for wrong login credentials; this must be 401 produces the following error, when using this as time stamp server with adobe standard/pro "BER decoding error" Are you sure you (adobe program) get timestamp and not just HTML error page ? Try to get TSReply manually with CURL: are you shure this TSA is working at all? openssl ts -query -data file.txt -sha256 -cert -no_nonce >file.txt-nononce-sha256-cert.tsq curl -k -v -H "Content-Type: application/timestamp-query" -u "name:password" --data-binary @file.txt-nononce- sha256-cert.tsq https://tsa.postsignum.cz:444 >file.txt-nononce-sha256-cert.postsignum.tsr what do you mean with "my solution with OpenSSL works" ? that my OpenSSL TS server works ... That you use own "testing", opennsl based TS server ? correct If yes and only timestamps from "tsa.postsignum.cz:444" server cause this problem then it would be interesting, because the CA (TS Authority) claims that only openssl client has problem with their timestamps. can you give me for a try userid and pwd, then I may find out where the bug is; try this: https://timestamp.geotrust.com/ (this is really free, no auth. neccessary) Adobe client no. which Adobe version they claim not having problems with ...? Greetings Walter smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-users] Offline Root CA and CRL generation
Hi Erwann, Am 15.03.2013 17:36, schrieb Erwann Abalea: Yes. That's one possible solution (possible from a PKI point of view). Another solution would be to play with indirect CRLs. That involves Thank you very much for your explanations, I will try these scenarios. Thanks, Sven __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Offline Root CA and CRL generation
Le 15/03/2013 17:01, Sven Dreyer a écrit : Hi Erwann, Am 15.03.2013 16:16, schrieb Erwann Abalea: You can generate a self-issued certificate dedicated to CRL signing (same name, different key, signed by your root). That's acceptable for RFC5280, but you'll have to check with your clients. And find a way to distribute this certificate. I'm not sure whether I got it right. My Root CA is named "Foobar Root CA" with keypair (A). I would then let "Foobar Root CA" issue a certificate for "Foobar Root CA" with keypair (B) and attribute "keyUsage = cRLSign". I would then use the certificate for keypair (B) to sign the CRL. Then, I would distribute the certificates for "Foobar Root CA" (A) and "Foobar Root CA" (B) to my clients' trusted CA stores. Is this the way you pointed me to? Yes. That's one possible solution (possible from a PKI point of view). Another solution would be to play with indirect CRLs. That involves issuing a certificate (with a different name, for example "Foobar CRL Signer") dedicated to CRL signing, specifying its name in the CRLDistributionPoints of your issued certificates, and sign the CRL with this certificate+private key (Foobar CRL Signer). That CRL must have a critical IssuingDistributionPoint extension with the indirectCRL set to true, and at least the first revocation entry must have an extension indicating its issuer name (Foobar Root CA). "Foobar CRL Signer" may be issued under a completely different trust chain. I don't know how well this second solution is supported by clients, and I suppose that the "Foobar CRL Signer" certificate should itself have a CRLDP extension pointing to a valid CRL, etc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL server downtime
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! The new server currently hosting the www, git, rt, ftp, and cvs services is going to be moved within the installation of our hoster. As a consequence, the system will be assigned a new IP address. Old: 178.16.220.54 New: 185.9.166.106 The move is planned to happen around 12.30 UTC on Sunday, 17 Mar 2013. Users are expected to see a short outage of the service. An additional delay may be caused by the old IP address being cached in the DNS. Best regards, Lutz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBUUNJd3iZOxScWKZtAQJlvwQAqZ6o8X70R5gElvX8929c5y+TtU7ViHr3 ClzteUdISun5zK1wCIhewCBEz92s8kCu0RtNk6t6D7g+LNOlAd9T2HO+wB0+WvC1 HMfTHJg3vNW5PgVaEzVEm69Nk4r3zfuXoginuQLHm3qIHopzrQMEy1DWxRD/Aysu AfrtmWYs74A= =TwV7 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Offline Root CA and CRL generation
Hi Erwann, Am 15.03.2013 16:16, schrieb Erwann Abalea: You can generate a self-issued certificate dedicated to CRL signing (same name, different key, signed by your root). That's acceptable for RFC5280, but you'll have to check with your clients. And find a way to distribute this certificate. I'm not sure whether I got it right. My Root CA is named "Foobar Root CA" with keypair (A). I would then let "Foobar Root CA" issue a certificate for "Foobar Root CA" with keypair (B) and attribute "keyUsage = cRLSign". I would then use the certificate for keypair (B) to sign the CRL. Then, I would distribute the certificates for "Foobar Root CA" (A) and "Foobar Root CA" (B) to my clients' trusted CA stores. Is this the way you pointed me to? Thanks, Sven __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl-user - UTF8 characters in configuration file
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: [openssl-users] Offline Root CA and CRL generation
X.509 allows for a self-signed certificate dedicated to CRL signing (with the same name, of course). But that's not acceptable for RFC5280. You can generate a self-issued certificate dedicated to CRL signing (same name, different key, signed by your root). That's acceptable for RFC5280, but you'll have to check with your clients. And find a way to distribute this certificate. -- Erwann ABALEA Le 15/03/2013 15:53, Sven Dreyer a écrit : Hi List, I would like to setup an OpenSSL-based offline Root CA. Certificates issued by this Root CA contain a CDP. I would like to issue CRLs every 3 days, which would mean that I would have to take the offline Root CA online each 3 days. Is there a way to let the Root CA issue a "CRL signer certificate", which can then run on a different machine for CRL signature? For OCSP it seems to be possbile (RFC2560, 2.6 - "OCSP Signature Authority Delegation"). Does anybody know whether it's possible for CRL's using OpenSSL? Thanks for any advice, Sven __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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: Offline Root CA and CRL generation
Hi Matthew, Am 15.03.2013 16:03, schrieb Matthew Hall: Read about the cRLSign KeyUsage bit. This is how it is usually handled. I already let the Root CA issue a certificate with "keyUsage = cRLSign" and used that certificate to sign the CRL, but my colleague's Windows machine refused to accept the CRL signed that way. The problem went away when I directly signed the CRL with the Root CA certificate, so I thought I did something wrong or it's simply not possible. Thanks, Sven __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Offline Root CA and CRL generation
Hi List, I would like to setup an OpenSSL-based offline Root CA. Certificates issued by this Root CA contain a CDP. I would like to issue CRLs every 3 days, which would mean that I would have to take the offline Root CA online each 3 days. Is there a way to let the Root CA issue a "CRL signer certificate", which can then run on a different machine for CRL signature? For OCSP it seems to be possbile (RFC2560, 2.6 - "OCSP Signature Authority Delegation"). Does anybody know whether it's possible for CRL's using OpenSSL? Thanks for any advice, Sven __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Validation error on generated csr
On Fri, 15 Mar 2013, Dr. Stephen Henson wrote: Analysing that CSR the actual signature isn't in the correct form: it just contains the raw SHA1 digest instead of the required DigestInfo structure. You can check that using rsautl in a manner similar to that for certificates mentioned in the manual page. However: sign_mechanism.mechanism = CKM_SHA1_RSA_PKCS; That mechanism *should* produce a signature in the correct format, so possibly a problem with the PKCS#11 library? Might be. Estonian ID-card PKCS#11 driver has exact same bug. If the hash algorithm is SHA-1 then the DigestInfo is omited. Use some other algorithm and it is correctly included. Estonian ID-card drivers share code with OpenSC drivers (or vice versa :) so this bug might be more widespread. Best regards, Arne __ 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
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: Validation error on generated csr
Hi Steve Thanks a lot for your reply. Just another quick question. Do you know by chance an openssl function that would convert the raw sha1 into a digestinfo structure? Kind regards Tim On 03/15/2013 02:36 PM, Dr. Stephen Henson wrote: On Fri, Mar 15, 2013, Tim Tassonis wrote: 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: Analysing that CSR the actual signature isn't in the correct form: it just contains the raw SHA1 digest instead of the required DigestInfo structure. You can check that using rsautl in a manner similar to that for certificates mentioned in the manual page. However: sign_mechanism.mechanism = CKM_SHA1_RSA_PKCS; That mechanism *should* produce a signature in the correct format, so possibly a problem with the PKCS#11 library? 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
Re: [openssl-users] using multiple keys
So if I want to do that, the very basic way for me to do it would be to write all of the commands (line-by-line; which processes each file separately) into a shell script file and then run that? But if I were to use some kind of programming or more advanced scripting language/syntaxes; I would be able to automate that (which makes it easier for me in the long run)? Thanks for all your help so far. P.S. In regards to the whole OS saga - I ended up installing Solaris 11.1; although I'm not really sure if it worked or not. lol... On Fri, Mar 15, 2013 at 9:32 AM, Erwann Abalea wrote: > > Le 15/03/2013 13:54, Ewen Chan a écrit : > >> Sorry, my bad. Wrong terminology. >> >> (The AES wiki says that it uses a key.) But I was really thinking >> about multiple passphrases. > > > And from this passphrase, a key and IV can be generated. It's more easy to > remember a passphrase than a bunch of hex digits. > > >> Sorry for the mix up. >> >> So let's say I have three files: >> file1 >> file2 >> file3 >> >> And then I have a passphrase file that contains the following: >> >> Alice >> Bob >> Charlie >> >> and I want to encrypt file1 with the passphrase "Alice"; file2 with >> the passphrase "Bob" and file3 with the passphrase "Charlie". >> >> Is there a way to get openssl to automatically do that or do I need to >> write a program/shell script so that I will automatically increment >> one and pull the passphrase from the appropriate passphrase file? > > > The openssl command-line tool doesn't do that. It can work with one > passphrase file per file, or you can provide the passphrase as an argument. > If you want to centralize your passphrases, you'll have to write some kind > of wrapper to extract the good passphrase and provide it to "openssl enc" > (either in a dedicated file, or as an argument). > > >> (Disclaimer: I am NOT a programmer. At all. By ANY stretch of the >> imagination.) > > > Nobody's perfect :D __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Validation error on generated csr
On Fri, Mar 15, 2013, Tim Tassonis wrote: > 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: > Analysing that CSR the actual signature isn't in the correct form: it just contains the raw SHA1 digest instead of the required DigestInfo structure. You can check that using rsautl in a manner similar to that for certificates mentioned in the manual page. However: > > sign_mechanism.mechanism = CKM_SHA1_RSA_PKCS; That mechanism *should* produce a signature in the correct format, so possibly a problem with the PKCS#11 library? 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
key/passphrase length limits - AES-256-CBC
For AES-256-CBC, if I have a passphrase stored in a file; are there limits in terms of how big either the key or the passphrase can be in terms of characters? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] using multiple keys
Le 15/03/2013 13:54, Ewen Chan a écrit : Sorry, my bad. Wrong terminology. (The AES wiki says that it uses a key.) But I was really thinking about multiple passphrases. And from this passphrase, a key and IV can be generated. It's more easy to remember a passphrase than a bunch of hex digits. Sorry for the mix up. So let's say I have three files: file1 file2 file3 And then I have a passphrase file that contains the following: Alice Bob Charlie and I want to encrypt file1 with the passphrase "Alice"; file2 with the passphrase "Bob" and file3 with the passphrase "Charlie". Is there a way to get openssl to automatically do that or do I need to write a program/shell script so that I will automatically increment one and pull the passphrase from the appropriate passphrase file? The openssl command-line tool doesn't do that. It can work with one passphrase file per file, or you can provide the passphrase as an argument. If you want to centralize your passphrases, you'll have to write some kind of wrapper to extract the good passphrase and provide it to "openssl enc" (either in a dedicated file, or as an argument). (Disclaimer: I am NOT a programmer. At all. By ANY stretch of the imagination.) Nobody's perfect :D __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Validation error on generated csr
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
FDASBgNVBAoTC2ludGVsbGlDYXJkMRUwEwYDVQQDEwxUaW0gVGFzc29uaXMxKjAo
BgkqhkiG9w0BCQEWG3RpbS50YXNzb25pc0BpbnRlbGxpY2FyZC5jaDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6eAKGt9fVPSd6uv1/Rs8Uf1j9eaaA5
y7GCeybV/vAqxebI7P7RN3POz6XBYP2i2P4DwXiGeU2oDylxnHHUItAWqtIfX3H+
WDb9d98oaZnWjQsWwoBWXLjsALdblU4MKaF1K9k7obDo2rN7exXzBMRdrQnvhbW/
6ICDe3iBNmhAk4xBIKC/lIuwILnb4xjopz261sPfg2fjV4964R/Wa7C8Iu+tPq20
LRLtZfqTTqWnnmMpdYRQMBAt7/MDSoG2l8rbnu7/TYr9F5Dzso/K2T884sZDZPeJ
cIo4ZjIDE7Vj4C9tOWDaG2lhrb11JNM0ok081ZIERhg3lEYSmMZxbbUCAwEAAaAA
MAsGCSqGSIb3DQEBBQOCAQEAeTc7sIpWdIwkh0bj5PVlbMcJT1QDaBG9m7lYkLRg
ACBKqNLaIh/drVvGmkLdMyoedOrtjRp5PHDuEptEtBjWRy3H/fBqOsqIr8w3tGA8
A3zubCM3qmLrm4bHTyhP5w2bqY+1JfrRO68bXTQlb1rhpFddtLO7jmjM2lMr7UgH
d9vicOWuAEjOOF1nenzCXxjWovKX3jB/b4rwmf9lmHx6hD8Z9EKCdwO5JKPgcWzr
/UCznGUe1TAHr0XFRZPwZo2buMCYAVPw70/4u36fc+G6UPaeQSk6QR035BUs8HE0
BBXO9brFuXld13VuE2xg+VnJ8vo3L7/SCC5ufEJaeSUOvQ==
-END CERTIFICATE REQUEST-
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)
{
BIO *bio_err = NULL,*bio_out = NULL;
X509_REQ *req=NULL;
static char *csr_buf = NULL;
int csr_len = 0;
int curr_nid;
X509_NAME *subj=NULL;
int i=0;
int rc;
CK_OBJECT_HANDLE prvkey = NULL, pubkey = NULL;
CK_RV rv;
CK_BYTE *buf_in=NULL,*buf_out=NULL, *p=NULL;
size_t inl=0,outl=0;
RSA *rsa = NULL;
CK_MECHANISM sign_mechanism;
EVP_PKEY *pkey = NULL;
FILE *req_info_file = NULL;
EVP_MD *md = EVP_sha1();
rc = p11_get_key(key_name,CKO_PRIVATE_KEY,&prvkey);
if (rc != 0) {
return NULL;
}
rc = p11_get_key(key_name,CKO_PUBLIC_KEY,&pubkey);
if (rc != 0) {
return NULL;
}
rsa = p11_key_rsa(pubkey);
if (!rsa) {
return NULL;
}
pkey = EVP_PKEY_new();
EVP_PKEY_assign_RSA(pkey, rsa );
req = X509_REQ_new();
if (req == NULL) {
return NULL;
}
if (!X509_REQ_set_version(req,0L)) {
return NULL;
}
subj = X509_REQ_get_subject_name(req);
for (i=0; key_attrs[i] != NULL; i++) {
curr_nid=OBJ_txt2nid(subjattrs[i]->key);
if (curr_nid == NID_undef ) {
continue;
}
if (!X509_NAME_add_entry_by_txt(subj,key_attrs[i]->key,
MBSTRING_ASC,(unsigned char *)key_attrs[i]->val,-1,-1,0)) {
continue;
}
}
X509_REQ_set_pubkey(req, pkey);
subj=NULL;
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;
}
req->signature->data=buf_out;
req->signature->length=outl;
req->sig_alg->algorithm = OBJ_nid2obj(md->pkey_type);
req->signature->flags&= ~(ASN1_STRING_FLAG_BITS_LEFT|0x07);
req->signature->flags|=ASN1_STRING_FLAG_BITS_LEFT;
bio_out=BIO_new(BIO_s_file());
if (BIO_write_filename(bio_out,"my.csr") <= 0) {
return NULL;
}
if (!PEM_write_bio_X509_REQ(bio_out,req)) {
return NULL;
}
BIO_free_all(bio_out); bio_out=NULL;
csr_buf = backend_read_file("my.csr",&csr_len);
csr_buf[csr_len] = '\0';
if (buf_in) free(buf_in);
if (buf_out) free(buf_out);
if (req) X509_REQ_free(req);
#ifndef OPENSSL_NO_ENGINE
ENGINE_cleanup();
#endif
CRYPTO_cleanup_all_ex_data();
if (bio_err) {
CRYPTO_mem_leaks(bio_err);
}
if (bio_err) BIO_free(bio_err);
Re: [openssl-users] using multiple keys
Sorry, my bad. Wrong terminology. (The AES wiki says that it uses a key.) But I was really thinking about multiple passphrases. Sorry for the mix up. So let's say I have three files: file1 file2 file3 And then I have a passphrase file that contains the following: Alice Bob Charlie and I want to encrypt file1 with the passphrase "Alice"; file2 with the passphrase "Bob" and file3 with the passphrase "Charlie". Is there a way to get openssl to automatically do that or do I need to write a program/shell script so that I will automatically increment one and pull the passphrase from the appropriate passphrase file? (Disclaimer: I am NOT a programmer. At all. By ANY stretch of the imagination.) Thanks. On Fri, Mar 15, 2013 at 5:01 AM, Erwann Abalea wrote: > "openssl enc" encrypts one file at a time, and can read the first line of a > file to get the passphrase (in order to derive key and iv). > If you want to provide your own key and iv, you have to do it as command > line arguments. > Key management is out of scope. > > -- > Erwann ABALEA > > Le 15/03/2013 06:33, Ewen Chan a écrit : >> >> If I have a directory and it has 10 files and I have 10 separate keys >> such that key1 is for file1 and key2 is for file2 (etc.); is there a >> way to automate the encryption process like that? >> >> Or do I have to run each of the commands separate and instead of >> having 10 separate keys in a single keyfile in a list format; that I >> would need to split them out into individual keyfiles (e.g. keyfile1, >> keyfile2, etc.) and then run the encryption individually (rather than >> launching a single encryption job that will process all 10 files with >> all 10 keys listed in one keyfile)? >> >> (I hope that this makes sense and that people are kinda getting what >> I'm asking here.) >> >> Thanks. >> __ >> 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: [openssl-users] Re: having a lot of troubles trying to get AES-NI working
a...okay. Gotcha. Thanks! On Fri, Mar 15, 2013 at 5:23 AM, Erwann Abalea wrote: > On a PC under Linux, you can do a "cat /proc/cpuinfo" and look for "aes" in > the "flags". > On a PC under any OS, get the CPUID, and look for bit 25 of ECX. > That's not OpenSSL-related. > > > The use of OPENSSL_ia32cap environment variable allows you to alter the > CPUID result (only inside OpenSSL), and alter its behaviour. It's not > resistant to a reboot, it's only process dependant. > > Compare the following results: > > OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc > openssl speed -elapsed -evp aes-128-cbc > > > -- > Erwann ABALEA > > Le 15/03/2013 04:46, Ewen Chan a écrit : > > Does it matter whether it's ia32 or ia64 even for an x64 processor? > Shouldn't there be some way for me to check whether AES is enabled or > being used (other than running a speed test) either in dmesg or /proc/ > or with openssl itself? I'm a little confused, and surprised/shocked > that there isn't a way to probe the status of whether the AES-NI is a) > present and b) enabled/utilized. > re: OPENSSL_ia32cap=~0x202 > so forgive me for asking lots of dumb questions but that would be > $ set OPENSSL_ia32cap=~0x202 > $ export OPENSSL_ia32cap > correct? > And how do I re-enable it without having to reboot the system? What's > the value that I should be putting in on the right-hand-side of the > equal sign? > Your help is much appreciated. > Sincerely, > Ewen > On Thu, Mar 14, 2013 at 7:35 PM, Dr. Stephen Henson > wrote: > > On Thu, Mar 14, 2013, Ewen Chan wrote: > > So this is a partial continuation from the discussion thread that I > started yesterday in regards to using AES-CBC. > I've got an Intel Core i7 3930K that supports AES-NI and I spent the > greater part of last night trying to get openssl to work or at least > recognize it, but it doesn't seem to want to do that. > > It it probably recognising it and you don't realise it. OpenSSL 1.0.1 > automatically switches to AES-NI at the EVP level without going through an > explicit AES-NI ENGINE. > You can disable AES-NI detection with the environment variable: > OPENSSL_ia32cap=~0x202 > You should see a considerable speed up with "openssl speed" by comparing the > two. > 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 > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: having a lot of troubles trying to get AES-NI working
On a PC under Linux, you can do a "cat /proc/cpuinfo" and look for "aes" in the "flags". On a PC under any OS, get the CPUID, and look for bit 25 of ECX. That's not OpenSSL-related. The use of OPENSSL_ia32cap environment variable allows you to alter the CPUID result (only inside OpenSSL), and alter its behaviour. It's not resistant to a reboot, it's only process dependant. Compare the following results: * OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc * openssl speed -elapsed -evp aes-128-cbc -- Erwann ABALEA Le 15/03/2013 04:46, Ewen Chan a écrit : Does it matter whether it's ia32 or ia64 even for an x64 processor? Shouldn't there be some way for me to check whether AES is enabled or being used (other than running a speed test) either in dmesg or /proc/ or with openssl itself? I'm a little confused, and surprised/shocked that there isn't a way to probe the status of whether the AES-NI is a) present and b) enabled/utilized. re: OPENSSL_ia32cap=~0x202 so forgive me for asking lots of dumb questions but that would be $ set OPENSSL_ia32cap=~0x202 $ export OPENSSL_ia32cap correct? And how do I re-enable it without having to reboot the system? What's the value that I should be putting in on the right-hand-side of the equal sign? Your help is much appreciated. Sincerely, Ewen On Thu, Mar 14, 2013 at 7:35 PM, Dr. Stephen Henson wrote: On Thu, Mar 14, 2013, Ewen Chan wrote: So this is a partial continuation from the discussion thread that I started yesterday in regards to using AES-CBC. I've got an Intel Core i7 3930K that supports AES-NI and I spent the greater part of last night trying to get openssl to work or at least recognize it, but it doesn't seem to want to do that. It it probably recognising it and you don't realise it. OpenSSL 1.0.1 automatically switches to AES-NI at the EVP level without going through an explicit AES-NI ENGINE. You can disable AES-NI detection with the environment variable: OPENSSL_ia32cap=~0x202 You should see a considerable speed up with "openssl speed" by comparing the two. 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
Re: [openssl-users] using multiple keys
"openssl enc" encrypts one file at a time, and can read the first line of a file to get the passphrase (in order to derive key and iv). If you want to provide your own key and iv, you have to do it as command line arguments. Key management is out of scope. -- Erwann ABALEA Le 15/03/2013 06:33, Ewen Chan a écrit : If I have a directory and it has 10 files and I have 10 separate keys such that key1 is for file1 and key2 is for file2 (etc.); is there a way to automate the encryption process like that? Or do I have to run each of the commands separate and instead of having 10 separate keys in a single keyfile in a list format; that I would need to split them out into individual keyfiles (e.g. keyfile1, keyfile2, etc.) and then run the encryption individually (rather than launching a single encryption job that will process all 10 files with all 10 keys listed in one keyfile)? (I hope that this makes sense and that people are kinda getting what I'm asking here.) Thanks. __ 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: openssl-user - UTF8 characters in configuration file
Hi, 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 ... ... [ req_distinguished_name ] ... localityName_value = ZádveĹ™ice ... and commonName can either be defined in cfg file (commonName_value) or it can be raed in from a file with the proper value (interactive cli input didn't work for me then) openssl req -config utf8configfile.cfg -new -nodes -utf8 -keyout utf8key.pem -out utf8req.pem Date: Thu, 14 Mar 2013 15:35:42 -0400 Subject: RE: openssl-user - UTF8 characters in configuration file > Hi Rich! > > Glad to hear from you and hope all is well! > > Thanks for the tip, but I haven't cracked this nut yet. I've tried several > permutations of: > > - the UTF8 flag on req - openssl req -x509 -newkey rsa:1024 -out > rootcacert.pem -utf8 -outform PEM > - the no UTF8 flag on req - openssl req -x509 -newkey rsa:1024 -out > rootcacert.pem -outform PEM > - the utf8 = yes in [ req ] > - the string_mask = utf8only > - and visa versa > > I'd been using ASCII characters (still valid UTF), so I thought I'd use > proper UTF and thus: > > commonName = Róót > > Which looks good in HEX (C3B3) = o with accent > > 5c0: 696f 6e73 0d0a 0d0a 5b20 726f 6f74 5f63 ions[ root_c > 5d0: 615f 6469 7374 696e 6775 6973 6865 645f a_distinguished_ > 5e0: 6e61 6d65 205d 0d0a 0d0a 636f 6d6d 6f6e name ]common > 5f0: 4e61 6d65 2020 2020 2020 2020 2020 2020 Name > 600: 2020 3d20 52c3 b3c3 b374 0d0a 7374 6174= Rt..stat > 610: 654f 7250 726f 7669 6e63 654e 616d 6520 eOrProvinceName > 620: 2020 2020 3d20 4d41 0d0a 636f 756e 7472 = MA..countr > 630: 794e 616d 6520 2020 2020 2020 2020 2020 yName > > I also tried > > - commonName = UTF8:Róót > - commonName = UTF8STRING:Róót > - commonName = UTF8String:Róót > > And all seem to yield: > > 163:d=5 hl=2 l= 3 prim: OBJECT:commonName > 168:d=5 hl=2 l= 4 prim: T61STRING :R▒▒t > > Which is a change from PRINTABLESTRING anyway. > > Still hoping to get this working. > > Cheers > > John > > > > > > > > From: "Salz, Rich" > To: "openssl-users@openssl.org" , > Cc: "owner-openssl-us...@openssl.org" > > Date: 03/14/2013 12:53 PM > Subject:RE: openssl-user - UTF8 characters in configuration file > Sent by:owner-openssl-us...@openssl.org > > > > > Hi John! > > Looking at apps/req.c, it seems you want to use the –utf8 flag (or put > utf8: yes in your conf file [req] section) and not prefix the string with > an identifier. > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
