Re: Secure Command Line MAC Computation
> It was my understanding that the HMAC key needed to be secret even > when used for verification. (Otherwise people could forge an HMAC.) Correct. >From what you wrote, I understand you're using crypto for files. When one thinks of the H(filecontent) as the 'sector number' and the file itself as the content stored in that indexed sector, you're right smack in area of disc encryption systems. I assume you've checked out the systems used there, e.g. ESSIV, TrueCrypt, etc.etc.. This list's archive is littered with concepts and subsequent ample and dire warnings against rolling your own crypto systems (that's including mixing crypto components into something new and improved), so I'll consider that water under the bridge. Heck, sometimes we need something 'custom' so better make sure it's as solid as we can make it. Regarding IV: when you are going to encrypt the file data, a chaining mode is indeed advised. CBC is the classic choice but as you mentioned before it requires no recurrence of the IV (unique IVs), but it /also/ requires /unpredictable/ IVs to have a chance to work. CBC mode is not an authenticating mode, so you'll need a MAC to go with that at least, otherwise edits to the ciphertext can simply pass into the decrypted plaintext undetected, which would be a bit embarrassing. What I see in most of those disc crypto designs is that IVs are mostly generated using H(Key) constructs, i.e. hashes of keys instead of keys directly; you're using a supposedly independent key, which should be fine as well, as that's the other choice going around a lot. Nevertheless, have your design reviewed by a few professional cryptoanalysts anyhow. I have not been trained for that. I don't see any glaring issues in your crypto design. Meanwhile you have another threat vector lingering there: you are worried about your keyfile for the HMAC, for one. Which means you perceive a possible threat originating from the system you're running on, at least from folks who can run a local or remote 'ps' on your critical box. 'critical' because the box carries secret key data on disc and in RAM. That means you have a threat vector going straight through your operating system's access control (those darn rwxrwxrwx bits on UNIX) plus another threat vector going 'around' your OS ACL and only memory protection to guard against it: when I can run ps, I can run another binary, which can dump all RAM content for me [*], unless the box has serious memory protection features preventing me from doing just that, and that leaves out 'dd'-ing the disc with your keyfile on it and cold boot attacks and what have we; I don't need your keyfile if I can get at it's equivalent in RAM or rip the disc it's sitting on. And there's no crypto countermeasures in there for those attackers there, is it? Is that okay with you? 'yes' is an acceptable answer; it's just that you need to consider /all/ threat vectors, rank them (level of risk: occurrence probability, severity of impact, amount of effort available to prevent them), and list the ones you don't want to mind about: every system has it's conditions and limitations that way. Listing threat protection as 'Operating System only' is okay, as long as it's listed. Sounds to me like you did, but I'm doublechecking here. [*] yes, yes, yes, guest can run ps but not 'install' his own binaries, let alone compile his evil gadgets. And no 'dd' for that evil s.o.b., ever! Absolutely. Meanwhile, allow me to write files and fiddle their x bit for me, and with a bit of extra effort I can transfer my evil binary onto your box and take it from there. Which means your admin has to be extra special careful with the evil dudes on there. Note that by worrying about your keyfile(s) like that, using that 'secure' word, you're implying that you are running your crypto system in an 'environment considered hostile' and that's a /very/ large can of worms you opened right there. Because 'secure' is weighted against your maximum effort, not your minimum (which is letting others, such as the OS, cope). So either it's not an issue your system will protect against, really (i.e. a threat vector listed as 'not protected against beyond the ability of the operating system' -- one human error is enough to get at the goodies), or you need to sit back and rethink the system. Given that you intend to apply the full cryptographic strength available today against attackers who can read those backup files, the question to pose to yourself is: against whom do you want to protect? How much? I.e. where are your attackers? How can they touch you? And which ones do you ignore == list as the responsibility of other systems/parts, such as 'the operating system' or 'the firewall'? Which are viable choices. Basic approach is that you're aware of all your systems conditions and limitations, threat-wise. That's also why, in designs such as yours (backups secured against unauthorized access) firewalls and other components play an important role i
BIO_renegotiate_timeout and BIO_renegotiate_bytes
I'm having trouble getting BIO_renegotiate_timeout() and BIO_renegotiate_bytes to work, and I'm hoping someone can help me out with what I'm doing wrong. The socket is initially opened and a connection accepted, and then I setup SSL with the following. SSL* ssl = SSL_new(ctx); BIO* bio = BIO_new_socket((int)fd, 0); SSL_set_bio(ssl, bio, bio); I then do the following to configure the auto renegotiation. BIO* rbio = SSL_get_rbio(ssl); BIO_set_ssl_renegotiate_bytes(rbio, 1024*1024); BIO_set_ssl_renegotiate_timeout(60); Our client/server protocol involves a heartbeat once per second, and in there I'm printing out the return value of BIO_get_num_renegotiates(SSL_get_rbio(ssl)) but it's always 0. Is there some other sort of configuration I need to be doing to get this to work? I've seen other people ask about this on the list, but never any responses. Is anyone using this successfully? Thanks, Wayne. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
Unsticking foot for 60 seconds - and, yes, this time I checked before I blab. Let's hope I checked enough: On Thu, Oct 1, 2009 at 11:25 PM, Michael D. Adams wrote: > Any normal user on a Linux machine would be able to see 'ps -f'. But > to 'cat' the keyfile or coredump the app, they would need to either for cat I don't need to be root; all it takes is a simple mistake in the file access rights for world or group. I can cat a file with world rights if I know it's path and that can be deduced from the ps output. When I'm in the same group as the owner, same again, but now for group rights, so something like chmod 0400 keyfile would be mandatory when creating it. and, yup, coredumping and such takes more effort. Was just thinking out loud. The point of my original blurb was to hint that going keyfile is not improving security all that much, at least not in arenas where terms like 'cryptographic strength' etc. come into play as well; generating a MAC is using crypto, so you're landed in that arena at least implicitly. Crypto folks tend to regard the word 'security' differently than others, at least we're I am; it's like regular people 'thanking them' versus a navy captain 'thanking them' (at least that's the literal translation for it from Dutch; don't know the precise US or English military lingo for this) - /exact/ same words, /quite/ different impact. (Hint: in the latter case you won't get a handshake, once there's time you'll get a salute, but it might take a while. There might be medals for you, though.) Alas, enough of this already. One bloody word, such a mess. At least now I know why PC popped into my brain back then. Simple words. Big messes. >From a pure usage perspective, having the test tools support a commandline format for keys where you can say things like 'literal:mykey' or 'file:keyfile' to the same command option is a nice idea to have throughout. Hm, maybe a patch for that can appease my lordship(s) ;-) Sticking foot back in... -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 4:37 PM, Kyle Hamilton wrote: > The question becomes more one of: Why does the OP need to keep the > HMAC computation key secret? Is the OP using the same key for HMAC > calculation as for symmetric encryption? (If so, why? If not, why > does the OP need to keep the verification key secret?) I'm not using the same key for HMAC as for symmetric encryption. It was my understanding that the HMAC key needed to be secret even when used for verification. (Otherwise people could forge an HMAC.) But you ask a fair question (i.e. Why keep the key secret?) and I'll try to answer. I'm not using an HMAC for message authentication, but for a more indirect purpose. (I apologize in advance for the length, explaining "why" requires a little context.) I am working with a backup system where the files are stored and referenced by their hash (similar to how git stores it's data). I would like to make it be able to store those files in encrypted form. In order for this system to work, we want two different encryptions of the same file with the same key to produce the exact same result. This rules out using a random initialization vector (IV). With the exception of SIV (which isn't yet widely implemented), my understanding is that reusing an IV for two different messages opens up avenues of crypto-analytical attack. Thus we want to use a different IV for each file, but use the same IV when the file contents are the same (*). The obvious choice is to use a cryptographic hash of the file's contents as the IV. It will be the same when the file contents are the same, but different when the file contents are different. Now that works great except for one thing. For simplicity of implementation, we would like to store that calculated IV in clear text as a header at the front of the encrypted file and then just use one of the block-cipher modes that remains secure even when the IV is known to the attacker. However, storing the IV in the clear opens up a dictionary attack if the attacker can easily compute the hash used to compute the IV (**). To get around this, I was planning on using a secret key with an HMAC (so the attacker couldn't compute his own hashes), but passing that key on the command leaks that secret key. To summarize: I would have done this: let IV = Hash(file) in concatenate(IV, encrypt(IV, Key2, file)). Except that sending IV in the clear opens a dictionary attack on the contents of file. So to fix that I was going to do this: let IV = HMAC(Key1, file) in concatenate(IV, encrypt(IV, Key2, file)). Except that doesn't gain anything over the previous one if Key1 isn't kept secret. So now what I'm thinking is to do this: let IV = encrypt(one-block-mode(***), Key1, Hash(file)) in concatenate(IV, encrypt(IV, Key2, file)). Again, sorry for the length, but I hope that de-mystifies some of why I want to keep the key secret. (*) Yes, this would open up a dictionary attack if the attacker could use the backup system as an encryption oracle. Fortunately, due to external factors, in our situation the attacker can't inject arbitrary data into the backup system and thus can't use it as an oracle. (**) This is the same dictionary attack as in "(*)" except that now the attacker is attacking the IV and doesn't need to use the backup system as an oracle. He can just run the hash algorithm himself. (***) We don't need a block-cipher mode here (it's basically ECB mode) if we ensure that the hash length matches the cipher block length. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 5:44 PM, Michael S. Zick wrote: > Misplaced security barrier - > The user should be sufficiently security qualified to see what they type. > Everbody in the same room should be sufficiently security qualified > to see anything typed within that room. > The room should be sufficiently security qualified to exclude others. > > In some installations, the red lights on the walls and ceilings flash > and the screens are all blanked if someone with less than a certain > minimum security qualification level is allowed entry. > And if that unqualified person unblanks a screen and types ps -f : simple, > shoot them. > (I was one of the guys that carried the gun in the room for years.) > > Other than those operational procedures, you should at least write > your own application that does not disclose what you want hidden. With "ps -f" someone else in *another* room can see the command line arguments of programs that I run. You wouldn't "chmod a+r" your key files now would you? Having key contents appears as a command line argument does effectively that for the duration of the command execution. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 10:33 PM, wrote: > admin# echo 100 > /tmp/p.txt > admin# sleep `cat /tmp/p.txt` & > [1] 21988 > admin# ps -ef | grep sleep | grep -v grep > root 21988 3150 0 22:29 pts/0 00:00:00 sleep 100 Dang. Buggerit buggerit buggerit. Yep, you're absolutely right. How long should I keep my foot in my mouth this time? I can't guarantee you I'll learn from the experience but at least it will be one less unintelligent input for the duration. Hm, now I should go and see how I can redeem myself... ... -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
validating signature against cert
Hi all...I'm having a bit of trouble with openssl and I was hoping someone here might point me in the right direction. I've been given an X509 signing certificate that I’m storing in base64 format along with a SHA1 w/ RSA signature. How do I verify that signature against the signing certificate via openssl? Any help would be appreciated. Best, Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu October 1 2009, Michael D. Adams wrote: > On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt wrote: > > A note about your mention of 'security leak': when you are worried > > about adversaries who can run 'ps -l' on your machine, then you're > > essentially worried about adversaries with plenty of access to your > > machine, so they'll quite probably be able to 'cat' that keyfile > > Any normal user on a Linux machine would be able to see 'ps -f'. But > to 'cat' the keyfile or coredump the app, they would need to either > (1) have root access, or (2) have cracked the machine. In my mind > there is a large leap between 'normal users could get this secret > info' and 'user's with root access could get this secret info'. > Misplaced security barrier - The user should be sufficiently security qualified to see what they type. Everbody in the same room should be sufficiently security qualified to see anything typed within that room. The room should be sufficiently security qualified to exclude others. In some installations, the red lights on the walls and ceilings flash and the screens are all blanked if someone with less than a certain minimum security qualification level is allowed entry. And if that unqualified person unblanks a screen and types ps -f : simple, shoot them. (I was one of the guys that carried the gun in the room for years.) Other than those operational procedures, you should at least write your own application that does not disclose what you want hidden. Mike > Michael D. Adams > __ > 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: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt wrote: > A note about your mention of 'security leak': when you are worried > about adversaries who can run 'ps -l' on your machine, then you're > essentially worried about adversaries with plenty of access to your > machine, so they'll quite probably be able to 'cat' that keyfile Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either (1) have root access, or (2) have cracked the machine. In my mind there is a large leap between 'normal users could get this secret info' and 'user's with root access could get this secret info'. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 01, 2009, Michael D. Adams wrote: > How would I securely compute a MAC for a file? The obvious way > (below) has a security leak as it puts the key on the command line > which other users could easily observe with "ps -f". > > $ openssl dgst -sha1 -hmac > > I would have thought that something like "openssl enc" has with "-pass > file:" would be available, but I haven't been able to find an > equivalent for "openssl dgst" (even the 1.0beta's "-macopt" flag > doesn't do this). > > Am I missing something here? What is the proper way to compute a MAC > on the command line? > Well the openssl utility is a test utility and if you really want something secure you should write a custom program. Writing one for hmac shouldn't take more than a few lines. For 1.0.0 MAC support is included which treats it as a signature algorithm where the "key" just happens to be an unstructured stream of bytes. You can even use pseudo pem files which can be "generated". For example: openssl genpkey -algorihm hmac -pkeyopt key:hello -out hmac.pem openssl sha1 -sign hmac.pem -hex somefilename The actual "key" is just the base64 encoded MAC key with headers included. 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: Secure Command Line MAC Computation
`cat keyfile` is processed by the shell, not by OpenSSL. That means that the backquotes are processed and stripped before the OpenSSL process ever sees it, which means that the shell is going to execute the cat and then will execute the dgst with the commandline including the contents of the cat. Which means that the ps problem actually still exists: $ openssl dgst -hmac `cat keyfile` -sha1 file -> $ openssl dgst -hmac 'whatever keyfile contains' -sha1 file Other than that, I agree with your analysis. (Note that keyfile can be a binary file in this method, and the shell won't get confused, since it just puts the output of the cat into a single **argv. This expands the number of possible hmac keys from "the union of possibility and the effect of the shell's metacharacter modification" to "the union of possibility". But, remember that you need to *not* include a newline at the end of the file, unless the newline is part of the key.) The question becomes more one of: Why does the OP need to keep the HMAC computation key secret? Is the OP using the same key for HMAC calculation as for symmetric encryption? (If so, why? If not, why does the OP need to keep the verification key secret?) -Kyle H On Thu, Oct 1, 2009 at 1:24 PM, Ger Hobbelt wrote: > ;-) Of course, you always could go an use shell backquoting, e.g. > > dgst -hmac `cat keyfile` ... > > assuming the 'keyfile' is in the proper format already. > > > A note about your mention of 'security leak': when you are worried > about adversaries who can run 'ps -l' on your machine, then you're > essentially worried about adversaries with plenty of access to your > machine, so they'll quite probably be able to 'cat' that keyfile > (proper access control (ACL) being the only thing keeping them from > doing so) and/or coredumping your running [OpenSSL] app so they can > get at the key in RAM through the core file at their leasure. > The other kind of 'adversary' that's to consider when using a screen > (with or without commandline) is the observant individual nearby or > far away, who can read what you type or see what is visible on your > screen (keys and passphrases which are not 'starred out'). > > If the latter blurb has you going 'whoa! over the top!' then no > worries; just a friendly reminder. threat analysis can quickly make > you go 'oh sh*t' and it's never simple. You asked about 'how do I > /securely/ ...' (emphasis mine) so I thought a little nudge would be > good. In some environments some words carry more meaning than a simple > 'lunch'. (Why do I get these goosebumps now while my brain delivers > the quite unwanted words 'politically correct' in my neocortex? eek!) > > When your purpose is to have the command run in a 'any viewer cannot > directly glean key from screen or tasklist while I run this' the `cat > file` backquoting will suffice. > > Otherwise, I'd say it's the 'proper way' to calculate a [H]MAC. > > > > On Thu, Oct 1, 2009 at 9:20 PM, Michael D. Adams wrote: >> How would I securely compute a MAC for a file? The obvious way >> (below) has a security leak as it puts the key on the command line >> which other users could easily observe with "ps -f". >> >> $ openssl dgst -sha1 -hmac >> >> I would have thought that something like "openssl enc" has with "-pass >> file:" would be available, but I haven't been able to find an >> equivalent for "openssl dgst" (even the 1.0beta's "-macopt" flag >> doesn't do this). >> >> Am I missing something here? What is the proper way to compute a MAC >> on the command line? >> >> Michael D. Adams >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-us...@openssl.org >> Automated List Manager majord...@openssl.org >> > > > > -- > Met vriendelijke groeten / Best regards, > > Ger Hobbelt > > -- > web: http://www.hobbelt.com/ > http://www.hebbut.net/ > mail: g...@hobbelt.com > mobile: +31-6-11 120 978 > -- > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@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: Secure Command Line MAC Computation
Hello, owner-openssl-us...@openssl.org wrote on 10/01/2009 10:24:11 PM: > Ger Hobbelt > Sent by: owner-openssl-us...@openssl.org > ;-) Of course, you always could go an use shell backquoting, e.g. > > dgst -hmac `cat keyfile` ... > > assuming the 'keyfile' is in the proper format already. admin# echo 100 > /tmp/p.txt admin# sleep `cat /tmp/p.txt` & [1] 21988 admin# ps -ef | grep sleep | grep -v grep root 21988 3150 0 22:29 pts/000:00:00 sleep 100 Best regards, -- Marek Marcola __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
;-) Of course, you always could go an use shell backquoting, e.g. dgst -hmac `cat keyfile` ... assuming the 'keyfile' is in the proper format already. A note about your mention of 'security leak': when you are worried about adversaries who can run 'ps -l' on your machine, then you're essentially worried about adversaries with plenty of access to your machine, so they'll quite probably be able to 'cat' that keyfile (proper access control (ACL) being the only thing keeping them from doing so) and/or coredumping your running [OpenSSL] app so they can get at the key in RAM through the core file at their leasure. The other kind of 'adversary' that's to consider when using a screen (with or without commandline) is the observant individual nearby or far away, who can read what you type or see what is visible on your screen (keys and passphrases which are not 'starred out'). If the latter blurb has you going 'whoa! over the top!' then no worries; just a friendly reminder. threat analysis can quickly make you go 'oh sh*t' and it's never simple. You asked about 'how do I /securely/ ...' (emphasis mine) so I thought a little nudge would be good. In some environments some words carry more meaning than a simple 'lunch'. (Why do I get these goosebumps now while my brain delivers the quite unwanted words 'politically correct' in my neocortex? eek!) When your purpose is to have the command run in a 'any viewer cannot directly glean key from screen or tasklist while I run this' the `cat file` backquoting will suffice. Otherwise, I'd say it's the 'proper way' to calculate a [H]MAC. On Thu, Oct 1, 2009 at 9:20 PM, Michael D. Adams wrote: > How would I securely compute a MAC for a file? The obvious way > (below) has a security leak as it puts the key on the command line > which other users could easily observe with "ps -f". > > $ openssl dgst -sha1 -hmac > > I would have thought that something like "openssl enc" has with "-pass > file:" would be available, but I haven't been able to find an > equivalent for "openssl dgst" (even the 1.0beta's "-macopt" flag > doesn't do this). > > Am I missing something here? What is the proper way to compute a MAC > on the command line? > > Michael D. Adams > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Secure Command Line MAC Computation
How would I securely compute a MAC for a file? The obvious way (below) has a security leak as it puts the key on the command line which other users could easily observe with "ps -f". $ openssl dgst -sha1 -hmac I would have thought that something like "openssl enc" has with "-pass file:" would be available, but I haven't been able to find an equivalent for "openssl dgst" (even the 1.0beta's "-macopt" flag doesn't do this). Am I missing something here? What is the proper way to compute a MAC on the command line? Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CRLs from CrlDistributionPoints
Hi, I want to implement HTTP download of CRLs from cert's CrlDistributionPoints in my application (if any) and include them in the verify process. What was best practice or best design to do this with OpenSSL? Are there certain callbacks I should use? Or even a sample I missed in the source code? -- Arno Garrels __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Segmentation fault in ssl3_read_n and shortened stack strace
We are using openssl-32bit-0.9.8a-18.26 on SLES 10.2 (x86_64). This problem is only occurring on a very small percentage of our installs, and is not readily repeatable, but is always results in the same back trace. Program terminated with signal 11, Segmentation fault. #0 0xb7bf54e3 in ssl3_read_n () from /usr/lib/libssl.so.0.9.8 (gdb) bt #0 0xb7bf54e3 in ssl3_read_n () from /usr/lib/libssl.so.0.9.8 #1 0x in ?? () (gdb) quit I'm digging into this issue more and can provide more information when I get it as far as what is calling ssl_read_n and what is being passed in. I have two questions right now though: 1) Are there any known issues as to why ssl3_read_n would cause a segmentation fault? 2) Is there any know reason why the call trace would be truncated? There is nothing past #1) and the other threads have clean call traces. Dwight Schauer dscha...@buchanan.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Second key in 3DES?
Joe Novak wrote: > Hi, > I'm using the EVP_ set of function calls to interface to > 2-key 3DES. I see how to set the first key in EVP_EncryptInit > but I do not see how to set the second key. Is it possible > with the EVP_ calls or do I need to use the lower-level DES_ > functions? Thanks. > Joe That 3DES internally splits the key is an implementation detail that users of the EVP_* interface need not concern themselves with. If you have the two individual DES keys, you should combine them into a single 3DES key and pass that to the EVP_EncryptInit function. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OCSP servergoes down when bad request
Hi everyone, I'm facing a problem setting up an OCSP Responder for internal use in my application. I've set up an internal CA for my application to authorize my users to access to it. When a user logs on I check its certificate using an OCSP request which is sent to openssl ocsp server. Everything works fine but my openssl ocsp server breaks down when it receives a bad OCSP request or if I simply try to connect to its port to check if it's up or down. Could anyone help me to keep this server up whatever happens? Thanks a lot, Regards Vicente Guardiola
