From m@mbsks.franken.de Wed Apr 4 11:36:43 2001 From: m@mbsks.franken.de (m@mbsks.franken.de) Date: Wed, 4 Apr 2001 12:36:43 +0200 Subject: [Cryptlib] Lightning damage Message-ID: <20010404123643.A19007@mbsks.franken.de> Mahlzeit I had a lighting damage one and a halve weeks ago and had to buy a new computer. I hope my new installation is now working. The webinterface is not working because of no permanent internet connection. Mahlzeit endergone Zwiebeltuete From exelrud@usa.net Wed Apr 4 13:55:57 2001 From: exelrud@usa.net (Jacques Exelrud) Date: Wed, 4 Apr 2001 09:55:57 -0300 Subject: [Cryptlib] Re: Welcome to the "Cryptlib" mailing list Message-ID: <000d01c0bd06$9a9e6860$4102330a@mc015> Is the list changing or this message was sent by mistake ? The urls are pointing to localhost. Jacques From m@mbsks.franken.de Wed Apr 4 14:57:41 2001 From: m@mbsks.franken.de (m@mbsks.franken.de) Date: Wed, 4 Apr 2001 15:57:41 +0200 Subject: [Cryptlib] Re: Welcome to the "Cryptlib" mailing list In-Reply-To: <000d01c0bd06$9a9e6860$4102330a@mc015>; from exelrud@usa.net on Wed, Apr 04, 2001 at 09:55:57AM -0300 References: <000d01c0bd06$9a9e6860$4102330a@mc015> Message-ID: <20010404155741.D20123@mbsks.franken.de> Mahlzeit On Wed, Apr 04, 2001 at 09:55:57AM -0300, Jacques Exelrud wrote: > Is the list changing or this message was sent by mistake ? > The urls are pointing to localhost. You can not access the mailinglist by the web interface because it has no permanent internet connection. You have to use cryptlib-request@mbsks.franken.de. I will change the address in the wellcome mail to something really meaningless. Mahlzeit endergone Zwiebeltuete From cryptlib@mbsks.franken.de Thu Apr 5 03:51:50 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 5 Apr 2001 02:51:50 (NZST) Subject: [Cryptlib] (no subject) Message-ID: <98639591002076@kahu.cs.auckland.ac.nz> Gary Jones writes: >I rebuilt cryptlib under Microsoft Visual C++ and the build runs fine but, I'm >still getting the stack overflow error. > >Do you have any other ideas? It sounds like something specific to your system, because I've never heard of this anywhere else. Did you make any changes to the code? Have you tried downloading a fresh copy and building that? Peter. From cryptlib@mbsks.franken.de Thu Apr 5 16:34:12 2001 From: cryptlib@mbsks.franken.de (Kay Behnke) Date: Thu, 5 Apr 2001 17:34:12 +0200 Subject: [Cryptlib] Constraint in key usage parameter of certificates Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C0BDF6.A179EA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 We use cryptlib in a quite large project for the Dutch ministry of = finance. Since a while we have some problems in checking the = certificates of a particular CA. The reason for this problem is that the = functions cryptCheckCert () returns an error which indicates that the = values for the attribute =91keyUsage=92 are inconsistent with each = other. Well, this is actually true but nevertheless we would like to use = these certificates with these values for the keyUsage parameter = (political reasons =85). In addition, as far as I knows, the RFC = specification allows =93any=94 combination of keyUsage values =85 ok, I = know that makes no sense, but the CA organization points to the = corresponding RFC =85=20 =20 Question to Peter or anyone who can give us an answer: How can I =93switch off=94 the consistency check in the cryptlib code? =20 Thanks for any quick reply, =20 Kay Behnke =20 =20 ------=_NextPart_000_0000_01C0BDF6.A179EA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

We use cryptlib in a quite = large project for the Dutch ministry of finance. Since a while we have some = problems in checking the certificates of a particular CA. The reason for this = problem is that the functions cryptCheckCert () returns an error which indicates = that the values for the attribute ‘keyUsage’ are inconsistent with each = other. Well, this is actually true but nevertheless we would like to use these certificates = with these values for the keyUsage parameter (political reasons …). In = addition, as far as I knows, the RFC specification allows “any” = combination of keyUsage values … ok, I know that makes no sense, but the CA organization = points to the corresponding RFC …

 

Question to Peter or anyone = who can give us an answer:

How can I “switch = off” the consistency check in the cryptlib = code?

 

Thanks for any quick = reply,

 

Kay = Behnke

 

 

------=_NextPart_000_0000_01C0BDF6.A179EA60-- From cryptlib@mbsks.franken.de Thu Apr 5 16:38:41 2001 From: cryptlib@mbsks.franken.de (Kay Behnke) Date: Thu, 5 Apr 2001 17:38:41 +0200 Subject: [Cryptlib] cryptlib and LDAP Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C0BDF7.410B3840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I still have another question. We wrote a small program which connects = to an LDAP server in order to retrieve a certificate or CRL from it. No = big deal. However, running this program under Linux (2.2.18, libc 2.2) = results in a segmentation fault, running the SAME code under Windows = (NT, 95, 2000) or AIX (4.x) results in no errors at all. We tried two = LDAP libraries, version 4.1 and 3.0, but that made no difference. =20 Are there any know problems with LDAP and cryptlib under Linux? =20 Thanks for any reply, =20 Kay Behnke =20 ------=_NextPart_000_0003_01C0BDF7.410B3840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I still have another = question. We wrote a small program which connects to an LDAP server in order to = retrieve a certificate or CRL from it. No big deal. However, running this program = under Linux (2.2.18, libc 2.2) results in a segmentation fault, running the = SAME code under Windows (NT, 95, 2000) or AIX (4.x) results in no errors at all. = We tried two LDAP libraries, version 4.1 and 3.0, but that made no = difference.

 

Are there any know problems = with LDAP and cryptlib under Linux?

 

Thanks for any = reply,

 

Kay = Behnke

 

------=_NextPart_000_0003_01C0BDF7.410B3840-- From cryptlib@mbsks.franken.de Wed Apr 4 18:05:16 2001 From: cryptlib@mbsks.franken.de (Thomas Schoessow) Date: Wed, 4 Apr 2001 19:05:16 +0200 Subject: [Cryptlib] Re: Cryptlib and Towitoko References: <98574806118202@kahu.cs.auckland.ac.nz> Message-ID: <00fb01c0bd29$6c2a8a90$0a000082@home.schoessow.de> Hi Peter, does that mean, that I cannot use Towitoko ? How about IKeys 2000/ 20032 = ? Regards Thomas -----Urspr=FCngliche Nachricht-----=20 Von: "Peter Gutmann" An: Gesendet: Mittwoch, 28. M=E4rz 2001 14:54 Betreff: [Cryptlib] Re: Cryptlib and Towitoko > "Thomas Schoessow" writes: >=20 > >I would like to use a 44C80 prozessor card (8000 byte eeprom) with = crypto > >functions for keeping the certs as secure as possible. As I didn't = found much > >information on those topic in the help manual, my question is: > > > >- Does anybody use this constellation cryptlib and towitoko (with cpu = cards) > >?. Are there any known "caveats" ? Is there a "list" of "known to be = good" > >cards for the use with towitoko available ? >=20 > It's not the reader and card type which is important, it's whether = there's a > PKCS #11 driver for them. AFAIK there isn't one for either the card = or the > reader, only the 66CX160 has PKCS #11 drivers, and the only PKCS #11 = driver > which works with the Towitoko readers which I know of isn't publicly = available > (there may be others which work via PC/SC, but I haven't been keen on > reinstalling the drivers ever since either the Towitoko or Gemplus = ones trashed > the NT machine I was using for testing). >=20 > Peter. >=20 >=20 > _______________________________________________ > Cryptlib mailing list > Cryptlib@mbsks.franken.de > http://localhost/mailman/listinfo/cryptlib >=20 From cryptlib@mbsks.franken.de Thu Apr 5 12:18:34 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 5 Apr 2001 11:18:34 (NZST) Subject: [Cryptlib] cryptlib beta 5 available + RSA conference Message-ID: <98642631404247@kahu.cs.auckland.ac.nz> It's now available in the usual place along with an updated manual. For the next week or so I'll be at the RSA conference in San Francisco, in case anyone wants to say hi there's a good chance I'll be at the Cryptographic Appliances stand, or failing that wandering around the show floor collecting souvenirs. In addition it's unlikely I'll be able to respond to any mail until I get back the following week. Peter. From cryptlib@mbsks.franken.de Sat Apr 7 13:15:38 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Sat, 7 Apr 2001 12:15:38 (NZST) Subject: [Cryptlib] Constraint in key usage parameter of certificates Message-ID: <98660253813490@kahu.cs.auckland.ac.nz> "Kay Behnke" writes: >We use cryptlib in a quite large project for the Dutch ministry >of finance. Since a while we have some problems in checking the >certificates of a particular CA. The reason for this problem is >that the functions cryptCheckCert () returns an error which >indicates that the values for the attribute M-^QkeyUsageM-^R are >inconsistent with each other. Well, this is actually true but >nevertheless we would like to use these certificates with these >values for the keyUsage parameter (political reasons M-^E). In >addition, as far as I knows, the RFC specification allows >M-^SanyM-^T combination of keyUsage values M-^E ok, I know that >makes no sense, but the CA organization points to the >corresponding RFC M-^E What's the conflict? I'm guessing it's something like a cert which has a keyUsage of keyAgreement even though the key is incapable of doing key agreement? (I've seen Diginotar's braindamage before). >Question to Peter or anyone who can give us an answer: >How can I M-^Sswitch offM-^T the consistency check in the cryptlib code? You can't, the code is telling you that the certificate key usage is claiming something which isn't valid, which is exactly what the cert validity check is meant to do. If you want disable this check, you'd have to edit the code in keymgmt/certchk.c. Peter. From cryptlib@mbsks.franken.de Sat Apr 7 13:08:37 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Sat, 7 Apr 2001 12:08:37 (NZST) Subject: [Cryptlib] cryptlib and LDAP Message-ID: <98660211713438@kahu.cs.auckland.ac.nz> "Kay Behnke" writes: >I still have another question. We wrote a small program which connects >to an LDAP server in order to retrieve a certificate or CRL from it. No >big deal. However, running this program under Linux (2.2.18, libc 2.2) >results in a segmentation fault, running the SAME code under Windows >(NT, 95, 2000) or AIX (4.x) results in no errors at all. We tried two >LDAP libraries, version 4.1 and 3.0, but that made no difference. > >Are there any know problems with LDAP and cryptlib under Linux? I've never tried it under Linux, and given the lack of generally-available LDAP cert stores I haven't tried it much under Windows either since the one I'd been using for testing shut down or went away or generally ceased to exist. Could you step into the code to see where the problem is? In particular, beta 5 contains some new workarounds for incompatibilities/bugs in LDAP libraries, but this sounds like something which is specific to the Linux LDAP client. Peter. From cryptlib@mbsks.franken.de Sat Apr 7 13:04:51 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Sat, 7 Apr 2001 12:04:51 (NZST) Subject: [Cryptlib] Re: Cryptlib and Towitoko Message-ID: <98660189113482@kahu.cs.auckland.ac.nz> "Thomas Schoessow" writes: >does that mean, that I cannot use Towitoko ? You can only use it with a device for which there's a PKCS #11 driver. >How about IKeys 2000/ 20032 ? They use the Datakey driver, so they should be OK. Peter. From cryptlib@mbsks.franken.de Mon Apr 9 13:39:12 2001 From: cryptlib@mbsks.franken.de (Michael Condillac) Date: Mon, 9 Apr 2001 13:39:12 +0100 Subject: [Cryptlib] Error importing session key. In-Reply-To: <98660211713438@kahu.cs.auckland.ac.nz> Message-ID: Hi, Im developing an application that sends a message around a network. The message is encrypted using a session key that is signed using each of the nodes public keys. The signed session key is appended to the message. so i have < Data > The first call to my function that retrieves the signed key works correctly and i can import and decode the data. The second call to import signed key1 returns Crypt_Cursor_Next, ie. -22 I would post my code if that would help. Thanks, Michael From cryptlib@mbsks.franken.de Tue Apr 10 10:10:23 2001 From: cryptlib@mbsks.franken.de (Fidel Liberal Malaina) Date: Tue, 10 Apr 2001 11:10:23 +0200 (CEST) Subject: [Cryptlib] Cryplib and threads Message-ID: First of all, hello to everybody in the list. I'm a last degree student of Telecommunications Eng. in Bilbao, Spain. My graduation project consists on developing a PKIX compliant PKI system and I'm thinking of Cryptlib to provide the crypto-interface. Taking a glance at the library it's supposed to be thread-safe but my first efforts are not quite successful. My System: RedHat Linux 7.0 (I don`t think Kernel, memory and glibc are important) I'm trying to make an example threaded-dummy-ssh-client as follows: #include ..... CRYPT_SESSION cryptSession; void *listen_server(void); main() { initialise cryptlib; set Session parameters; Activate_session ; SUCCESS! I do make the connection and receive data THREAD_CREATE(listen_server,null); ^^^^^^^^^^^^^^^^ ^^ ^^^^^^^^^^ ^^ while(1) { cryptPushData(cryptSession,buffer,sizeof(buffer),NULL); cryptPushData(cryptSession,NULL,0,NULL); } void *listen_server (void) { int read_bytes=0; ...... while(1) { cryptPopData(cryptSession,buffer2,sizeof(buffer2),&read_bytes); buffer2[read_bytes]='\0'; printf("%s",buffer2); } } I compile with no-erros but after connecting with ssh server I always get a Segmentation Fault. When I execute listen_server from the main function it works well. One more question: Why in the test examples provided with the library they use delayThread() between each push - pop? Is there any blocking alternatives to cryptPop and cryptPush? Any idea? Thanks in advance. Fidel Liberal Malaina ETSI, Bilbao Spain From cryptlib@mbsks.franken.de Wed Apr 11 09:43:30 2001 From: cryptlib@mbsks.franken.de (David Maurus) Date: Wed, 11 Apr 2001 10:43:30 +0200 Subject: [Cryptlib] Cryplib and threads References: Message-ID: <3AD41932.F617ED0D@mailbag.de> Hi, Fidel Liberal Malaina wrote: > I compile with no-erros but after connecting with ssh server I always get > a Segmentation Fault. When I execute listen_server from the main function > it works well. > I haven't used cryptlib yet, but generally if a library is considered /threadsafe/, that doen't imply that you can use its session variables accross threads. So it could very well be that you will have to create a CRYPT_SESSION for each thread that will use the library. (I might be wrong - I hope someone will correct me if that's the case.) Best Regards, David From cryptlib@mbsks.franken.de Wed Apr 11 17:27:31 2001 From: cryptlib@mbsks.franken.de (Liberal Malaina Fidel) Date: Wed, 11 Apr 2001 18:27:31 +0200 (CEST) Subject: [Cryptlib] Cryplib and threads In-Reply-To: <3AD41932.F617ED0D@mailbag.de> Message-ID: On Wed, 11 Apr 2001, David Maurus wrote: > haven't used cryptlib yet, but generally if a library is considered > /threadsafe/, that doen't imply that you can use its session variables accross > threads. So it could very well be that you will have to create a CRYPT_SESSION > for each thread that will use the library. (I might be wrong - I hope someone > will correct me if that's the case.) > > Best Regards, > David Thanks for your answer but if you create a CRYPT_SESSION for each thread how will you share information between diferent CRYPT_SESSION structures?. I mean that both structures must share at leat session key and, at lower level, the socket (o binding to the TCP port) to attend the communication. Instead of using threads I tried to use processes and everything runs right but changing fork() by pthread_create produces SEGFAULT again. Any other ideas? Is David's approach more suitable than using a global variable (as you do when you use only socket, no encryption? Fidel Liberal Malaina ETSI, Bilbao Spain From cryptlib@mbsks.franken.de Thu Apr 12 08:18:02 2001 From: cryptlib@mbsks.franken.de (Eric Schreuder) Date: Thu, 12 Apr 2001 09:18:02 +0200 Subject: [cryptlib] Constraint in key usage parameter of certificates Message-ID: <000b01c0c320$b769ade0$4601a8c0@imnla291> Hi Peter, Kay is one of my collegues, and he discussed this subject last week with you. Now I am responsible for patching keymgmt/certchk.c.Something I don't like to do, because I think cryptlib is right about the inconsistency. Only the CA still does not want to see it. While putting a debugger on de cryptCheckCert() function, I learned the following (which is a little bit different from the story Kay wrote you): - key usage is "Key Encipherement" and "Data Encipherement" - one of the extended key usage attributes is "Client Authentication (1.3.6.1.5.5.7.3.2)" The other extended key usage attributes defined in the certificate are: Secure Email (1.3.6.1.5.5.7.3.4) IP security user (1.3.6.1.5.5.7.3.7) Encrypting File System (1.3.6.1.4.311.10.3.4) >From the debugging session, I conclude that because of the extended key usage attribute "Client Authentication", cryptlib expects a key usage "Digital Signature", and because there is no key usage "Digital Signature" in the certificate, the certificate is declared "invalid". Can you please confirm (or deny) my conclusion, I am a bit confused about all the bit fiddling that takes place in certchk.c. Kind regards, Eric Schreuder "Kay Behnke" writes: >We use cryptlib in a quite large project for the Dutch ministry >of finance. Since a while we have some problems in checking the >certificates of a particular CA. The reason for this problem is >that the functions cryptCheckCert () returns an error which >indicates that the values for the attribute M-^QkeyUsageM-^R are >inconsistent with each other. Well, this is actually true but >nevertheless we would like to use these certificates with these >values for the keyUsage parameter (political reasons M-^E). In >addition, as far as I knows, the RFC specification allows >M-^SanyM-^T combination of keyUsage values M-^E ok, I know that >makes no sense, but the CA organization points to the >corresponding RFC M-^E What's the conflict? I'm guessing it's something like a cert which has a keyUsage of keyAgreement even though the key is incapable of doing key agreement? (I've seen Diginotar's braindamage before). >Question to Peter or anyone who can give us an answer: >How can I M-^Sswitch offM-^T the consistency check in the cryptlib code? You can't, the code is telling you that the certificate key usage is claiming something which isn't valid, which is exactly what the cert validity check is meant to do. If you want disable this check, you'd have to edit the code in keymgmt/certchk.c. Peter. From cryptlib@mbsks.franken.de Thu Apr 12 09:51:07 2001 From: cryptlib@mbsks.franken.de (Luciano Benetti) Date: Thu, 12 Apr 2001 09:51:07 +0100 Subject: [Cryptlib] (no subject) Message-ID: <003c01c0c32d$b6e8d230$05c8a8c0@dummy.net> This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C0C336.189656D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am writing to as for some help with the Cryptolib. I am using the = Beta 5 with Delphi. When I use the codes listed below, I get an error = (-2) =20 status :=3D = cryptGetAttributeString(signatureKeyContext,CRYPT_CERTINFO_SERIALNUMBER,@= valore,k); =20 =20 I was previously using the Beta 4 and it worked fine. If I try to read = something, such as: CRYPT_CERTINFO_ORGANIZATIONNAME=20 =20 It works just fine. Have you changed something with the Beta 5 version? = If you could please offer some assistance to me it would be greatly = appreciated.=20 =20 Thank you,=20 =20 Luciano Benetti ------=_NextPart_000_0039_01C0C336.189656D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am writing to as for some help with the Cryptolib.  I am = using the=20 Beta 5 with Delphi.  When I use the codes listed below, I get an = error=20 (-2)
 
status :=3D=20 cryptGetAttributeString(signatureKeyContext,CRYPT_CERTINFO_SERIALNUMBER,@= valore,k); =20
 
I was previously using the Beta 4 and = it worked=20 fine.  If I try to read something, such as:=20 CRYPT_CERTINFO_ORGANIZATIONNAME
 
It works just fine.  Have you changed something with the = Beta 5=20 version? If you could please offer some assistance to me it would be = greatly=20 appreciated.
 
Thank you,
 
Luciano Benetti
------=_NextPart_000_0039_01C0C336.189656D0-- From cryptlib@mbsks.franken.de Thu Apr 12 14:53:32 2001 From: cryptlib@mbsks.franken.de (Susanna Bessone) Date: Thu, 12 Apr 2001 15:53:32 +0200 Subject: [Cryptlib] Secure session Message-ID: <002c01c0c357$fbf23720$2d07020a@sirio> Hi, I'm trying to perform data exchange between a server and a pc. As written in your last security toolkit (beta 5), the SSL/TLS client code is still under constraction: is there another way to handle a secure session? Is it possible to extract the content of a context (in my case the content is the session key encrypted with a pubblic key) and copy it on a file? Thanks Susanna From cryptlib@mbsks.franken.de Thu Apr 12 19:04:55 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Thu, 12 Apr 2001 20:04:55 +0200 (MET DST) Subject: [Cryptlib] Key exchange needed Message-ID: Hi to all cryptlib developers! I've encountered a serious problem with cryptlib during my developing work. I have to set up a link encrypted socket between two components of a software. There's a kludge wrning in the manual and in the old beta02a testlib too. The manual says that no key exchange protocol supported, but there is a key agreement. What's the difference between the key agreement and the key exchange? I have zero knowledge on both sides, and I need a Diffie-Hellman key exchange like protocol, or whatever to generate two key on each side for symmetric encryption. I've tried first the key agreement method introduced in the manual, but it didn't work. Than I take a closer look at the testlib example and I see of a loading some DH key. I can't generate DH key for myself (once it has benn generated, cryptlib not allow to read this, and I don't want to use another crypto lib for this). So summary: I need a secure protocol using cryptlib, which produces the same symmetric encryption key on both side, with zero starting knowledge. Is it possible without a big hacking? Is it supported by cryptlib? I hope my problem is clear. I would be very pleased if you would be so kind as to help me. Cheerz -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Fri Apr 13 12:02:39 2001 From: cryptlib@mbsks.franken.de (Wolfgang Gothier) Date: Fri, 13 Apr 2001 13:02:39 +0200 Subject: [Cryptlib] RE: cryptlib beta compatibility, was:[Luciano Benetti] (no subject) In-Reply-To: <003c01c0c32d$b6e8d230$05c8a8c0@dummy.net> Message-ID: <000001c0c409$41290150$0301a8c0@sogot2k> Hi Mr. Benetti, (it would be fine to use a subject line :-)) > I am writing to as for some help with the Cryptolib. > I am using the Beta 5 with Delphi. When I use the > codes listed below, I get an error (-2) > > status := cryptGetAttributeString(signatureKeyContext,CRYPT_CERTINFO_SERIALNUMBER,@val ore,k); > > I was previously using the Beta 4 and it worked fine. > If I try to read something, such as: > CRYPT_CERTINFO_ORGANIZATIONNAME > It works just fine. ... Are you sure to use the CL32.DLL and cryptlib.pas from Beta05 ? Did you copy CL32.DLL Beta04 to \Windows\sytem32 and forgot to replace it by CL32.DLL Beta05 ? (That's the way I always run into such problems.) In Beta04 CRYPT_CERTINFO_SERIALNUMBER was 2012, in Beta05 you have CRYPT_CERTINFO_TRUSTED_IMPLICIT = 2012; CRYPT_CERTINFO_SERIALNUMBER = 2013; maybe, this is your problem. Cryptlib is NOT upward compatible (only "source compatible"), you have to recompile your source with each beta. Using your compiled program with the cl32.dll from a previous beta doesn't work. This is true for Delphi and C/C++ programs. The reason for that are incompatible changes in cryptlib.h Wolfgang Gothier -------------------------------------------------------- http://www.sogot.de From cryptlib@mbsks.franken.de Fri Apr 13 17:18:39 2001 From: cryptlib@mbsks.franken.de (Luciano Benetti) Date: Fri, 13 Apr 2001 17:18:39 +0100 Subject: [Cryptlib] (no subject) Message-ID: <002501c0c435$665c4e10$05c8a8c0@dummy.net> This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0C43D.C7E6BA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i have some doubts about the use of the Cryptolib.=20 The Italian law needs of a generation of the "time stamping" in some = operations connected with the CA actions.=20 Can you tell me how can I do that using the Cryptolib? Is it possible? I = think it is possible, but I need of some help from you. Can you give me some clue? =20 Thank you very much.=20 Luciano Benetti=20 ------=_NextPart_000_0022_01C0C43D.C7E6BA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

i have some = doubts=20 about the use of the Cryptolib.

The Italian law = needs of a=20 generation of the “time stamping” in some operations = connected with the CA=20 actions.

Can you tell me = how can I=20 do that using the Cryptolib? Is it possible? I think it is possible, but = I need=20 of some help from you.

Can you give me = some=20 clue?  

Thank you very = much.=20

Luciano=20 Benetti 

------=_NextPart_000_0022_01C0C43D.C7E6BA50-- From cryptlib@mbsks.franken.de Fri Apr 13 17:41:54 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Fri, 13 Apr 2001 18:41:54 +0200 (MET DST) Subject: [Cryptlib] My previous mail Message-ID: Hi again! I've take a closer look at to the beta05 testlib, and I saw that the keyagreement is commented out now (not only the key exchange as in beta02). So has anyone some code or idea how to implement link encryption with cryptlib? I think my need is a very basic thing, it must be supported somehow by cryptlib or not? If this mail arrives to the list, please reply something to it, so I can see it is succesfully arrived. Thanks in advance. -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Sat Apr 14 20:58:33 2001 From: cryptlib@mbsks.franken.de (Marcus Carey) Date: Sat, 14 Apr 2001 12:58:33 -0700 Subject: [Cryptlib] My previous mail References: Message-ID: <008f01c0c51d$50a64010$c2f4fea9@internet> Toth Your mail arrived but I don't think this list gets a lot of traffic. If you download the software it seems you're basically on your own. Marcus ----- Original Message ----- From: "Toth Csaba" To: "Cryptlib Developer Mailing List" Sent: Friday, April 13, 2001 9:41 AM Subject: [Cryptlib] My previous mail > Hi again! > > I've take a closer look at to the beta05 testlib, and I saw that the > keyagreement is commented out now (not only the key exchange as in > beta02). > > So has anyone some code or idea how to implement link encryption with > cryptlib? I think my need is a very basic thing, it must be supported > somehow by cryptlib or not? > > If this mail arrives to the list, please reply something to it, so I can > see it is succesfully arrived. > > Thanks in advance. > > -- > > tocsa > > ------------------------------------------------------------- > | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | > | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | > ------------------------------------------------------------- > > > _______________________________________________ > Cryptlib mailing list > Cryptlib@mbsks.franken.de > http://the-web-interface-does-not-work/mailman/listinfo/cryptlib From cryptlib@mbsks.franken.de Sat Apr 14 22:25:27 2001 From: cryptlib@mbsks.franken.de (cryptlib@mbsks.franken.de) Date: Sat, 14 Apr 2001 23:25:27 +0200 Subject: [Cryptlib] My previous mail In-Reply-To: <008f01c0c51d$50a64010$c2f4fea9@internet>; from mlcarey59@email.msn.com on Sat, Apr 14, 2001 at 12:58:33PM -0700 References: <008f01c0c51d$50a64010$c2f4fea9@internet> Message-ID: <20010414232527.E3874@mbsks.franken.de> Mahlzeit On Sat, Apr 14, 2001 at 12:58:33PM -0700, Marcus Carey wrote: > Your mail arrived but I don't think this list gets a lot of traffic. Probably, because there is a very detailed manual. > [Long quoted mail deleted.] Mahlzeit endergone Zwiebeltuete From cryptlib@mbsks.franken.de Sat Apr 14 23:11:21 2001 From: cryptlib@mbsks.franken.de (Matthijs van Duin) Date: Sun, 15 Apr 2001 00:11:21 +0200 Subject: [Cryptlib] Typo in cryptos.h Message-ID: I dunno where to send these normally, so I'll send it here in cryptos.h, it says somewhere at the bottom: #define DECLARE_OBJECT_LOCKING_VARS int dummy but DECLARE_OBJECT_LOCKING_VARS is used without semicolon, giving a compile error... it should probably be "int dummy;" or nothing at all -xmath Matthijs van Duin - PGP Key: 0xB6205CCB - - FP: D73C 9EE3 5F6B E5D5 8E19 2CBE 4648 8C3E B620 5CCB - From cryptlib@mbsks.franken.de Sun Apr 15 01:53:42 2001 From: cryptlib@mbsks.franken.de (Marcus Carey) Date: Sat, 14 Apr 2001 17:53:42 -0700 Subject: [Cryptlib] My previous mail References: <008f01c0c51d$50a64010$c2f4fea9@internet> <20010414232527.E3874@mbsks.franken.de> Message-ID: <000701c0c546$866dcfa0$b039fea9@online> Mahlzeit Yes there is a detailed manual but its not straight forward. The manual says, "Before you can use any of the cryptlib functions, you need to call the cryptInit() function to initialise cryptlib. You also need to call its companion function cryptEnd() at the end of your program". However calling CRYTP_SESSION object after calling cryptInit() function does not compile. cryptInit(); CRYPT_SESSION cryptSession; cryptCreateSession( . . . ); cryptDestroySession(cryptSession); cryptEnd(cryptSession); After several hours of looking at the testsess.c source code I got it to compile by placing CRYPT_SESSION object in a function outside of the windows main function. Also some of the function prototypes in the manual are not declared the same as in the source code. Marcus cryptCreateSession( . . . ); cryptDestroySession(cryptSession); cryptEnd(cryptSession); After several hours of looking at the testsess.c source code I got it to compile by placing CRYPT_SESSION object in a function outside of the windows main function. Also some of the function prototypes in the manual are not declared the same as in the source code. ----- Original Message ----- From: To: Sent: Saturday, April 14, 2001 2:25 PM Subject: Re: [Cryptlib] My previous mail > Mahlzeit > > > On Sat, Apr 14, 2001 at 12:58:33PM -0700, Marcus Carey wrote: > > Your mail arrived but I don't think this list gets a lot of traffic. > > Probably, because there is a very detailed manual. > > > [Long quoted mail deleted.] > > > Mahlzeit > > endergone Zwiebeltuete > > _______________________________________________ > Cryptlib mailing list > Cryptlib@mbsks.franken.de > http://the-web-interface-does-not-work/mailman/listinfo/cryptlib From cryptlib@mbsks.franken.de Mon Apr 16 02:34:07 2001 From: cryptlib@mbsks.franken.de (=?gb2312?B?zfXB1g==?=) Date: Mon, 16 Apr 2001 09:34:07 +0800 Subject: [Cryptlib] (no subject) Message-ID: <001601c0c615$6865f8a0$118175ca@wl> This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C0C658.6280BE00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sIGV2ZXJ5IGNyeXB0TGliIGRldmVsb3BlcjoNCg0KICAgICAgICBOb3csIEknbSB1c2lu ZyBjcnlwdGxpYiBtYWtpbmcgYSBwcm9qZWN0IHVuZGVyIFZpc3VhbCBCYXNpYy4gSSBoYXZlIGEg cHJvYmxlbSB3aXRoIGNlcnRpZmljYXRlOiBJIGRvbid0IGtub3cgaG93IHRvIG1ha2UgYSBkaXNr IGZpbGUgb2YgYSBjZXJ0aWZpY2F0ZSwgaS5lLiwgbWFrZSBhIGNlciBmaWxlIG9mIGEgY2VydGlm aWNhdGUgc2hjaCB0aGF0IGl0IGNhbiBiZSBkaXNwbGF5ZWQgYXV0b21hdGljYWxseSB3aGVuIGNs aWNrZWQuIENvdWxkIHNvbWVvbmUgcGxlYXNlIHRlbGwgbWUgaG93PyBUaGFuayB5b3UhDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTaW5jZXJlbHkgWW91cnMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIExpbiBXYW5nDQoNCg0KDQoNCg0KDQp3YW5nbGlu QHhpeW91LmVkdS5jbg0K ------=_NextPart_000_0013_01C0C658.6280BE00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0yPkhlbGxvLCBldmVyeSBjcnlwdExpYiANCmRldmVsb3Blcjo8L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KTm93LCBJJ20gdXNpbmcg Y3J5cHRsaWIgbWFraW5nIGEgcHJvamVjdCB1bmRlciBWaXN1YWwgQmFzaWMuIEkgaGF2ZSBhIHBy b2JsZW0gDQp3aXRoIGNlcnRpZmljYXRlOiBJIGRvbid0IGtub3cgaG93IHRvIG1ha2UgYSBkaXNr IGZpbGUgb2YgYSBjZXJ0aWZpY2F0ZSwgaS5lLiwgDQptYWtlIGEgY2VyIGZpbGUgb2YgYSBjZXJ0 aWZpY2F0ZSBzaGNoIHRoYXQgaXQgY2FuIGJlIGRpc3BsYXllZCBhdXRvbWF0aWNhbGx5IA0Kd2hl biBjbGlja2VkLiBDb3VsZCBzb21lb25lIHBsZWFzZSB0ZWxsIG1lIGhvdz8gVGhhbmsgeW91ITwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAN CiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgU2luY2VyZWx5IFlvdXJzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7IExpbiBXYW5n PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48 QSANCmhyZWY9Im1haWx0bzp3YW5nbGluQHhpeW91LmVkdS5jbiI+d2FuZ2xpbkB4aXlvdS5lZHUu Y248L0E+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0013_01C0C658.6280BE00-- From cryptlib@mbsks.franken.de Tue Apr 17 16:09:14 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Tue, 17 Apr 2001 11:09:14 -0400 (EDT) Subject: [Cryptlib] Re: Cryplib and threads Message-ID: <20010417150914.B394F84F0@mrspeel.watson.ibm.com> [I'm back from the RSA conference with ~1,500 pieces of mail to catch up on. I'll also upload a slightly updated copy of the manual some time within the next week, the current copy still needs a bit of editing but I wanted to get it out at the same time as the beta] Fidel Liberal Malaina writes: >I compile with no-erros but after connecting with ssh server I always get a >Segmentation Fault. When I execute listen_server from the main function it >works well. Could you step into the code to see where the problem is? There are too many different system configurations and versions for me to be able to test the code on all of them, I tested it under RH 6.2 (I think) and who knows what version of glibc... I also found one very old version of Linux where it wouldn't work at all (connect() returned -1 with errno = 0, which wasn't very useful). >One more question: Why in the test examples provided with the library they use >delayThread() between each push - pop? Is there any blocking alternatives to >cryptPop and cryptPush? I could make it blocking, but I'm not sure what the preferred behaviour for this would be - should it block until data is received, or block until a timeout is reached, or what? It also has to be portable to weird languages and across multiple OS'es, ie I can't use things like semaphores which the caller can wait on. Blocking until a timeout is reached is probably the best (portable) way to handle this, but I'm open to suggestions. David Maurus added: >I haven't used cryptlib yet, but generally if a library is considered >/threadsafe/, that doen't imply that you can use its session variables accross >threads. So it could very well be that you will have to create a CRYPT_SESSION >for each thread that will use the library. (I might be wrong - I hope someone >will correct me if that's the case.) You can use the session variable across threads. Peter. From cryptlib@mbsks.franken.de Tue Apr 17 17:20:41 2001 From: cryptlib@mbsks.franken.de (Marcus Carey) Date: Tue, 17 Apr 2001 09:20:41 -0700 Subject: [Cryptlib] Client Server Examples Message-ID: <004001c0c75a$5a332820$c2f4fea9@internet> This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C0C71F.AC88BD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anyone code samples for a simple client server application using = SSL? Marcus ------=_NextPart_000_003D_01C0C71F.AC88BD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Has anyone code samples for a = simple client=20 server application using SSL?
 
Marcus
------=_NextPart_000_003D_01C0C71F.AC88BD50-- From cryptlib@mbsks.franken.de Tue Apr 17 17:26:18 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Tue, 17 Apr 2001 12:26:18 -0400 (EDT) Subject: [Cryptlib] Re: Secure session Message-ID: <20010417162618.0736B84F0@mrspeel.watson.ibm.com> "Susanna Bessone" writes: >I'm trying to perform data exchange between a server and a pc. As written in >your last security toolkit (beta 5), the SSL/TLS client code is still under >constraction: is there another way to handle a secure session? There are two options, you could either grab the source code and finish the SSL connect function yourself (that's the cool thing about open source, if you really need it you've got the code to do it yourself), or use an ssh session. >Is it possible to extract the content of a context (in my case the content is >the session key encrypted with a pubblic key) and copy it on a file? Uhh, the context will only contain a single key, either the session key or a public key. You can't extract session keys from a context except in encrypted form. Peter. From cryptlib@mbsks.franken.de Tue Apr 17 17:33:58 2001 From: cryptlib@mbsks.franken.de (Geoff Thorpe) Date: Tue, 17 Apr 2001 09:33:58 -0700 (PDT) Subject: [Cryptlib] Re: Cryplib and threads In-Reply-To: <20010417150914.B394F84F0@mrspeel.watson.ibm.com> Message-ID: Hi there, I haven't looked at Cryptlib's session handling for some time and I know Peter's been doing a fair bit of work in there - so I'll leap into this blindly :-) On Tue, 17 Apr 2001, Peter Gutmann wrote: > Fidel Liberal Malaina writes: > > >One more question: Why in the test examples provided with the library they use > >delayThread() between each push - pop? Is there any blocking alternatives to > >cryptPop and cryptPush? > > I could make it blocking, but I'm not sure what the preferred behaviour for > this would be - should it block until data is received, or block until a > timeout is reached, or what? It also has to be portable to weird languages and > across multiple OS'es, ie I can't use things like semaphores which the caller > can wait on. Blocking until a timeout is reached is probably the best > (portable) way to handle this, but I'm open to suggestions. Blocking is generally a bad idea as it's far easier to make an async API work in a blocking manner from inside application code, than it is to do the inverse. Of course, if Cryptlib is managing sockets directly (I'm not an advocate of this at all, but given OpenSSL does this extensively as well, I'm rather outnumbered anyhow) then it should make those sockets available together with some state so that an application can do select()ing and/or poll()ing (or WSA*** cruft on Windoze platforms). Eg. Cryptlib should indicate if it is ready (or able) to read and/or write data on the back-end encrypted stream (ssh, ssl, whatever). The caller can then do related logic on the clean side - ie. cryptoPop-ing into a "outgoing" FIFO buffer and cryptPush-ing from an "incoming" FIFO buffer. A select() could be called for the two sockets; on the encrypted socket, it would use Cryptlib's indicated state, and on the unencrypted socket, it would depend on whether the "outgoing" buffer is non-empty (socket-write) and/or the "incoming" buffer is non-full (socket-read). This can then safely block as long as the application wants - because the first event that could progress the session state would result in a break out of the blocking select() call. I should really dig into Cryptlib's session code again at some point ... maybe this is already there? (Peter?) Cheers, Geoff From cryptlib@mbsks.franken.de Tue Apr 17 17:26:43 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Tue, 17 Apr 2001 12:26:43 -0400 (EDT) Subject: [Cryptlib] Re: (no subject) Message-ID: <20010417162643.6FF0A84F0@mrspeel.watson.ibm.com> "Luciano Benetti" writes: >The Italian law needs of a generation of the "time stamping" in some >operations connected with the CA actions. > >Can you tell me how can I do that using the Cryptolib? Is it possible? I think >it is possible, but I need of some help from you. See the sections of the manual which cover timestamping servers and clients. Peter. From cryptlib@mbsks.franken.de Tue Apr 17 19:07:26 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Tue, 17 Apr 2001 14:07:26 -0400 (EDT) Subject: [Cryptlib] Re: Typo in cryptos.h Message-ID: <20010417180726.AA4CB84F0@mrspeel.watson.ibm.com> Matthijs van Duin writes: >in cryptos.h, it says somewhere at the bottom: > > #define DECLARE_OBJECT_LOCKING_VARS int dummy > >but DECLARE_OBJECT_LOCKING_VARS is used without semicolon, giving a compile >error... it should probably be "int dummy;" or nothing at all Thanks, I'll update the code. There has to be a dummy variable present because of the preprocessor tricks which are required to get the code to compile on threaded and non-threaded systems (ones where one version of the OS doesn't have threads, the next has them but they're broken, and the one after that finally supports them properly, are a particular joy to support :-). Peter. From cryptlib@mbsks.franken.de Wed Apr 18 15:26:32 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Wed, 18 Apr 2001 14:26:32 (NZST) Subject: [Cryptlib] Re: Constraint in key usage parameter of certificates Message-ID: <98756079217926@kahu.cs.auckland.ac.nz> "Eric Schreuder" writes: >While putting a debugger on de cryptCheckCert() function, I learned the >following (which is a little bit different from the story Kay wrote you): > >- key usage is "Key Encipherement" and "Data Encipherement" >- one of the extended key usage attributes is "Client Authentication >(1.3.6.1.5.5.7.3.2)" > >From the debugging session, I conclude that because of the extended key usage >attribute "Client Authentication", cryptlib expects a key usage "Digital >Signature", and because there is no key usage "Digital Signature" in the >certificate, the certificate is declared "invalid". Yup, to do client authentication you need to be able to sign data (either a login request or a challenge from the server or whatever). Since the cert has a key usage which says it can't be used for signing data, it logically can't be used for client authentication (if you did try and use it, it would fail with a CRYPT_ERROR_PERMISSION). cryptlib detects this when it does the general cert check and reports it as being invalid. >Can you please confirm (or deny) my conclusion, I am a bit confused about all >the bit fiddling that takes place in certchk.c. The X.509 keyUsage encoding isn't necessarily the most elegant data format ever invented :-). Peter. From cryptlib@mbsks.franken.de Mon Apr 23 07:13:53 2001 From: cryptlib@mbsks.franken.de (zhong_duhang) Date: Mon, 23 Apr 2001 14:13:53 +0800 Subject: [Cryptlib] (no subject) Message-ID: =CD=F5=C1=D6=A3=AC=C4=FA=BA=C3=A3=A1 first ,you can export the cert to a buffer use the function= cryptExportCert();then you write the buffer to a file (for= example aa.der) and it is OK! =D4=DA 2001-04-16 09:34:00 =C4=FA=D0=B4=B5=C0=A3=BA >Hello, every cryptLib developer: > > Now, I'm using cryptlib making a project under Visual= Basic. I have a problem with certificate: I don't know how to= make a disk file of a certificate, i.e., make a cer file of a= certificate shch that it can be displayed automatically when= clicked. Could someone please tell me how? Thank you! > = = Sincerely Yours > = = Lin Wang > > > > > > >wanglin@xiyou.edu.cn =D6=C2 =C0=F1=A3=A1 zhong_duhang zhong_duhang@21cn.com From cryptlib@mbsks.franken.de Thu Apr 19 03:50:06 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 19 Apr 2001 02:50:06 (NZST) Subject: [Cryptlib] Re: My previous mail Message-ID: <98760540622926@kahu.cs.auckland.ac.nz> "Marcus Carey" writes: >Yes there is a detailed manual but its not straight forward. The manual says, >"Before you can use any of the cryptlib functions, you need to call the >cryptInit() function to initialise cryptlib. You also need to call its >companion function cryptEnd() at the end of your program". However calling >CRYTP_SESSION object after calling cryptInit() function does not compile. > >cryptInit(); >CRYPT_SESSION cryptSession; That's not surprising, cryptlib is written in ANSI C (or C++ if you must) and the code above isn't ANSI C. Might I suggest supplementing your reading of the cryptlib manual with something like "ANSI and ISO Standard C Programmer's Reference" by Plauger and Brodie, or Schildt's "The Annotated ANSI C Standard" if you ignore the annotations (its one redeeming feature is that it's ~$100 cheaper than the standard, the price difference reflects the value of the annotations). >After several hours of looking at the testsess.c source code I got it to >compile by placing CRYPT_SESSION object in a function outside of the windows >main function. Reading Plauger would have been a more productive use of those hours. Peter. From cryptlib@mbsks.franken.de Thu Apr 19 03:57:38 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 19 Apr 2001 02:57:38 (NZST) Subject: [Cryptlib] Re: Re: Cryplib and threads Message-ID: <98760585823146@kahu.cs.auckland.ac.nz> Geoff Thorpe writes: >On Tue, 17 Apr 2001, Peter Gutmann wrote: >>Fidel Liberal Malaina writes: >> >>>One more question: Why in the test examples provided with the library they use >>>delayThread() between each push - pop? Is there any blocking alternatives to >>>cryptPop and cryptPush? >> >>I could make it blocking, but I'm not sure what the preferred behaviour for >>this would be - should it block until data is received, or block until a >>timeout is reached, or what? It also has to be portable to weird languages and >>across multiple OS'es, ie I can't use things like semaphores which the caller >>can wait on. Blocking until a timeout is reached is probably the best >>(portable) way to handle this, but I'm open to suggestions. > >Blocking is generally a bad idea as it's far easier to make an async API work >in a blocking manner from inside application code, than it is to do the >inverse. That means the user would have to implement platform-specific async socket handling, which I suspect will prevent about 95% of users from ever getting secure sessions working (look at all the hoops the net_tcp.c code has to jump through for this). You really need to hide all this, and do it in a platform- and language-independent manner (if anyone really wants to do this themselves they can always rewrite net_tcp.c, so far only one person that I know of has even considered this because they already had their own socket library, and I don't know how far they went with this). >Eg. Cryptlib should indicate if it is ready (or able) to read and/or write >data on the back-end encrypted stream (ssh, ssl, whatever). The caller can >then do related logic on the clean side - ie. cryptoPop-ing into a "outgoing" >FIFO buffer and cryptPush-ing from an "incoming" FIFO buffer. A select() could >be called for the two sockets; on the encrypted socket, it would use >Cryptlib's indicated state, and on the unencrypted socket, it would depend on >whether the "outgoing" buffer is non-empty (socket-write) and/or the >"incoming" buffer is non-full (socket-read). This can then safely block as >long as the application wants - because the first event that could progress >the session state would result in a break out of the blocking select() call. Yuck, that's unloading even more of the work on the user, you're now requiring them to do a lot of what's in the session/*.c modules as well. This was actually the model I worked with initially, but it's completely unmanageable once you get into any of the more complex session types such as ssh and SSL, you and up with huge amounts of state passing back and forth between cryptlib and the user app, and the user having to implement most of what's in the session-handling code themselves. I'm trying to implement something which closely follows the standard network sockets interface (open a connection, then just read and write), which apparently was what Netscape were originally aiming for, all I really need is an indication of what behaviour people would prefer for this. Peter. From cryptlib@mbsks.franken.de Wed Apr 18 21:11:10 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Wed, 18 Apr 2001 22:11:10 +0200 (MET DST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange Message-ID: Dear Peter Gutmann and other developers! I'm writing this mail because I'm stucked again. I've spent a lot of hour to get work the Diffie-Helman key agreement later. Now beta05's key agreement gave another chance for me. After a big breath I started to test again. I've spent this day with coding around it, but without any success :(((( I've started to work from the previous version of my key agreement test code: a socket client & server, in which the client wants to send a 'hello' message to the server through a link encrypted socket, where the key of the link encryption would be created by the key agreement procedure. In this version of the agreement procedure the steps follow the way suggested by the manual. The essence of this (as I could understand): s1, s2: session contexts d1, d2: DH contexts e1, e2: exported keys A sequence: create(s1); create(s2); create(d1); create(d2); export(s1, d1, e1); export(s2, d2, e2); import(s1, d1, e2); import(s2, d2, e1); So, on both side, we have to _export_the_key_first_, than import the key arrived form the other side. After taking a closer look at the new beta05 testlib, I saw the TestKeyAgreement() procedure in testhl.c, line 734. Unfortunately this code is not tested during the testlib procedure (there isn't any message in the log belonging to that function). Why? But I said: never mind, just look at it and get to work. This procedure follows this simplified sequence: B sequence: create(s1); create(s2); create(d1); create(d2); export(s1, d1, e1); import(s2, d2, e1); export(s2, d2, e2); import(s1, d1, e2); So as I could see, the opposit side (number 2) should _import_e1_first_ before exporting e2!!! This is different form the manual! I thought that I've found the reason why my code does not work. But after several hours of reading and coding I still had no success. I'll include my testcode here, and please correct it to me. Don't be afraid, its very simple: as I said, the client sends a message to the server, and that's all. So if you have some clue about what went wrong, modify this code to work, and repost to me (I have tried _everything_, so I couldn't make it good). If you have another _stand_alone_ solution (don't say KeyAgreement() in testhl.c, I've spent hours to cut it out with all of the functions, defines, etc.), sample code in C, than it will welcome too. Please, please, I'm begging to correct the code to me. Take a pity on me, and send the good one to that unlucky fellow (me) :(((( This is very important for me (for my thesis). Thanks in advance. Makefile: LD = $(CC) LIBNAME = libcl.a CFLAGS = -ggdb -c -Wall -I. LFLAGS = -L. -lcl -lpthread all: keyxchgcli keyxchgsrv keyxchgcli: $(LIBNAME) keyxchgcli.o $(LD) -o keyxchgcli keyxchgcli.o $(LFLAGS) keyxchgsrv: $(LIBNAME) keyxchgsrv.o $(LD) -o keyxchgsrv keyxchgsrv.o $(LFLAGS) keyxchgsrv.o: cryptlib.h keyxchgsrv.c $(CC) $(CFLAGS) keyxchgsrv.c keyxchgcli.o: cryptlib.h keyxchgcli.c $(CC) $(CFLAGS) keyxchgcli.c keyxchgsrv.c: #include #include #include #include #include #include #include #include #include #include #include #include #include "cryptlib.h" #define DEFAULT_SERVER_PORT 9000 #define DEFAULT_BUFFER_LENGTH 8192 #define LABEL "TothCsaba" CRYPT_CONTEXT linkCryptContext; CRYPT_CONTEXT dhContext; int linkInited = 0, dhInited = 0; struct sockaddr_in listen_addr; struct sockaddr srv_name, cli_name, cld_name; int listen_fd, cli_fd; int namelen, i, dflg = 1, lu; void usage(int exitcode) { fprintf(stderr, "Link encrypted server version 0.1, author: s8217tot@hszk.bme.hu\n"); fprintf(stderr, "Using DH key agreement, using Peter Gutmann's cryptlib 3.0 beta2\n"); fprintf(stderr, "Usage : keyxchgsrv [-V] [-d] [-l listenport]\n"); exit(exitcode); } void cleanup(void) { if (linkInited) cryptDestroyContext( linkCryptContext ); if (dhInited) cryptDestroyContext( dhContext ); cryptEnd(); exit( -1 ); } void CLIB(int status) { if( cryptStatusError( status ) ) { fprintf(stdout, "Error occured: %d\n", status); cleanup(); } else { printf(" [ %d ]\n", status); } } int main(int argc, char* argv[]) { char buffer[DEFAULT_BUFFER_LENGTH]; // char* sharedSecret; char sharedSecret[DEFAULT_BUFFER_LENGTH]; int sharedSecretLength = DEFAULT_BUFFER_LENGTH; int c; extern int optind; extern char* optarg; int on; int listen_port = DEFAULT_SERVER_PORT; while ((c = getopt(argc, argv, "Vdl:")) != EOF) { switch (c) { case 'V' : usage(0); break; case 'd' : dflg++; break; case 'l' : listen_port = atoi(optarg); break; default : usage(1); } } printf("DH key exchange test server\n"); printf("Initiaiting cryptlib 3.0 beta 2a (by Peter Gutmann).\n"); CLIB( cryptInit() ); printf("Warming up random engine.\n"); CLIB( cryptAddRandom(NULL, CRYPT_RANDOM_SLOWPOLL) ); printf("Creating context for symmetric link encryption.\n"); CLIB( cryptCreateContext( &linkCryptContext, CRYPT_UNUSED, CRYPT_ALGO_RC5 ) ); linkInited = 1; printf("Setting mode of operation.\n"); CLIB( cryptSetAttribute( linkCryptContext, CRYPT_CTXINFO_MODE, CRYPT_MODE_CBC ) ); printf("Creating context for Diffie-Helman.\n"); CLIB( cryptCreateContext( &dhContext, CRYPT_UNUSED, CRYPT_ALGO_DH ) ); dhInited = 1; printf("Creating socket "); if ((listen_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("listen socket descriptor problem"); exit(1); } printf("listen port: %d\n", listen_port); memset(&listen_addr, 0, sizeof(listen_addr)); listen_addr.sin_port = htons(listen_port); listen_addr.sin_addr.s_addr = INADDR_ANY; listen_addr.sin_family = AF_INET; on = 1; if (setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, (char *) &on, sizeof(on)) < 0) { perror("setsockopt REUSEADDR problem"); } printf("Binding socket.\n"); if (bind(listen_fd, (struct sockaddr *)&listen_addr, sizeof(listen_addr))) { perror("bind problem"); exit(-1); } printf("Listening socket.\n"); if (listen(listen_fd, 5) < 0) { perror("listen problem"); exit(-1); } printf("Accepting connection...\n"); if ((cli_fd = accept(listen_fd, 0, 0) ) < 0) { perror("accept"); exit(-1); } printf("Accepted.\n"); if (dflg) { namelen = sizeof(cld_name); i = getsockname(cli_fd, &cld_name, &namelen); printf("Socket on: %d.%d.%d.%d:%d accepts\n", cld_name.sa_data[2] & 255, cld_name.sa_data[3] & 255, cld_name.sa_data[4] & 255, cld_name.sa_data[5] & 255, ntohs(((short *) cld_name.sa_data)[0] & 65535) ); namelen = sizeof(cli_name); i = getpeername(cli_fd, &cli_name, &namelen); printf("client from: %d.%d.%d.%d:%d\n", cli_name.sa_data[2] & 255, cli_name.sa_data[3] & 255, cli_name.sa_data[4] & 255, cli_name.sa_data[5] & 255, ntohs(((short *) cli_name.sa_data)[0] & 65535) ); } /* printf("Determining shared secret size.\n"); CLIB( cryptExportKey(NULL, &sharedSecretLength, dhContext, linkCryptContext) ); sharedSecret = malloc(sharedSecretLength);*/ printf("Exchanging secret:\n"); printf("Reading exported key from client.\n"); /* for(lu = 0; lu < sharedSecretLength;) { i = read(cli_fd, sharedSecret + lu, sharedSecretLength - lu); if (i > 0) lu += i; }*/ lu = read(cli_fd, sharedSecret, sharedSecretLength); printf("%d bytes recieved, break code %d\n", lu, i); printf("\nReceived server secret: %s\n", sharedSecret); printf("Importing shared secret.\n"); CLIB( cryptImportKey(sharedSecret, dhContext, linkCryptContext) ); printf("Exporting shared secret.\n"); CLIB( cryptExportKey(sharedSecret, &sharedSecretLength, dhContext, linkCryptContext) ); printf("Sizeof exported server secret: %d\n", sharedSecretLength); printf("Exported server secret: %s\n", sharedSecret); printf("Sending exported key to client.\n"); for(lu = 0; lu < sharedSecretLength;) { i = write(cli_fd, sharedSecret + lu, sharedSecretLength - lu); if (i > 0) lu += i; } printf("%d bytes sent, break code %d\n", lu, i); printf("Destroying DH context.\n"); CLIB( cryptDestroyContext(dhContext) ); dhInited = 0; printf("Read data from client.\n"); for(lu = 0; i > 0;) { i = read(cli_fd, buffer, sizeof(buffer)); if (i > 0) lu += i; } printf("%d. bytes of data received\n", lu); printf("Decrypt data.\n"); CLIB( cryptDecrypt(linkCryptContext, buffer, lu) ); if (dflg) { printf("From client:\n"); printf("%s\n", buffer); } printf("Destroy link context.\n"); CLIB( cryptDestroyContext(linkCryptContext) ); linkInited = 0; // free(sharedSecret); close(cli_fd); close(listen_fd); return 0; } keyxchgcli.c: #include #include #include #include #include #include #include #include #include #include #include #include #ifndef TRUE #define FALSE 0 #define TRUE !FALSE #endif /* TRUE */ #include "cryptlib.h" #define DEFAULT_SERVER_PORT 9000 #define DEFAULT_BUFFER_LENGTH 8192 #define LABEL "TothCsaba" #define PKC_KEYSIZE 512 #define DH_KEY1_LABEL "Test DH key #1" typedef struct { int pLen; unsigned char p[ 64 ]; int qLen; unsigned char q[ 20 ]; int gLen; unsigned char g[ 64 ]; int xLen; unsigned char x[ 20 ]; int yLen; unsigned char y[ 64 ]; } DLP_PRIVKEY; DLP_PRIVKEY dlpTestKey = { /* p */ 512, { 0x8D, 0xF2, 0xA4, 0x94, 0x49, 0x22, 0x76, 0xAA, 0x3D, 0x25, 0x75, 0x9B, 0xB0, 0x68, 0x69, 0xCB, 0xEA, 0xC0, 0xD8, 0x3A, 0xFB, 0x8D, 0x0C, 0xF7, 0xCB, 0xB8, 0x32, 0x4F, 0x0D, 0x78, 0x82, 0xE5, 0xD0, 0x76, 0x2F, 0xC5, 0xB7, 0x21, 0x0E, 0xAF, 0xC2, 0xE9, 0xAD, 0xAC, 0x32, 0xAB, 0x7A, 0xAC, 0x49, 0x69, 0x3D, 0xFB, 0xF8, 0x37, 0x24, 0xC2, 0xEC, 0x07, 0x36, 0xEE, 0x31, 0xC8, 0x02, 0x91 }, /* q */ 160, { 0xC7, 0x73, 0x21, 0x8C, 0x73, 0x7E, 0xC8, 0xEE, 0x99, 0x3B, 0x4F, 0x2D, 0xED, 0x30, 0xF4, 0x8E, 0xDA, 0xCE, 0x91, 0x5F }, /* g */ 512, { 0x62, 0x6D, 0x02, 0x78, 0x39, 0xEA, 0x0A, 0x13, 0x41, 0x31, 0x63, 0xA5, 0x5B, 0x4C, 0xB5, 0x00, 0x29, 0x9D, 0x55, 0x22, 0x95, 0x6C, 0xEF, 0xCB, 0x3B, 0xFF, 0x10, 0xF3, 0x99, 0xCE, 0x2C, 0x2E, 0x71, 0xCB, 0x9D, 0xE5, 0xFA, 0x24, 0xBA, 0xBF, 0x58, 0xE5, 0xB7, 0x95, 0x21, 0x92, 0x5C, 0x9C, 0xC4, 0x2E, 0x9F, 0x6F, 0x46, 0x4B, 0x08, 0x8C, 0xC5, 0x72, 0xAF, 0x53, 0xE6, 0xD7, 0x88, 0x02 }, /* x */ 160, { 0x20, 0x70, 0xB3, 0x22, 0x3D, 0xBA, 0x37, 0x2F, 0xDE, 0x1C, 0x0F, 0xFC, 0x7B, 0x2E, 0x3B, 0x49, 0x8B, 0x26, 0x06, 0x14 }, /* y */ 512, { 0x19, 0x13, 0x18, 0x71, 0xD7, 0x5B, 0x16, 0x12, 0xA8, 0x19, 0xF2, 0x9D, 0x78, 0xD1, 0xB0, 0xD7, 0x34, 0x6F, 0x7A, 0xA7, 0x7B, 0xB6, 0x2A, 0x85, 0x9B, 0xFD, 0x6C, 0x56, 0x75, 0xDA, 0x9D, 0x21, 0x2D, 0x3A, 0x36, 0xEF, 0x16, 0x72, 0xEF, 0x66, 0x0B, 0x8C, 0x7C, 0x25, 0x5C, 0xC0, 0xEC, 0x74, 0x85, 0x8F, 0xBA, 0x33, 0xF4, 0x4C, 0x06, 0x69, 0x96, 0x30, 0xA7, 0x6B, 0x03, 0x0E, 0xE3, 0x33 } }; CRYPT_CONTEXT linkCryptContext; CRYPT_CONTEXT dhContext; int linkInited = 0, dhInited = 0; char duma[] = "Hello\n"; char endmsg[] = "quit"; struct sockaddr_in srv_addr; struct sockaddr srv_name, cli_name; int srv_fd; int namelen, i, dflg = 1, lu; void cleanup(void) { if (linkInited) cryptDestroyContext( linkCryptContext ); if (dhInited) cryptDestroyContext( dhContext ); cryptEnd(); exit( -1 ); } void CLIB(int status) { if( cryptStatusError( status ) ) { fprintf(stdout, "Error occured: %d\n", status); cleanup(); } else { printf(" [ %d ]\n", status); } } int loadDHContexts( CRYPT_CONTEXT *cryptContext, int keySize ) { CRYPT_PKCINFO_DLP *dhKey; /* Allocate room for the public-key components */ if( ( dhKey = ( CRYPT_PKCINFO_DLP * ) malloc( sizeof( CRYPT_PKCINFO_DLP ) ) ) == NULL ) return( -1 ); /* Create the first encryption context */ CLIB( cryptCreateContext( cryptContext, CRYPT_UNUSED, CRYPT_ALGO_DH ) ); CLIB( cryptSetAttributeString( *cryptContext, CRYPT_CTXINFO_LABEL, DH_KEY1_LABEL, strlen( DH_KEY1_LABEL ) ) ); cryptInitComponents( dhKey, CRYPT_KEYTYPE_PUBLIC ); cryptSetComponent( dhKey->p, dlpTestKey.p, dlpTestKey.pLen ); cryptSetComponent( dhKey->q, dlpTestKey.q, dlpTestKey.qLen ); cryptSetComponent( dhKey->g, dlpTestKey.g, dlpTestKey.gLen ); CLIB( cryptSetAttributeString( *cryptContext, CRYPT_CTXINFO_KEY_COMPONENTS, dhKey, sizeof( CRYPT_PKCINFO_DLP ) ) ); cryptDestroyComponents( dhKey ); free( dhKey ); return( 0 ); } int main(int argc, char* argv[]) { // char buffer[DEFAULT_BUFFER_LENGTH]; // char sharedSecret[DEFAULT_BUFFER_LENGTH]; char* sharedSecret; int sharedSecretLength = DEFAULT_BUFFER_LENGTH; int on; int server_port = DEFAULT_SERVER_PORT; int labellen = strlen(LABEL); printf("DH key exchange test client\n"); printf("Initiaiting cryptlib 3.0 beta 2a (by Peter Gutmann).\n"); CLIB( cryptInit() ); printf("Warming up random engine.\n"); CLIB( cryptAddRandom(NULL, CRYPT_RANDOM_SLOWPOLL) ); printf("Creating context for symmetric link encryption.\n"); CLIB( cryptCreateContext( &linkCryptContext, CRYPT_UNUSED, CRYPT_ALGO_RC5 ) ); linkInited = 1; printf("Setting mode of operation.\n"); CLIB( cryptSetAttribute( linkCryptContext, CRYPT_CTXINFO_MODE, CRYPT_MODE_CBC ) ); printf("Creating context for Diffie-Helman.\n"); CLIB( cryptCreateContext( &dhContext, CRYPT_UNUSED, CRYPT_ALGO_DH ) ); dhInited = 1; printf("Setting label: %s (len: %d)...\n", LABEL, labellen); CLIB( cryptSetAttributeString( dhContext, CRYPT_CTXINFO_LABEL, LABEL, labellen) ); printf("Generating key into the Diffie-Helman context.\n"); CLIB( cryptGenerateKey(dhContext) ); // loadDHContexts( &dhContext, PKC_KEYSIZE ); printf("Determining shared secret size.\n"); CLIB( cryptExportKey(NULL, &sharedSecretLength, dhContext, linkCryptContext) ); sharedSecret = malloc(sharedSecretLength); printf("Exporting shared secret.\n"); CLIB( cryptExportKeyEx(sharedSecret, &sharedSecretLength, CRYPT_FORMAT_CRYPTLIB, dhContext, linkCryptContext) ); printf("Sizeof exported client secret: %d\n", sharedSecretLength); printf("Exported client secret: %s\n", sharedSecret); printf("Creating socket.\n"); if ((srv_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket descriptor problem"); exit(1); } memset(&srv_addr, 0, sizeof(srv_addr)); srv_addr.sin_port = htons(server_port); srv_addr.sin_addr.s_addr = INADDR_ANY; srv_addr.sin_family = AF_INET; on = 1; if (setsockopt(srv_fd, SOL_SOCKET, SO_REUSEADDR, (char *) &on, sizeof(on)) < 0) { perror("setsockopt REUSEADDR problem"); } printf("Connecting to server on %d...\n", server_port); if (connect(srv_fd, (struct sockaddr *)&srv_addr, sizeof(srv_addr)) < 0) { perror("connecting to server"); exit(1); } printf("Connected.\n"); if (dflg) { namelen = sizeof(cli_name); i = getsockname(srv_fd, &cli_name, &namelen); printf("Client on: %d.%d.%d.%d:%d connects to\n", cli_name.sa_data[2] & 255, cli_name.sa_data[3] & 255, cli_name.sa_data[4] & 255, cli_name.sa_data[5] & 255, ntohs(((short *) cli_name.sa_data)[0] & 65535) ); namelen = sizeof(srv_name); i = getpeername(srv_fd, &srv_name, &namelen); printf("server on: %d.%d.%d.%d:%d\n", srv_name.sa_data[2] & 255, srv_name.sa_data[3] & 255, srv_name.sa_data[4] & 255, srv_name.sa_data[5] & 255, ntohs(((short *) srv_name.sa_data)[0] & 65535) ); } printf("Exchanging secret:\n"); printf("Sending exported key to server.\n"); for(lu = 0; lu < sharedSecretLength;) { i = write(srv_fd, (char *)sharedSecret + lu, sharedSecretLength - lu); if (i > 0) lu += i; } printf("%d bytes sent, break code %d\n", lu, i); printf("Reading exported key from server.\n"); for(lu = 0; lu < sharedSecretLength;) { i = read(srv_fd, sharedSecret + lu, sharedSecretLength - lu); if (i > 0) lu += i; } printf("%d bytes received, break code %d\n", lu, i); printf("Importing shared secret.\n"); CLIB( cryptImportKey(sharedSecret, dhContext, linkCryptContext) ); printf("Destroying DH context.\n"); CLIB( cryptDestroyContext(dhContext) ); dhInited = 0; printf("Communication:\n"); printf("Writing duma[]=%s\n", duma); printf("Encrypting.\n"); CLIB( cryptEncrypt(linkCryptContext, duma, sizeof(duma)) ); write(srv_fd, duma, sizeof(duma)); printf("Destroy link context.\n"); CLIB( cryptDestroyContext(linkCryptContext) ); linkInited = 0; free(sharedSecret); close(srv_fd); return 0; } -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Wed Apr 18 20:36:51 2001 From: cryptlib@mbsks.franken.de (Geoff Thorpe) Date: Wed, 18 Apr 2001 12:36:51 -0700 (PDT) Subject: [Cryptlib] Re: Re: Cryplib and threads In-Reply-To: <98760585823146@kahu.cs.auckland.ac.nz> Message-ID: On Thu, 19 Apr 2001, Peter Gutmann wrote: > Geoff Thorpe writes: > > >Blocking is generally a bad idea as it's far easier to make an async API work > >in a blocking manner from inside application code, than it is to do the > >inverse. > > That means the user would have to implement platform-specific async socket > handling, which I suspect will prevent about 95% of users from ever getting > secure sessions working (look at all the hoops the net_tcp.c code has to jump > through for this). You really need to hide all this, and do it in a platform- Well, I see no problem providing an alternative that handholds baby programmers through this - but doing it in an unbypassable way does somewhat pin yourself down to use-cases only baby programmers are going stay within. :-) As I'll point out shortly, this also puts you in serious trouble with any SSL/TLS application that wishes to use renegotiates or that has no defined order of data flow in the application-protocol within the SSL/TLS stream. (Eg. any kind of real-time application, tunneling/VPN/PPP type stuff, chat/talk type protocols, etc). > and language-independent manner (if anyone really wants to do this themselves > they can always rewrite net_tcp.c, so far only one person that I know of has > even considered this because they already had their own socket library, and I > don't know how far they went with this). Well, I would respectfully suggest rewriting the network code in Cryptlib is not something people will be comfortable doing just because they want to avoid a blocking interface. The current approach will have a number of problems; * The only way to handle more than one stream is with multiple threads or processes. This is because Cryptlib's API functions will block on per-connection activity. It is still theoretically possible to handle multiple streams if you don't mind blocking on one connection causing blocking on all of them, but even then it gets complicated. The thread-per-connection mentality is thankfully dying in network programming, as it should. * It is not possible to conduct SSL/TLS in a chain. Ie. unlike the normal cryptoPush/Pop applications, you can't be chaining envelopes in a line. You have to assume that the encrypted side of an SSL/TLS session must go directly to a (blocking) TCP/IP socket. Eg. it cannot be encapsulated in anything else. * It is not possible to conduct SSL/TLS over another medium. SSL/TLS has nothing whatsoever specifically to do with TCP/IP ... there's nothing to stop it being used over domain sockets, physical interfaces, etc, or indeed sending SSL/TLS records back and forth across something more discrete - eg. message passing between threads, processes, windows, etc, or function calls across RPC, CORBA, DCOM, etc (this works if the model supports server-to-client "events"). However, not putting the SSL/TLS logic inside a medium-independant state machine precludes it from being applied to any of these. * It is not possible to utilise SSL/TLS inline with any other data. Eg. STARTTLS and other such techniques (perhaps even custom application-specific ones) that send non-SSL/TLS data before and/or after the stream carries the actual SSL/TLS data. Solutions of this form have also been proposed for getting around the name-based virtual hosting problems of secure web-serving (that is, you can't run multiple secure sites over a single IP/port pair, because the site for the user's request isn't known until you've performed the entire SSL/TLS handshake and peered inside the cleartext request). I'll bail out of that now before it gets out of control. > >Eg. Cryptlib should indicate if it is ready (or able) to read and/or write > >data on the back-end encrypted stream (ssh, ssl, whatever). The caller can > >then do related logic on the clean side - ie. cryptoPop-ing into a "outgoing" > >FIFO buffer and cryptPush-ing from an "incoming" FIFO buffer. A select() could > >be called for the two sockets; on the encrypted socket, it would use > >Cryptlib's indicated state, and on the unencrypted socket, it would depend on > >whether the "outgoing" buffer is non-empty (socket-write) and/or the > >"incoming" buffer is non-full (socket-read). This can then safely block as > >long as the application wants - because the first event that could progress > >the session state would result in a break out of the blocking select() call. > > Yuck, that's unloading even more of the work on the user, you're now requiring > them to do a lot of what's in the session/*.c modules as well. This was > actually the model I worked with initially, but it's completely unmanageable > once you get into any of the more complex session types such as ssh and SSL, > you and up with huge amounts of state passing back and forth between cryptlib > and the user app, and the user having to implement most of what's in the > session-handling code themselves. I'm trying to implement something which > closely follows the standard network sockets interface (open a connection, then > just read and write), which apparently was what Netscape were originally aiming > for, all I really need is an indication of what behaviour people would prefer > for this. Well I disagree that it's difficult or unmanageable, it can actually be done extremely easily (I won't refer to OpenSSL as an example, because IMHO it has evolved a rather unattractive and convoluted technique for this). Also, if Netscape had intended this just to work like a standard socket interface for use in simple "protocols" like HTTPS, I dare suggest they would have written an HTTPS standard and save themselves and everyone else a tonne of pain. As it is, SSL/TLS is a pretty flexible stream-oriented protocol, not a transactional protocol like HTTP - which is why the state logic gets "complicated". OTOH, this is why it can be used in asynchronous uses such as VPNs. Even defining how SSL/TLS should interact with http is extremely weird once you get into the details, because it's very much like a square in a round hole. S/MIME would actually have provided a more logical fit than SSL/TLS! (I'll withold some tempting comments about people racing out with ways of doing things too fast to realise some obvious problems with what they've done). In fact, your logic for implementing SSL/TLS this way is implicitly broken unless I'm missing some insanely cool trick you've cooked up. Eg. renegotiates. Either side of an SSL/TLS session can elect to kick-start a renegotiate, but because it's spontaneous and need not be caused by any client-side event (at your end of the stream that is), the "single-sided Push/Pop" API will not recognise or react to that unless the caller tries to do a read or write. Ie. the renegotiate attempt by the peer won't even get noticed until the caller tries to read (pop) or write (push) some data, at which point (if renegotiation is supported) the flurry of negotiation will only just begin. What you suggest is usable in a transaction-only context, particularly if the application protocol makes reads and writes (and the order in which they occur) deterministic. However, I see no obvious way how Cryptlib implementing sessions this way can possibly support the possibility where the caller can deal with not knowing if the next "event" will be caller-side (ie. do a write) or peer-side (ie. do a read). If you go into a blocking read and there's nothing coming from the peer - there's no obvious way to interrupt as/when the user wants to send data. Similarly, if we don't go into a blocking read, we'll never know if the peer has sent data to us until the user proactively causes something to do a read/write action. Using idle-time processing or short sleep()s is a horribly ineffecient and hacky way of trying to get round this logical bottleneck, only to avoid the simple fact that the SSL/TLS state machine needs to be operated in such a way that I/O on all 4 points (clean read/write and dirty read/write) can be event driven. This email runneth over ... I'll quickly finish up by saying that a general layout for this sort of async stuff is pretty easy to create, explain, understand, and use. What's more - it should be quite easy given that to then create a switchable form of the support that attempts to do what you're doing right now (ie. automate the encrypted side I/O on a socket/file-descriptor so that the interface looks like a clear-text push/pop). It just requires certain decisions to be made (perhaps by the caller, perhaps assumed) about which of these anomalies you are prepared to avoid/ignore. Cheers, Geoff From cryptlib@mbsks.franken.de Wed Apr 18 21:45:46 2001 From: cryptlib@mbsks.franken.de (Luciano Benetti) Date: Wed, 18 Apr 2001 22:45:46 +0200 Subject: [CRYPTLIB] tsa Message-ID: Hello! I'm using the library beta 5 with Delphi 5 and smartcard Schlumberger. I made a small program to administrate a TSA server session which stays in stand-by and wait the call of the client. Here is the source code of the server: cryptInit; Chkerr(cryptSetAttributeString( CRYPT_UNUSED, CRYPT_OPTION_DEVICE_PKCS11_DVR01,pchar(FPKCS11_DRIVER_PATH), length(FPKCS11_DRIVER_PATH) )); Chkerr(cryptDeviceOpen( cryptDevice,CRYPT_UNUSED, CRYPT_DEVICE_PKCS11,Pchar(Dummy))); Chkerr(cryptSetAttributeString( cryptDevice, CRYPT_DEVINFO_AUTHENT_USER, pchar('QWERTYUI'), 8 )); Chkerr(cryptDeviceCreateContext( cryptDevice,signatureKeyContext, CRYPT_ALGO_RSA )), Chkerr(cryptGetPrivateKey( cryptDevice, signatureKeyContext, CRYPT_KEYID_NAME,PChar(RSA_PUBKEY_LABEL), pchar('') )); Chkerr(cryptCreateSession (CryptSession,CRYPT_UNUSED,CRYPT_SESSION_TSP_SERVER)); Chkerr(cryptSetAttribute( CryptSession, CRYPT_SESSINFO_PRIVATEKEY, signatureKeyContext )); Chkerr(cryptSetAttribute( CryptSession, CRYPT_SESSINFO_ACTIVE, 1 )); On the client side of my program, which signs and generates the S/MIME file, I added as mentioned on page 166 of the manual status :=cryptSetAttributeString( cryptEnvelope,CRYPT_ENVINFO_TIMESTAMP_AUTHORITY ,Pchar(ftsaserver),length status := cryptPushData( cryptEnvelope,@FilesData, size, bytesCopied ); status := cryptPushData( cryptEnvelope, pchar(nil), 0, bytesCopied ); Following this last raw of the server program, there I get an assert at line 686 of the stream.c stream->flags & STREAM_FLAG_READONLY Where is my mistake? Thank you very much. From cryptlib@mbsks.franken.de Thu Apr 19 05:15:27 2001 From: cryptlib@mbsks.franken.de (Jim Law) Date: Thu, 19 Apr 2001 12:15:27 +0800 Subject: [Cryptlib] CRYPTLIB encrypt and decrypt time References: Message-ID: <3ADE665F.6AF9718E@mailserv.cuhk.edu.hk> I found the time for decrypting a message is much longer encrypting, about 20 times than decrypt a message using RSA. Is it normally? I am only use cryptEncrypt() and cryptDecrypt only. I am not using crypt CreateSignature and crypt CheckSignature as suggest in Manual. I use gcc to compile. From cryptlib@mbsks.franken.de Wed Apr 18 23:56:40 2001 From: cryptlib@mbsks.franken.de (Marcus Carey) Date: Wed, 18 Apr 2001 15:56:40 -0700 Subject: [Cryptlib] Re: My previous mail References: <98760540622926@kahu.cs.auckland.ac.nz> Message-ID: <002701c0c85a$d5735090$c2f4fea9@internet> Peter I am copying the code examples from the manual and usingthem in my programs. Are you saying the code examples inthe manual are not ANSI C? Also will the books you recommended explain how to use your toolkit? #include "cryptlib.h" int main(){ const char *hostName = "127.0.0.1";const int portNumber = 443; cryptInit(); /* Calls to cryptlib routines */ CRYPT_SESSION cryptSession; cryptCreateSession( &cryptSession, CRYPT_UNUSED, CRYPT_SESSION_SSL );/* Add the host name and port number */cryptSetAttributeString( cryptSession, CRYPT_SESSINFO_SERVER_NAME, hostName, trlen(hostName) );cryptSetAttribute( cryptSession, CRYPT_SESSINFO_SERVER_PORT, portNumber ); /* Communicate with the remote server or client *//* Activate the session */ cryptSetAttribute( cryptSession, CRYPT_SESSINFO_ACTIVE, 1 ); cryptDestroySession( cryptSession ); cryptEnd();return 0;} I can connect to a secure sever using the above code. The only problem I am having now is setting the Cipher, Hash and Key attributes. Reading the manual it's unclear which sequence of functions to call. Marcus ----- Original Message ----- From: "Peter Gutmann" To: Sent: Thursday, April 19, 2001 2:50 AM Subject: [Cryptlib] Re: My previous mail > "Marcus Carey" writes: > > >Yes there is a detailed manual but its not straight forward. The manual says, > >"Before you can use any of the cryptlib functions, you need to call the > >cryptInit() function to initialise cryptlib. You also need to call its > >companion function cryptEnd() at the end of your program". However calling > >CRYTP_SESSION object after calling cryptInit() function does not compile. > > > >cryptInit(); > >CRYPT_SESSION cryptSession; > > That's not surprising, cryptlib is written in ANSI C (or C++ if you must) and > the code above isn't ANSI C. Might I suggest supplementing your reading of the > cryptlib manual with something like "ANSI and ISO Standard C Programmer's > Reference" by Plauger and Brodie, or Schildt's "The Annotated ANSI C Standard" > if you ignore the annotations (its one redeeming feature is that it's ~$100 > cheaper than the standard, the price difference reflects the value of the > annotations). > > >After several hours of looking at the testsess.c source code I got it to > >compile by placing CRYPT_SESSION object in a function outside of the windows > >main function. > > Reading Plauger would have been a more productive use of those hours. > > Peter. > > > _______________________________________________ > Cryptlib mailing list > Cryptlib@mbsks.franken.de > http://the-web-interface-does-not-work/mailman/listinfo/cryptlib From cryptlib@mbsks.franken.de Thu Apr 19 12:33:43 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 19 Apr 2001 11:33:43 (NZST) Subject: [Cryptlib] Re: Re: Cryplib and threads Message-ID: <98763682328499@kahu.cs.auckland.ac.nz> Geoff Thorpe writes: >On Thu, 19 Apr 2001, Peter Gutmann wrote: >>and language-independent manner (if anyone really wants to do this themselves >>they can always rewrite net_tcp.c, so far only one person that I know of has >>even considered this because they already had their own socket library, and I >>don't know how far they went with this). > >Well, I would respectfully suggest rewriting the network code in Cryptlib is >not something people will be comfortable doing just because they want to avoid >a blocking interface. Oh no, that wasn't the intent of my comment at all, what I meant was that they had their own networking interface and wanted to use that in place of the cryptlib one. If people want blocking behaviour I can add that and you can enable it by setting a session object attribute CRYPT_SESSINFO_BLOCKING or something, I just want to get some comments on what the blocking behaviour should be. The only one which makes much sense to me is "block until data is received or the timeout is reached", but there may be other options available. >* It is not possible to conduct SSL/TLS in a chain. Ie. unlike the normal > cryptoPush/Pop applications, you can't be chaining envelopes in a line. You > have to assume that the encrypted side of an SSL/TLS session must go > directly to a (blocking) TCP/IP socket. Eg. it cannot be encapsulated in > anything else. Actually you will be able to, I can implement that when the time comes (ie when it's needed for anything). Hint: cryptlib already uses container objects internally for things like PKCS #15, S/MIME timestamping, etc. >* It is not possible to conduct SSL/TLS over another medium. SSL/TLS has > nothing whatsoever specifically to do with TCP/IP ... there's nothing to stop > it being used over domain sockets, physical interfaces, ..X.25, HDLC, SNA, LU6.2, carpet static... > etc, or indeed sending SSL/TLS records back and forth across something more > discrete - eg. message passing between threads, processes, windows, etc, .. sneakernet, tunneled over SMTP, semaphore, mouse organ... >Well I disagree that it's difficult or unmanageable, it can actually be done >extremely easily (I won't refer to OpenSSL as an example, because IMHO it has >evolved a rather unattractive and convoluted technique for this). Well, I'll refer to OpenSSL as an example of why you don't want to do it :-). >Also, if Netscape had intended this just to work like a standard socket >interface for use in simple "protocols" like HTTPS, I dare suggest they would >have written an HTTPS standard and save themselves and everyone else a tonne >of pain. That was the intent with SSL 1.0 (yeah, the one that was broken by members of the audience as it was being presented). It's evolved a bit since then. Peter. From cryptlib@mbsks.franken.de Thu Apr 19 12:42:27 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 19 Apr 2001 11:42:27 (NZST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange Message-ID: <98763734728633@kahu.cs.auckland.ac.nz> Toth Csaba writes: >I've spent this day with coding around it, but without any success :(((( I've >started to work from the previous version of my key agreement test code: a >socket client & server, in which the client wants to send a 'hello' message to >the server through a link encrypted socket, where the key of the link >encryption would be created by the key agreement procedure. If you need a secured link, why not just use the ssh client/server code, or grab the SSLv3 spec/TLS RFC and pick apart the final bit of the SSL client/server handshake where it fails when sending the MAC? >After taking a closer look at the new beta05 testlib, I saw the >TestKeyAgreement() procedure in testhl.c, line 734. Unfortunately this code is >not tested during the testlib procedure (there isn't any message in the log >belonging to that function). Why? It's commented out because RFC 2630 requires the use of assorted Fortezza-type parameters including recipient certificates (that is, you can't just use a straight DH key, you have to create a certificate for it and use sender and recipient certificates to do the exchange). This is just too painful to work with and all the bits and pieces you have to provide goes beyond even the cryptExportKeyEx() capabilities, so the self-test for this isn't enabled. If you want to implement a secure session yourself, just use RSA keys (although as mentioned above using session objects would be easier). Peter. From cryptlib@mbsks.franken.de Thu Apr 19 09:04:37 2001 From: cryptlib@mbsks.franken.de (cryptlib@mbsks.franken.de) Date: Thu, 19 Apr 2001 10:04:37 +0200 Subject: [Cryptlib] CRYPTLIB encrypt and decrypt time In-Reply-To: <3ADE665F.6AF9718E@mailserv.cuhk.edu.hk>; from a100700@mailserv.cuhk.edu.hk on Thu, Apr 19, 2001 at 12:15:27PM +0800 References: <3ADE665F.6AF9718E@mailserv.cuhk.edu.hk> Message-ID: <20010419100437.C10705@mbsks.franken.de> Mahlzeit On Thu, Apr 19, 2001 at 12:15:27PM +0800, Jim Law wrote: > I found the time for decrypting a message is much longer encrypting, about 20 > times than decrypt a message using RSA. Is it normally? I am only use Yes. For encrypting, you use the encryption exponent e, which has at most a length of 16 bits and for decryption you use the decryption exponent d, which has a length of 1024 bits or what ever the modulus is. So m^e mod n is much faster than m^d mod n. Mahlzeit endergone Zwiebeltuete From cryptlib@mbsks.franken.de Thu Apr 19 00:26:57 2001 From: cryptlib@mbsks.franken.de (Carlos =?ISO-8859-1?Q?Serr=E3o?=) Date: Thu, 19 Apr 2001 00:26:57 +0100 Subject: [Cryptlib] RSA keys Message-ID: <3ADE22C1.5090307@iscte.pt> Dear all, I would like to use CryptLib to generate a RSA key pair and afterwards I=20 would like to acess the indivual key components (e, n, v, ...) in order=20 to save them to a file. Is is possible to do it ? How can I do it with Cryptlib ? Thanks in advance, Best regards, --=20 _____________________________________________________________ Carlos Serr=E3o carlos.serrao@iscte.pt http://www.carlos-serrao.com DCTI - IS/IT Department IS/IT Research and Development ADETTI/ISCTE - Av.Forcas Armadas 1600-082 LISBOA Portugal Tel.: +351217903064/+351217903901 Fax: +351217935300 From cryptlib@mbsks.franken.de Thu Apr 19 10:54:41 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Thu, 19 Apr 2001 11:54:41 +0200 (MET DST) Subject: [Cryptlib] CRYPTLIB encrypt and decrypt time In-Reply-To: <20010419100437.C10705@mbsks.franken.de> Message-ID: hi! On Thu, 19 Apr 2001 m@mbsks.franken.de wrote: >On Thu, Apr 19, 2001 at 12:15:27PM +0800, Jim Law wrote: >> I found the time for decrypting a message is much longer encrypting, about 20 >> times than decrypt a message using RSA. Is it normally? I am only use > >Yes. For encrypting, you use the encryption exponent e, which has >at most a length of 16 bits and for decryption you use the decryption >exponent d, which has a length of 1024 bits or what ever the modulus >is. So m^e mod n is much faster than m^d mod n. Moreover, the e exponent is usually a fixed special number: 1000 0000 0000 0001 (binary) This makes the "encryption" more faster, than with other 16 bit long numbers, cause the weight of the number is only 2. Cheerz. -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Thu Apr 19 11:08:24 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Thu, 19 Apr 2001 12:08:24 +0200 (MET DST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange In-Reply-To: <98763734728633@kahu.cs.auckland.ac.nz> Message-ID: Hi! On Thu, 19 Apr 2001, Peter Gutmann wrote: >If you need a secured link, why not just use the ssh client/server code, or >grab the SSLv3 spec/TLS RFC and pick apart the final bit of the SSL >client/server handshake where it fails when sending the MAC? Because unfortunately I don't have enough time for it. I've allready spent a lot of time to implement onion routing components (ver. 1, and it is only a test laboratory version, doesn't contain Certificate database now). I should write my thesis, which is about onion router and anonym connection/anonym communication technologies. If I can win a PhD in our University, maybe I would develop it further, and maybe I would finish the SSLv3/TLS part of cryptlib (also if you find my programmer capabilities enough for this), but this is only the sound of the future. >>After taking a closer look at the new beta05 testlib, I saw the >>TestKeyAgreement() procedure in testhl.c, line 734. Unfortunately this code is >>not tested during the testlib procedure (there isn't any message in the log >>belonging to that function). Why? > >It's commented out because RFC 2630 requires the use of assorted Fortezza-type >parameters including recipient certificates (that is, you can't just use a >straight DH key, you have to create a certificate for it and use sender and >recipient certificates to do the exchange). This is just too painful to work >with and all the bits and pieces you have to provide goes beyond even the >cryptExportKeyEx() capabilities, so the self-test for this isn't enabled. If >you want to implement a secure session yourself, just use RSA keys (although as >mentioned above using session objects would be easier). :(((( So I need a fast solution. Sadly, I will do an RSA key exchange hack, which won't be too secure (compared to the STS key exchange for example), but in a test laboratory it will do the job now. Also in a whole implementation I should take more attention to the key exchange, and also for the PKI and LDAP infrastructure. Bye! -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Thu Apr 19 11:19:32 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Thu, 19 Apr 2001 12:19:32 +0200 (MET DST) Subject: [Cryptlib] RSA keys In-Reply-To: <3ADE22C1.5090307@iscte.pt> Message-ID: Hi! On Thu, 19 Apr 2001, Carlos [ISO-8859-1] Serr=E3o wrote: >Dear all, >I would like to use CryptLib to generate a RSA key pair and afterwards I >would like to acess the indivual key components (e, n, v, ...) in order >to save them to a file. > >Is is possible to do it ? How can I do it with Cryptlib ? It is possible, but not in the way you possibly mean. If you generate an RSA key with cryptlib, than you can't access its components, because the secure cryptlib kernel won't let you to touch it. You can create a key certificate, or export it some way. Then depending on the output format, you have to decrypt and get the raw key components by yourself. You can do this decryption with cryptlib if you discover the exported format. It might be _very_ painful, but the cryptlib kernel should be secure. There is another trick/hack (I use it only for testing): generate your keys with PGP, and fortunately you can read the keys from the PGP keyrings with cryptlib. But I think this hack is a no-no, and the "good" way is to use other standard (X509.v3, PKCS#x) certificate formats. Cryptlib experts, please correct me if necessary. Cheerz. -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Thu Apr 19 14:16:50 2001 From: cryptlib@mbsks.franken.de (Jim Law) Date: Thu, 19 Apr 2001 21:16:50 +0800 Subject: [Cryptlib] CRYPTLIB encrypt and decrypt time References: <3ADE665F.6AF9718E@mailserv.cuhk.edu.hk> <20010419100437.C10705@mbsks.franken.de> Message-ID: <3ADEE542.3080007@mailserv.cuhk.edu.hk> Why it is at most 16 bits but not the length of public key of RSA private/public pairs. Are the length of the private and public equal in RSA algorithm? My understanding is as follows: Encryption : use my RSA public key to encrypt. Decryption : use my RSA private to decrypt. Am I right? Jim Law m@mbsks.franken.de wrote: > Mahlzeit > > > On Thu, Apr 19, 2001 at 12:15:27PM +0800, Jim Law wrote: > >> I found the time for decrypting a message is much longer encrypting, about 20 >> times than decrypt a message using RSA. Is it normally? I am only use > > > Yes. For encrypting, you use the encryption exponent e, which has > at most a length of 16 bits and for decryption you use the decryption > exponent d, which has a length of 1024 bits or what ever the modulus > is. So m^e mod n is much faster than m^d mod n. > > > Mahlzeit > > endergone Zwiebeltuete > > _______________________________________________ > Cryptlib mailing list > Cryptlib@mbsks.franken.de > http://the-web-interface-does-not-work/mailman/listinfo/cryptlib From cryptlib@mbsks.franken.de Thu Apr 19 14:46:56 2001 From: cryptlib@mbsks.franken.de (cryptlib@mbsks.franken.de) Date: Thu, 19 Apr 2001 15:46:56 +0200 Subject: [Cryptlib] CRYPTLIB encrypt and decrypt time In-Reply-To: <3ADEE542.3080007@mailserv.cuhk.edu.hk>; from a100700@mailserv.cuhk.edu.hk on Thu, Apr 19, 2001 at 09:16:50PM +0800 References: <3ADE665F.6AF9718E@mailserv.cuhk.edu.hk> <20010419100437.C10705@mbsks.franken.de> <3ADEE542.3080007@mailserv.cuhk.edu.hk> Message-ID: <20010419154656.I14762@mbsks.franken.de> Mahlzeit On Thu, Apr 19, 2001 at 09:16:50PM +0800, Jim Law wrote: > Why it is at most 16 bits but not the length of public key of RSA > private/public pairs. It is because this value is choosen to be only 16 (or 3) bits to make the public key calculations (encryption) faster. If you would take a 1024bit (modulus length) value for e, public key calculations would be as slow as private key calculations, because m^e mod n would make the same compuational work than m^d mod n. Mahlzeit endergone Zwiebeltuete From cryptlib@mbsks.franken.de Fri Apr 20 03:24:23 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Fri, 20 Apr 2001 02:24:23 (NZST) Subject: [Cryptlib] Re: My previous mail Message-ID: <98769026301529@kahu.cs.auckland.ac.nz> "Marcus Carey" writes": >I am copying the code examples from the manual and usingthem in my programs. >Are you saying the code examples inthe manual are not ANSI C? The cryptlib manual is definitively accurate. Reality occasionally fails to live up to this level of accuracy. >Also will the books you recommended explain how to use your toolkit? No, but they'll show you how to write ANSI C code. The example you gave has a variable declaration after code inside the function body, which isn't valid C (although it is OK in C++). Peter. From cryptlib@mbsks.franken.de Fri Apr 20 03:42:33 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Fri, 20 Apr 2001 02:42:33 (NZST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange Message-ID: <98769135301942@kahu.cs.auckland.ac.nz> Toth Csaba writes: >On Thu, 19 Apr 2001, Peter Gutmann wrote: >>If you need a secured link, why not just use the ssh client/server code, or >>grab the SSLv3 spec/TLS RFC and pick apart the final bit of the SSL >>client/server handshake where it fails when sending the MAC? > >Because unfortunately I don't have enough time for it. I've allready spent a >lot of time to implement onion routing components Oh, sorry, I'd forgotten that you were doing onion routing. In that case I guess you'd have to go with RSA... the X9.42 DH isn't much better than RSA anyway in terms of PFS because one side is forced to permanently freeze their DH parameters in a certificate, if you use the so-called static-static DH then you get something with no PFS and none of the properties of RSA, the only reason it works at all is that you have to mix in externally-provided keying material (UKM), which is another reason why even cryptlib's ...Ex() functions aren't sufficient to handle this (you can see why X9.42 has been such a roaring success in the real world). cryptlib's ssh implementation actually implements PFS via RSA because it uses a new RSA key for each connection and destroys it as soon as the connection is established. Peter. From cryptlib@mbsks.franken.de Fri Apr 20 06:46:42 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Fri, 20 Apr 2001 05:46:42 (NZST) Subject: [CRYPTLIB] tsa Message-ID: <98770240203094@kahu.cs.auckland.ac.nz> "Luciano Benetti" writes: >I'm using the library beta 5 with Delphi 5 and smartcard Schlumberger. I made >a small program to administrate a TSA server session which stays in stand-by >and wait the call of the client. Here is the source code of the server: > >[...] > >Following this last raw of the server program, there I get an assert at line >686 of the stream.c > >stream->flags & STREAM_FLAG_READONLY In the code segment at line 381 of session/tsp.c, replace the sMemConnect() line with: sMemOpen( &stream, bufPtr, 4 + 5 ); Building a non-debug version will also get rid of the assertion. Peter. From cryptlib@mbsks.franken.de Fri Apr 20 12:09:08 2001 From: cryptlib@mbsks.franken.de (Lin Wang) Date: Fri, 20 Apr 2001 19:09:08 +0800 Subject: [Cryptlib] (no subject) References: Message-ID: <000901c0c98a$52b5f460$118175ca@wl> SGksemhvbmdfZHVoYW5nDQoNCiAgICBUaGFuayB5b3UgZm9yIHlvdXIgaGVscCwgYW5kIEkgdHJp ZWQgeW91ciBtZXRob2QgZm9yIG1hbnkgdGltZXMgd2l0aG91dCBzdWNjZXNzLkNvdWxkIHlvdSBw bGVhc2Ugc2hvdyBtZSB0aGUgc2FtcGxlIGNvZGU/IFRoYW5rIHlvdS4NCg0KLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJ6aG9uZ19kdWhhbmciIDx6aG9uZ19kdWhhbmdAMjFj bi5jb20+DQpUbzogPGNyeXB0bGliQG1ic2tzLmZyYW5rZW4uZGU+DQpTZW50OiBNb25kYXksIEFw cmlsIDIzLCAyMDAxIDI6MTMgUE0NClN1YmplY3Q6IFJlOiBbQ3J5cHRsaWJdIChubyBzdWJqZWN0 KQ0KDQoNCj4gzfXB1qOsxPq6w6OhDQo+IA0KPiBmaXJzdCAseW91IGNhbiBleHBvcnQgdGhlIGNl cnQgdG8gYSBidWZmZXIgdXNlIHRoZSBmdW5jdGlvbiBjcnlwdEV4cG9ydENlcnQoKTt0aGVuIHlv dSB3cml0ZSB0aGUgYnVmZmVyIHRvIGEgZmlsZSAoZm9yIGV4YW1wbGUgDQo+IGFhLmRlcikNCj4g YW5kIGl0IGlzIE9LIQ0KPiANCj4g1NogMjAwMS0wNC0xNiAwOTozNDowMCDE+tC0tcCjug0KPiA+ SGVsbG8sIGV2ZXJ5IGNyeXB0TGliIGRldmVsb3BlcjoNCj4gPg0KPiA+ICAgICAgICBOb3csIEkn bSB1c2luZyBjcnlwdGxpYiBtYWtpbmcgYSBwcm9qZWN0IHVuZGVyIFZpc3VhbCBCYXNpYy4gSSBo YXZlIGEgcHJvYmxlbSB3aXRoIGNlcnRpZmljYXRlOiBJIGRvbid0IGtub3cgaG93IHRvIG1ha2Ug YSBkaXNrIGZpbGUgb2YgYSBjZXJ0aWZpY2F0ZSwgaS5lLiwgbWFrZSBhIGNlciBmaWxlIG9mIGEg Y2VydGlmaWNhdGUgc2hjaCB0aGF0IGl0IGNhbiBiZSBkaXNwbGF5ZWQgYXV0b21hdGljYWxseSB3 aGVuIGNsaWNrZWQuIENvdWxkIHNvbWVvbmUgcGxlYXNlIHRlbGwgbWUgaG93PyBUaGFuayB5b3Uh DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaW5jZXJlbHkgWW91cnMNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExpbiBXYW5nDQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID53YW5nbGluQHhpeW91LmVkdS5jbg0KPiANCj4gICAg ICAgICAgICAgICAgICAgICDWwg0KPiDA8aOhDQo+IA0KPiAgICAgICAgICAgICB6aG9uZ19kdWhh bmcNCj4gICAgICAgICAgICAgemhvbmdfZHVoYW5nQDIxY24uY29tDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ3J5cHRsaWIgbWFp bGluZyBsaXN0DQo+IENyeXB0bGliQG1ic2tzLmZyYW5rZW4uZGUNCj4gaHR0cDovL3RoZS13ZWIt aW50ZXJmYWNlLWRvZXMtbm90LXdvcmsvbWFpbG1hbi9saXN0aW5mby9jcnlwdGxpYg0KPiANCg== From cryptlib@mbsks.franken.de Sun Apr 22 19:27:19 2001 From: cryptlib@mbsks.franken.de (Paul Hurley) Date: Sun, 22 Apr 2001 14:27:19 -0400 Subject: [Cryptlib] Silly Newbie Question In-Reply-To: <000901c0c98a$52b5f460$118175ca@wl> Message-ID: Greetings all, I have an Windows-based email delivery application under development, and I'm looking into adding S/MIME signing and encryption options. I want to keep it as simple as possible, for me and my users. I've looked at CryptoAPI (yuk) and now Cryptlib. I'd like to do as little cert management as possible. If the user already has certs "somewhere" on the system, I'd like to be able to access them. CryptoAPI has a the concept of a "system store", but I can't seem to find something similar in Cryptlib. Is it possible to get a handle to the "standard" Windows store, and locate an appropriate cert for use by the enveloping functions for S/MIME? Thanks Paul --- Paul Hurley Caliban Computing http://www.caliban.com From cryptlib@mbsks.franken.de Sun Apr 22 22:34:06 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Sun, 22 Apr 2001 23:34:06 +0200 (MET DST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange In-Reply-To: <98769135301942@kahu.cs.auckland.ac.nz> Message-ID: Hi! Thanks for your answer. On Fri, 20 Apr 2001, Peter Gutmann wrote: >Oh, sorry, I'd forgotten that you were doing onion routing. In that case I >guess you'd have to go with RSA... Ok, I've implemented a Needham-Schroeder 3 phase PK key agreement protocol, with RSA. The two key (one for backward, and one for the forward data flow) are generated correctly on both side, so I initialize two DES OFB, IV=0 contexts on both side. But unfotunately, I cannot get the link encrypted data back on the opposite side (after decrypting, I got random data). The two onion router test component are located on the same machine. I use static cryptlib library. Now there is an exciting thing: sometimes, the the CRYPT_CONTEXT variables of the two components are exactly the same (I mean, CRYPT_CONTEXT is actually an integer, and equal integer handles are generated on the opposite side). Can this strange thing affect cryptlib's behaviour? Are two separate cryptlib kernel working for the two onion router? The key agreement and the context generation are coded in a separate module, and the onion routers call functions form this module (exchange() and get2context()). Or is there any special thing about OFB mode? Is it important if I do cryptEncrypt or cryptDecrypt (I think yes, and I try to follow this). Anyway, I think that I do somewthing nasty little bug (as usually the case), but I couldn't find it yet. It is interesting, that the anonym DES OFB en/decryption is working fine. >the X9.42 DH isn't much better than RSA >anyway in terms of PFS because one side is forced to permanently freeze their >DH parameters in a certificate, if you use the so-called static-static DH then The NRL team were originally do an STS (the most secure Diffie-Helman method in teh Applied Cryptography). Is RSA Needham-Schroeder PK key agreement weaker than STS? Thanks. -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Mon Apr 23 08:46:40 2001 From: cryptlib@mbsks.franken.de (cryptlib@mbsks.franken.de) Date: Mon, 23 Apr 2001 09:46:40 +0200 Subject: [Cryptlib] cryptlib question Message-ID: Hello, I would like to get the keys( symmetric and asymmetric ) from a context CRYPT_CONTEXT. How can I do that? Think you for your help. Laurence DUQUERROY From cryptlib@mbsks.franken.de Tue Apr 24 03:40:44 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Tue, 24 Apr 2001 02:40:44 (NZST) Subject: [Cryptlib] Silly Newbie Question Message-ID: <98803684421043@kahu.cs.auckland.ac.nz> "Paul Hurley" writes: >I have an Windows-based email delivery application under development, and I'm >looking into adding S/MIME signing and encryption options. I want to keep it >as simple as possible, for me and my users. I've looked at CryptoAPI (yuk) >and now Cryptlib. I'd like to do as little cert management as possible. If >the user already has certs "somewhere" on the system, I'd like to be able to >access them. CryptoAPI has a the concept of a "system store", but I can't >seem to find something similar in Cryptlib. Is it possible to get a handle to >the "standard" Windows store, and locate an appropriate cert for use by the >enveloping functions for S/MIME? Everything about MS's cert and key storage is completely undocumented, so there's no way you can get at the certs and keys unless you reverse-engineer the access mechanisms and storage formats (that is, you can get at the certs via CryptoAPI, but without the corresponding keys you can't do much with them). Peter. From cryptlib@mbsks.franken.de Tue Apr 24 06:45:28 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Tue, 24 Apr 2001 05:45:28 (NZST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange Message-ID: <98804792826176@kahu.cs.auckland.ac.nz> Toth Csaba writes: >I've implemented a Needham-Schroeder 3 phase PK key agreement protocol, with >RSA. The two key (one for backward, and one for the forward data flow) are >generated correctly on both side, so I initialize two DES OFB, IV=0 contexts >on both side. This is really bad, what this does is create a fixed keystream which means if any of the keystream is ever reused in some way you can trivially recover the plaintext. I'd use anything other than this mode, it's probably the least secure way you can use a block cipher. >The two onion router test component are located on the same machine. I use >static cryptlib library. Now there is an exciting thing: sometimes, the the >CRYPT_CONTEXT variables of the two components are exactly the same (I mean, >CRYPT_CONTEXT is actually an integer, and equal integer handles are generated >on the opposite side). Can this strange thing affect cryptlib's behaviour? Are >two separate cryptlib kernel working for the two onion router? The key >agreement and the context generation are coded in a separate module, and the >onion routers call functions form this module (exchange() and get2context()). So you've got two different applications both statically linked to cryptlib? They won't share anything (well, unless you've done something really strange with shared memory :-). Can you encrypt/decrypt data using your code if both sides of the exchange are talking directly to each other? This is what the self-test code does, eg look at what testKeyExportImport() in test/testhl.c does (it exports and imports a key, then encrypts and decrypts using the original and recreated key to make sure the exchange worked). >Or is there any special thing about OFB mode? Is it important if I do >cryptEncrypt or cryptDecrypt (I think yes, and I try to follow this). No, in OFB mode you can use either encrypt or decrypt since you're just XORing with a fixed keystream. >The NRL team were originally do an STS (the most secure Diffie-Helman method >in teh Applied Cryptography). Is RSA Needham-Schroeder PK key agreement weaker >than STS? I couldn't answer that offhand (or at least I'd answer it by referring to HAC or something, because it's not something I work with much), but in general there are a whole class of key exchange mechanisms which offer about the same level of security/service, STS is nice and clean but doesn't hold a monopoly on good key exchange. Peter. From cryptlib@mbsks.franken.de Tue Apr 24 23:41:15 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Wed, 25 Apr 2001 00:41:15 +0200 (MET DST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange In-Reply-To: <98804792826176@kahu.cs.auckland.ac.nz> Message-ID: Hi! On Tue, 24 Apr 2001, Peter Gutmann wrote: >>generated correctly on both side, so I initialize two DES OFB, IV=0 contexts >>on both side. > >This is really bad, what this does is create a fixed keystream which means if >any of the keystream is ever reused in some way you can trivially recover the >plaintext. I'd use anything other than this mode, it's probably the least >secure way you can use a block cipher. Hmm. You say something. But as I can remember, in the NRL plans they used OFB because an attacker could modify the data stream. So if the attacker once modify the stream, than the communication channel won't recover from the error and produce random data. In other words: the attacker's action causes a DoS, but the identity of teh two communicating parties won't revealed. So such a mode of operation is needed, which cannot recover from errors (modifications). It might be my memory is malfunctioning, and I should use CFB. I'll look it up. I don't know what "reuse" means. I think I don't reuse the key stream. I think it is impossible to dig the key stream out from cryptlib secure kernel. >So you've got two different applications both statically linked to cryptlib? >They won't share anything (well, unless you've done something really strange >with shared memory :-). Ok. So of course I've made some several bugs, but now the laboratory test version is working!!! Time to make some measurments (connection setup delay, crypto overhead), and to write the thesis itself. >Can you encrypt/decrypt data using your code if both sides of the exchange are >talking directly to each other? This is what the self-test code does, eg look >at what testKeyExportImport() in test/testhl.c does (it exports and imports a >key, then encrypts and decrypts using the original and recreated key to make >sure the exchange worked). There were other kind of errors. In fact I don't know why I started to whinning here at the list after some debugging. After one sleep, I've found the bugs. >I couldn't answer that offhand (or at least I'd answer it by referring to HAC >or something, because it's not something I work with much), but in general >there are a whole class of key exchange mechanisms which offer about the same >level of security/service, STS is nice and clean but doesn't hold a monopoly on >good key exchange. What is your opinion about this Needham-Scrhoeder PK KA? I've looked it up in the Handbook of Applied Cryptography. Cryptlib is a great tool! Bye! -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Wed Apr 25 11:17:50 2001 From: cryptlib@mbsks.franken.de (WeiSheng Chong) Date: Wed, 25 Apr 2001 03:17:50 -0700 (PDT) Subject: [Cryptlib] #cryptlib 3.0 beta package includes cl32ui.dll file? Message-ID: <20010425101750.44980.qmail@web12106.mail.yahoo.com> Hi, #cryptlib 3.0 beta package includes CL32ui.dll file? I wish to know is cryptlib 3.0 beta package includes the cl32ui.dll file? I couldn't found it from the downloaded file from the cryptlib web*. According to the cryptlib 3.0 beta users guide and manual( page 11), the cl32ui.dll is needed to use the cryptolib user interface. Please send me the cl32ui.dll file if you have one. Thank you. -- Regards, Chong Wei Sheng Research Student *the the cryptlib 3.0 beta at cryptlib web ftp://ftp.franken.de/pub/crypt/cryptlib/beta/cl30beta05.zip __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From cryptlib@mbsks.franken.de Wed Apr 25 11:21:56 2001 From: cryptlib@mbsks.franken.de (WeiSheng Chong) Date: Wed, 25 Apr 2001 03:21:56 -0700 (PDT) Subject: [Cryptlib] #where to get the archive of cryptlib mailist list? Message-ID: <20010425102156.12600.qmail@web12104.mail.yahoo.com> Hi, #where to search the archive of cryptlib mailist list? As a new participant in this mailist list, I wish to know where to get the archive of cryptlib mailist list. I can't get this information from the dead link of http://the-web-interface-does-not-work/mailman/listinfo/cryptlib Thank you. -- Regards, Chong Wei Sheng Research Student *the the cryptlib 3.0 beta at cryptlib web ftp://ftp.franken.de/pub/crypt/cryptlib/beta/cl30beta05.zip __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From cryptlib@mbsks.franken.de Wed Apr 25 12:14:09 2001 From: cryptlib@mbsks.franken.de (WeiSheng Chong) Date: Wed, 25 Apr 2001 04:14:09 -0700 (PDT) Subject: [Cryptlib] #minor page reference error in cryptlib manual Message-ID: <20010425111409.1752.qmail@web12105.mail.yahoo.com> hi, #minor page reference error in cryptlib manual the "algorithms and modes" could be found in page 199 but not page 191 (as mentioned in page 206) and page page 196 (as mentioned in page 69). I hope this help to make the manual better. thank you. -- Vincent __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From cryptlib@mbsks.franken.de Thu Apr 26 06:40:23 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Thu, 26 Apr 2001 05:40:23 (NZST) Subject: [Cryptlib] Begging: please help in Diffie-Helman key exchange Message-ID: <98822042300378@kahu.cs.auckland.ac.nz> Toth Csaba writes: >Hmm. You say something. But as I can remember, in the NRL plans they used OFB >because an attacker could modify the data stream. So if the attacker once >modify the stream, than the communication channel won't recover from the error >and produce random data. In other words: the attacker's action causes a DoS, >but the identity of teh two communicating parties won't revealed. It'll certainly cause a DOS, but with OFB an attacker can corrupt data in transit unless you also MAC it (which will cause just as much of a DOS as the use of a non-OFB mode). >I don't know what "reuse" means. I think I don't reuse the key stream. I think >it is impossible to dig the key stream out from cryptlib secure kernel. If used properly you won't reuse the keystream, however it's very easy to get this wrong (Microsoft are experts at this, every single time they've used RC4 (effectively an OFB-mode cipher) they've got it wrong and reused keystream somewhere, covering a period of nearly ten years(!!)). Someone once made the comment that "If RC4 were a child's toy, it'd be recalled as too dangerous". >What is your opinion about this Needham-Scrhoeder PK KA? I've looked it up >in the Handbook of Applied Cryptography. It's OK, but there are many other alternatives. I rather like the ssh handshake because it's simple and clean and gives you PFS with RSA keys, but it doesn't do mutual authentication in the initial handshake like Needham- Schroeder does. Peter. From cryptlib@mbsks.franken.de Wed Apr 25 19:34:11 2001 From: cryptlib@mbsks.franken.de (cryptlib@mbsks.franken.de) Date: Wed, 25 Apr 2001 20:34:11 +0200 Subject: [Cryptlib] #where to get the archive of cryptlib mailist list? In-Reply-To: <20010425102156.12600.qmail@web12104.mail.yahoo.com>; from cwsheng@yahoo.com on Wed, Apr 25, 2001 at 03:21:56AM -0700 References: <20010425102156.12600.qmail@web12104.mail.yahoo.com> Message-ID: <20010425203411.D1479@mbsks.franken.de> Mahlzeit On Wed, Apr 25, 2001 at 03:21:56AM -0700, WeiSheng Chong wrote: > As a new participant in this mailist list, I wish > to know where to get the archive of cryptlib mailist > list. With the old mailing list software one could have requested the archive via mail, which caused often problems, because a lot of people where not allowed to receive mails with the size of a few mega bytes. If someone want's it, I can put it on the ftp server. How much do you want? The whole archive is uncompressed about 4.3MB. Mahlzeit endergone Zwiebeltuete From cryptlib@mbsks.franken.de Wed Apr 25 20:34:58 2001 From: cryptlib@mbsks.franken.de (Thomas Blood) Date: Wed, 25 Apr 2001 12:34:58 -0700 Subject: [Cryptlib] #where to get the archive of cryptlib mailist list? References: <20010425102156.12600.qmail@web12104.mail.yahoo.com> <20010425203411.D1479@mbsks.franken.de> Message-ID: <3AE726E2.7060802@safevote.com> --------------050402000206050707070503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hallo endergone Zwiebeltuete, I would like access to the complete archive, although compressed would be better. Guten Appetit, Thomas m@mbsks.franken.de wrote: > Mahlzeit > > > On Wed, Apr 25, 2001 at 03:21:56AM -0700, WeiSheng Chong wrote: > >> As a new participant in this mailist list, I wish >> to know where to get the archive of cryptlib mailist >> list. > > > With the old mailing list software one could have requested the > archive via mail, which caused often problems, because a lot of > people where not allowed to receive mails with the size of a > few mega bytes. > > If someone want's it, I can put it on the ftp server. How much > do you want? The whole archive is uncompressed about 4.3MB. > > > Mahlzeit > > endergone Zwiebeltuete > > > _______________________________________________ > Cryptlib mailing list > Cryptlib@mbsks.franken.de > http://the-web-interface-does-not-work/mailman/listinfo/cryptlib > > > > --------------050402000206050707070503 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo endergone Zwiebeltuete,

I would like access to the complete archive, although compressed would be better.

Guten Appetit,

Thomas

m@mbsks.franken.de wrote:
Mahlzeit


On Wed, Apr 25, 2001 at 03:21:56AM -0700, WeiSheng Chong wrote:
   As a new participant in this mailist list, I wish
to know where to get the archive of cryptlib mailist
list. 

With the old mailing list software one could have requested the
archive via mail, which caused often problems, because a lot of
people where not allowed to receive mails with the size of a
few mega bytes.

If someone want's it, I can put it on the ftp server. How much
do you want? The whole archive is uncompressed about 4.3MB.


Mahlzeit

endergone Zwiebeltuete


_______________________________________________
Cryptlib mailing list
Cryptlib@mbsks.franken.de
http://the-web-interface-does-not-work/mailman/listinfo/cryptlib





--------------050402000206050707070503-- From cryptlib@mbsks.franken.de Wed Apr 25 21:29:52 2001 From: cryptlib@mbsks.franken.de (cryptlib@mbsks.franken.de) Date: Wed, 25 Apr 2001 22:29:52 +0200 Subject: [Cryptlib] Archive Message-ID: <20010425222952.A1431@mbsks.franken.de> Mahlzeit The all past postings are now at: ftp://ftp.franken.de/pub/crypt/cryptlib/cryptlib-ml-20010425.zip Mahlzeit endergone Zwiebeltuete From cryptlib@mbsks.franken.de Wed Apr 25 23:59:30 2001 From: cryptlib@mbsks.franken.de (Toth Csaba) Date: Thu, 26 Apr 2001 00:59:30 +0200 (MET DST) Subject: [Cryptlib] I have to correct myself In-Reply-To: <98822042300378@kahu.cs.auckland.ac.nz> Message-ID: Hi! On Thu, 26 Apr 2001, Peter Gutmann wrote: >It'll certainly cause a DOS, but with OFB an attacker can corrupt data in >transit unless you also MAC it (which will cause just as much of a DOS as the >use of a non-OFB mode). In fact, modification in OFB or CFB generated ciphertext will not cause an endless corruption in data (a minor correction of myself). NRL project want to use only some kind of stream cipher, not exactly OFB. But in their implementation, they used OFB mode. The use of a stream cipher will make an attackers life harder: he couldn't reply cells so easily, and data corruption occurs in case of data modification (this was the original reason, why they used stream cipher). Because CFB mode of operation is a stream cipher too, and as I can see it is more secure than OFB mode (see keystream reuseing) maybe I should use CFB. In the original design there is not any MAC. Maybe it should be used later. I'll ask the NRL researchers about this some time. >>I don't know what "reuse" means. I think I don't reuse the key stream. I think >>it is impossible to dig the key stream out from cryptlib secure kernel. Please don't take my question seriously :) My brain went to vacation :) >If used properly you won't reuse the keystream, however it's very easy to get >this wrong (Microsoft are experts at this, every single time they've used RC4 >(effectively an OFB-mode cipher) they've got it wrong and reused keystream >somewhere, covering a period of nearly ten years(!!)). Someone once made the >comment that "If RC4 were a child's toy, it'd be recalled as too dangerous". That's good :))))) >It's OK, but there are many other alternatives. I rather like the ssh >handshake because it's simple and clean and gives you PFS with RSA keys, but it >doesn't do mutual authentication in the initial handshake like Needham- >Schroeder does. Ok, so it will be perfect for testing in our lab. I think, that the authentication is important. Thanks for your help! -- tocsa ------------------------------------------------------------- | email: s8217tot@hszk.bme.hu, tocsa@inf.bme.hu | | homepage: www.hszk.bme.hu/~s8217tot, www.inf.bme.hu/~tocsa | ------------------------------------------------------------- From cryptlib@mbsks.franken.de Fri Apr 27 14:15:24 2001 From: cryptlib@mbsks.franken.de (xli) Date: Fri, 27 Apr 2001 21:15:24 +0800 Subject: [Cryptlib] how can cryptlib work with language other than english Message-ID: <00dd01c0cf1c$1ecf4d30$0dccfea9@free> This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C0CF5F.2CD3E1A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGw6DQoNCkkgaGF2ZSBjcmVhdGUgYSBDQSB3aXRoIGNyeXB0bGliIGFuZCBpdCB3b3Jr IHdlbGwgaW4gZW5nbGlzaCBETnMsIGJ1dCB3aGVuIEkgaW5wdXQgc2ltcGx5IGNoaW5lc2UgaW4g Q29tbW9uTmFtZSwgT3JnYW5pemF0aW9uTmFtZS4uLiAgaXQgYXBlYXIgcmFuZG9tIGNvZGUuIEhv dyBjYW4gY3J5cHRsaWIgd29yayB3aXRoIHNpbXBseSBjaGluZXNlPw0KDQp0aGFua3MhDQoNCmxp eGluDQo= ------=_NextPart_000_00DA_01C0CF5F.2CD3E1A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjYwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj5EZWFyIEFsbDo8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgaGF2ZSBjcmVhdGUgYSZuYnNwO0NBIHdp dGggY3J5cHRsaWIgYW5kIGl0IHdvcmsgd2VsbCBpbiBlbmdsaXNoIEROcywgYnV0IA0Kd2hlbiBJ IGlucHV0IHNpbXBseSBjaGluZXNlIGluIENvbW1vbk5hbWUsIE9yZ2FuaXphdGlvbk5hbWUuLi4m bmJzcDsgaXQgYXBlYXIgDQpyYW5kb20gY29kZS4gSG93IGNhbiBjcnlwdGxpYiB3b3JrIHdpdGgg c2ltcGx5IGNoaW5lc2U/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj50aGFua3MhPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5saXhpbjwvRElWPjwvRk9OVD48L0RJVj48L0JP RFk+PC9IVE1MPg0K ------=_NextPart_000_00DA_01C0CF5F.2CD3E1A0-- From cryptlib@mbsks.franken.de Fri Apr 27 14:08:02 2001 From: cryptlib@mbsks.franken.de (xli) Date: Fri, 27 Apr 2001 21:08:02 +0800 Subject: [Cryptlib] client certificate not found in in selection dialog box of IE5.0 References: Message-ID: <00d201c0cf1b$17932600$0dccfea9@free> This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C0CF5E.2509AB40 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: base64 RGVhciBBbGw6DQoNCkkgaGF2ZSBjcmVhdGUgYSBjbGllbnQgY2VydGlmaWNhdGUgd2l0aCBjcnlw dGxpYiBhbmQgc2V0dXAgU1NMIGNvbmVjdGlvbiB0byBJSVM1LjAgaW4gd2luMjAwMCwgIGJ1dCBJ IGNhbiBub3QgZm91bmQgbXkgY2VydGlmaWNhdGUgaW4gdGhlIGNlcnRpZmljYXRlcyBzZWxlY3Rp b24gZGlhbG9nIGJveCEgSSBhbSBzdXJlIEkgaGF2ZSBpbnN0YWxsIHRoZSBjZXJ0aWZpY2F0ZSBj b3JyZWN0bHksIGJlY2F1c2UgSSBjYW4gZmluZCBpdCBpbiAiVG9vbHMtPk9wdGlvbi0+Q29udGVu dC0+Q2VydGlmaWNhdGVzIiBkaWFsb2cgb2YgSUU1LjAuIFdoYXQgaXMgd3JvbmchDQpJIGF0dGFj aCBteSBDQSBjZXJ0aWZpY2F0ZSBhbmQgdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZSBpbiB0aGlzIGxl dHRlci4gSSBoYXZlIHVzZWQgbXkgcHJvZ3JhbSB0byBjcmVhdGUgZW1haWwgcHJvdGVjdCBjZXJ0 aWZpY2F0ZSBhbmQgaXQgd29yayB3ZWxsIGluIG91dGxvb2sgZXhwcmVzcy4NCg0KdGhhbmtzIQ0K DQpsaXhpbg0K ------=_NextPart_000_00D0_01C0CF5E.2509AB40 Content-Type: application/x-x509-ca-cert; name="client.der" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="client.der" -----BEGIN CERTIFICATE----- MIICuTCCAmOgAwIBAgIIYUFix+lxl7MwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAkNOMRAwDgYDVQQIEwdiZWlqaW5nMRAwDgYDVQQHEwdiZWlqaW5nMR4wHAYD VQQKExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEZMBcGA1UEAxMQUm9vdCBDZXJ0aWZpY2F0ZTAeFw0wMTA0Mjcx MjU3MzdaFw0wMjA0MjcxMjU3MzdaMF8xCzAJBgNVBAYTAkNOMRAwDgYDVQQIEwdi ZWlqaW5nMRAwDgYDVQQHEwdiZWlqaW5nMQ0wCwYDVQQKEwRmcmVlMQ0wCwYDVQQL EwRmcmVlMQ4wDAYDVQQDEwVsaXhpbjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCv fNQq5vx3l9y5GRsQNEOE6vW2smIt9DERaSJ9DEwnlNtQZr0/Q1IeV2tm1GKht3Yf S+algNUvp908XMIUemN/AgMBAAGjgdQwgdEwNwYIKwYBBQUHAQEEKzApMCcGCCsG AQUFBzABhhtodHRwOi8vd3d3LmNhMzY1LmNvbS9DQUluZm8wHQYDVR0OBBYEFLXn 5psWfm4mW0NrGw3cNOCaVDaGMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMBAf8EAjAA MC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly93d3cuY2EzNjUuY29tL2NlcnQuY3Js MCkGA1UdIwQiMCCAFAIbvzkComIjxv4HzpYlg0ZiZsVsgghR8BB4xd6ixDANBgkq hkiG9w0BAQUFAANBAD4+Z4uiccQC7l/Wj07C5UxLhHV2FRydVKn1tJaAPWxMeCEa ZxkPBieP35Jbisiv+m+xCV0RbydEUt1KXbwQ8jE= -----END CERTIFICATE----- ------=_NextPart_000_00D0_01C0CF5E.2509AB40 Content-Type: application/x-x509-ca-cert; name="root.der" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="root.der" -----BEGIN CERTIFICATE----- MIICvzCCAmmgAwIBAgIIUfAQeMXeosQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAkNOMRAwDgYDVQQIEwdiZWlqaW5nMRAwDgYDVQQHEwdiZWlqaW5nMR4wHAYD VQQKExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEZMBcGA1UEAxMQUm9vdCBDZXJ0aWZpY2F0ZTAeFw0wMTA0MjYw NjUwMjdaFw0yMTA0MjEwNjUwMjdaMIGMMQswCQYDVQQGEwJDTjEQMA4GA1UECBMH YmVpamluZzEQMA4GA1UEBxMHYmVpamluZzEeMBwGA1UEChMVQ2VydGlmaWNhdGUg QXV0aG9yaXR5MR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGTAXBgNV BAMTEFJvb3QgQ2VydGlmaWNhdGUwXDANBgkqhkiG9w0BAQEFAANLADBIAkEA21U+ e8NLs0aWupdWxcm23QA4WA5I/dvXjc1O90ilHYL81H6rw0KARfwjy4+9MYzcwXWG 1KmQbdh8CkitDDXRHwIDAQABo4GsMIGpMDcGCCsGAQUFBwEBBCswKTAnBggrBgEF BQcwAYYbaHR0cDovL3d3dy5jYTM2NS5jb20vQ0FJbmZvMB0GA1UdDgQWBBQCG785 AqJiI8b+B86WJYNGYmbFbDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zAuBgNVHR8EJzAlMCOgIaAfhh1odHRwOi8vd3d3LmNhMzY1LmNvbS9yb290LmNy bDANBgkqhkiG9w0BAQUFAANBAMkw+j6KZbr9GnzJ2SzRPDdoTS6yQik0slNFf2Vj Neud5eks2Wt/dC7++U+ztEvUzNI26oi5bO7p80xBUjY/yuY= -----END CERTIFICATE----- ------=_NextPart_000_00D0_01C0CF5E.2509AB40-- From cryptlib@mbsks.franken.de Sat Apr 28 07:39:55 2001 From: cryptlib@mbsks.franken.de (Peter Gutmann) Date: Sat, 28 Apr 2001 06:39:55 (NZST) Subject: [Cryptlib] how can cryptlib work with language other than english Message-ID: <98839679519601@kahu.cs.auckland.ac.nz> "xli" writes: >I have create a CA with cryptlib and it work well in english DNs, but when I >input simply chinese in CommonName, OrganizationName... it apear random code. >How can cryptlib work with simply chinese? cryptlib doesn't care what you put in a name, it just encodes and decodes the data, however I have no idea what Windows might do to the string values. You could step through the code in keymgmt/certstr.c to see if they're being mangled in some way by the Windows internationalisation routines (or lack thereof, experiments with Windows i18n functions in a command-line utility have produced all sorts of weird results). >I have create a client certificate with cryptlib and setup SSL conection to >IIS5.0 in win2000, but I can not found my certificate in the certificates >selection dialog box! I am sure I have install the certificate correctly, >because I can find it in "Tools->Option->Content->Certificates" dialog of >IE5.0. What is wrong! That's a Windows problem, you'd have to contact Microsoft for help (maybe someone on the CryptoAPI list will know the answer). Peter. From cryptlib@mbsks.franken.de Fri Apr 27 20:52:26 2001 From: cryptlib@mbsks.franken.de (Victor Gimeno) Date: Fri, 27 Apr 2001 14:52:26 -0500 Subject: [Cryptlib] client certificate not found in in selection dialog box of IE5.0 In-Reply-To: <00d201c0cf1b$17932600$0dccfea9@free> Message-ID: You have to install the CA on your web server. run MCC.exe select Console->Add/Remove Snap-in click on the Add Button Double click con Certificates Select Computer account radio button Click on Next , an then Finish Click Close Click OK Then select from the list Certificates then do a rigth click on Trusted Root Certification Authorities Select from the popup menu All Tasks then select Import. Then just follow the Wizard. Good luck -----Mensaje original----- De: cryptlib-admin@mbsks.franken.de [mailto:cryptlib-admin@mbsks.franken.de]En nombre de xli Enviado el: Viernes, 27 de Abril de 2001 08:08 a.m. Para: cryptlib@mbsks.franken.de Asunto: [Cryptlib] client certificate not found in in selection dialog box of IE5.0 Dear All: I have create a client certificate with cryptlib and setup SSL conection to IIS5.0 in win2000, but I can not found my certificate in the certificates selection dialog box! I am sure I have install the certificate correctly, because I can find it in "Tools->Option->Content->Certificates" dialog of IE5.0. What is wrong! I attach my CA certificate and the client certificate in this letter. I have used my program to create email protect certificate and it work well in outlook express. thanks! lixin From cryptlib@mbsks.franken.de Sun Apr 29 10:45:40 2001 From: cryptlib@mbsks.franken.de (xli) Date: Sun, 29 Apr 2001 17:45:40 +0800 Subject: [Cryptlib] client certificate was not comparible with IE5 and IIS5 Message-ID: <004201c0d091$27aa2030$0dccfea9@free> This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C0D0D4.34EB3D90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003F_01C0D0D4.34ECC430" ------=_NextPart_001_003F_01C0D0D4.34ECC430 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGw6DQoNCkkgaGF2ZSBjcmVhdGUgYSBjbGllbnQgY2VydGlmaWNhdGUgd2l0aCBjcnlw dGxpYiBhbmQgc2V0dXAgU1NMIGNvbmVjdGlvbiB0bw0KSUlTNS4wIGluIHdpbjIwMDAsIGJ1dCB3 aGVuIEkgc2VsZWN0IG15IGNlcnRpdGljYXRlIGluIHRoZSBjZXJ0aWZpY2F0ZXMNCnNlbGVjdGlv biBkaWFsb2cgYm94IG9mIElFNSwgSSBhbHdheXMgZ290IHRoZSBlcnJvciBvZiBteSBjbGllbnQg Y2VydGlmaWNhdGUgaXMgbm90IGVmZmVjdGl2ZS4gV2hhdCBpcyB3cm9uZyENCg0KSSBhdHRhY2gg bXkgQ0EgY2VydGlmaWNhdGUgYW5kIHRoZSBjbGllbnQgY2VydGlmaWNhdGUgaW4gdGhpcyBsZXR0 ZXIuIFdobyBjYW4gaGVscCBtZT8gdGhhbmsgeW91IHZlcnkgbXVjaCENCg0KdGhhbmtzIQ0KDQps aXhpbg0KDQo= ------=_NextPart_001_003F_01C0D0D4.34ECC430 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjYwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mz5EZWFy IEFsbDo8QlI+PEJSPkkgaGF2ZSBjcmVhdGUgYSBjbGllbnQgDQpjZXJ0aWZpY2F0ZSB3aXRoIGNy eXB0bGliIGFuZCBzZXR1cCBTU0wgY29uZWN0aW9uIHRvPEJSPklJUzUuMCBpbiANCndpbjIwMDAs Jm5ic3A7YnV0IHdoZW4mbmJzcDtJIHNlbGVjdCBteSBjZXJ0aXRpY2F0ZSBpbiB0aGUgDQpjZXJ0 aWZpY2F0ZXM8QlI+c2VsZWN0aW9uIGRpYWxvZyBib3ggb2YgSUU1LCBJIGFsd2F5cyBnb3QgdGhl IGVycm9yIG9mIG15IGNsaWVudCANCmNlcnRpZmljYXRlIGlzIG5vdCBlZmZlY3RpdmUuIFdoYXQg aXMgd3JvbmchPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNp emU9Mz48QlI+SSBhdHRhY2ggbXkgQ0EgY2VydGlmaWNhdGUgYW5kIHRoZSBjbGllbnQgDQpjZXJ0 aWZpY2F0ZSBpbiB0aGlzIGxldHRlci4gV2hvIGNhbiBoZWxwIG1lPyB0aGFuayB5b3UgdmVyeSAN Cm11Y2ghPEJSPjxCUj50aGFua3MhPEJSPjxCUj5saXhpbjwvRk9OVD48QlI+PC9ESVY+PC9GT05U PjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_001_003F_01C0D0D4.34ECC430-- ------=_NextPart_000_003E_01C0D0D4.34EB3D90 Content-Type: application/x-pkcs12; name="client.pfx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="client.pfx" MIIHwAIBAzCCB3wGCSqGSIb3DQEHAaCCB20EggdpMIIHZTCCAtYGCSqGSIb3DQEHAaCCAscEggLD MIICvzCCArsGCyqGSIb3DQEMCgECoIIBjjCCAYowHAYKKoZIhvcNAQwBAzAOBAgf+OYsY56VTwIC B9AEggFoPLAKTtLjxOqVyP1mZXxJu08BKBMORrF7N+D4N8fxWVPF6/kkBtikfLSD6MnIq+pxfoAp lDUTY8JOOQ6xKe16OJ98Pk3SoavW1gbKDdXuEB4JKeBYhNr3cfQgUQk5H4cvVTr8jf90PYzqXlkg zfGj+uamsapX0DZt0G34ACDlXL/lCYzI7qMnlmrbez12VqrDGplBZElqmvGcrbE4g251SJAKL3Si YiDGkAzcBe0O2IKW9VpxR7oflWT5rTuD68TrCfRAnfZN2JjKFbwgpelMU21KzboxUOVyoBTybmOz /tV//lWC8dn4K5gVTsqIPBF7fGe5hupCE7QUBBegDxGpJYWjXOBJ1am6g8RjAKesjc1QwN15HrDA l0TzJYPwk3+pPvo3lfq5CKoObtsUw5Md3sWLD4snW1I/DPnxq01wWUXMyjuq1DjJofbdHiPDaY3/ p0IxnFkx5wLWqLX+HSnXJQWf+6l2aNY3MYIBGDATBgkqhkiG9w0BCRUxBgQEAQAAADBjBgkrBgEE AYI3EQExVh5UAE0AaQBjAHIAbwBzAG8AZgB0ACAAQgBhAHMAZQAgAEMAcgB5AHAAdABvAGcAcgBh AHAAaABpAGMAIABQAHIAbwB2AGkAZABlAHIAIAB2ADEALgAwMIGbBgkqhkiG9w0BCRQxgY0egYoA NwBkADgAMQAyADEANgA1ADEAZgAxADEAMQAzAGUAYQBiADkAMQA3ADAANQBkADEANwAyAGUAMAA3 AGQAMwBhAF8AZABjADUAOQBiAGIAYwA4AC0AYwA2ADAAMwAtADQANQBlADEALQBhAGQAOQBjAC0A MgA5ADcAMgA4AGYAMQBlADEAMAA4AGUwggSHBgkqhkiG9w0BBwagggR4MIIEdAIBADCCBG0GCSqG SIb3DQEHATAcBgoqhkiG9w0BDAEGMA4ECKFTj+Q5OYX8AgIH0ICCBEDD5zwjFYalixesCmxYReZl mpidWXKoadukDU//GoCF9AAVMtcimYRJKlRk6yNqPI+4Am+Rwy6EbGB9PO6kLHO8Y/1YDYCY474R /QogiXVmbdUetagQknHeBNiFEZYqfZDFIWfXQO/HeCk1PLkGYcoIY906g2N/fxjs93MFFrYiedKY wy8CRnby2FdwOMG+mxEG1B3mFL7zKSw+IeQyjJzxSOqdp4jtPoMpegM1u8iOnoUCT/nCZA3tyuI+ 1JhwaxahBj/PTVp5OjzyzhndDg+1HewLKIB6JJV/ycBqhRP2NGYj12kV4sWTCW1Z7NXHsyI51FNT gwNChw0Azu3OfCohhhz4gTIC1QSIaagbgMqu5Xpozgb+i1UEBxIDWph0LR5YPliKCeC2j0yf5mb5 OJnHWQsNCIZntr1CYI1kkwTfgOm1piRj3ZyQVLsVMF/76GldadNrZ6xjiPtnM9nMVOCTrZGbBFF7 3aJQ4kgmPmMB7wociYB/JpBrTaZ0gNRtD2KzWUbqdUlVlHe15EaVjId6FUVSdikpHPed+CF00rf6 d2aFWH+mN+19e0/9bxnFzuCOTGThSlBCki3lbnOVnp1VHrHcwAI5Oc4OlDn7HExIGLLUyQzO7D/R hxGBKH4EHKCs1sI82iiKR7XPROtcu2ioc1uWebfmL8sCMmyFlbIXY0vLdin8/XWMDiA/wx7vIwbb vVBs0iTStfI24Ssb2dn1h/Xv4XXAgDiE4d1dEx/fz37tOSdW2VHAOVgEIyyFDhjbkrciCGoh8/PP 5qkzp77oKJYPISTH2jjj67pdZ6YATuo2Kar9OSZH36T2ccfKlgZxzpl2owvRUryQ6AYT6yx+2k30 zXCQsFXeuRrnuzCzhnWBygT43juf6/2G9IcOVeHp5vPBykBL/E+wuvY8Na9HbndgLpl5pXhDf0vy oxRyBiJFm1NS02tyVPvzE1VJAQ58E46nBC4BfNrG8vP6mtL6m57VzY1iJfoPLpNGVwpBclZ1axTs C9OYyCySMUuCiY8LsHE04PYmTgNgi4gi9Z+sVeILiFh0musfB9+Lpo/eGt2P8+WVZvgw0GdgoTCX SCFtGPJBPrhIBq375isRBpolXhb8nHafIcL5O7n8yggwJGXfHjBfMPFAWmtC6LQUc7iL0Gxf2yUH +QqtFcroFTBmm+4G3Ii9AWV47yzdpqejShNcH6FKFkLI0EOIjLO2MZ0YqDQ2XQ8NQYWKwfCYA0pZ ZdwTkaE46IE0xyu2SmuMTwtgeHlD3wwNzys4m3NbnyfMKEjxv9lvzhzuPYHNvifhuk6qEEhWJnqw q4QuWxdO+V/at7a1iLZBj09EsvysacIiyAB9xaKFCmlIG4Mf49M52J7wP4ROhr6nca9UXiOdKmkE OPWMzOgfsgABAOp6jJZyOzJtKe6wZwfu/dFV+vMkNO6nXfms8nmfXGegYisHrTA7MB8wBwYFKw4D AhoEFG9sg+VEhOyupeBHv1gx8TIerQYDBBRt25pfDwj/4lRTGVDB9nOb2mDDNAICB9A= ------=_NextPart_000_003E_01C0D0D4.34EB3D90 Content-Type: application/x-x509-ca-cert; name="root.der" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="root.der" -----BEGIN CERTIFICATE----- MIIEajCCA1KgAwIBAgIIRLV+NTckSBAwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAkNOMRAwDgYDVQQIEwdiZWlqaW5nMRAwDgYDVQQHEwdiZWlqaW5nMR4wHAYD VQQKExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEZMBcGA1UEAxMQUm9vdCBDZXJ0aWZpY2F0ZTAeFw0wMTA0Mjkw ODAxMjRaFw0yMTA0MjQwODAxMjRaMIGMMQswCQYDVQQGEwJDTjEQMA4GA1UECBMH YmVpamluZzEQMA4GA1UEBxMHYmVpamluZzEeMBwGA1UEChMVQ2VydGlmaWNhdGUg QXV0aG9yaXR5MR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxGTAXBgNV BAMTEFJvb3QgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDvDMbqQIeEs0cZEtNBjR/s8XQGfJR9HGGmZF3c2+65p7u3zc/eaagOvFsv wVKi5cFV3c/wmwUigXnhDG0L2K/x1fN7O74iOOIonmOmH5gvkVRRzXsS36mbi7Ij 1HUdhx0IvbdW0EYi9Bu9jSoAOeqsg4wUIl14Cf/BaxqiFrtOpAfypmXo0QCjroBN fJxIn9NcuYqg+wwoOznV30vMX6DoaWxywUjFBt2M5MLIOLsvFkHl0maO8D7ZJqhc LFIyaAg7QGTjQLwYeXy8QBdrW2XUXY5DjLImzw2gSD+IYMRDu7907DXpxrRn5cok Z7gMjgb4JEJ8i6MMYAvSfsjLhzYFAgMBAAGjgc0wgcowNwYIKwYBBQUHAQEEKzAp MCcGCCsGAQUFBzABhhtodHRwOi8vd3d3LmNhMzY1LmNvbS9DQUluZm8wHQYDVR0O BBYEFHA0DWEvGacK5Pa0Kgau/PeoZY1xMA4GA1UdDwEB/wQEAwIBBjAfBgNVHREE GDAWhhRodHRwOi8vd3d3LmNhMzY1LmNvbTAPBgNVHRMBAf8EBTADAQH/MC4GA1Ud HwQnMCUwI6AhoB+GHWh0dHA6Ly93d3cuY2EzNjUuY29tL3Jvb3QuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQC3tqNV4XiLc8gb2RFxRW4x3t8CR3yAuNVdINSMydGKsqoV 2Pv6FL+JdC2KXOFvXY4+nW97c0sHcaJL5Zua7BzwgN2dXZWk6mIzPYLYBtXXRukm j7Xsp6kdjZCChqqlAd6dprbxONSvIhcNB37nT41JgR/qPzAK8yRpMRWzwbZ7qlLX 6qu0WySwQI9fyOYqy8BTVMEkLImLcAtUZyZUPrSg5/wtkYC95ST43ipP2PTdkPp8 Tm4dPsDFZSWPPGr0E8AvbkQ7UffaLTTP9yyj2FsmMR1/nch24Q89/s6W7w9wFYIj wfdeL9ZrlSWgllB611gtKHB1k9FgBWOmbI/eB9gx -----END CERTIFICATE----- ------=_NextPart_000_003E_01C0D0D4.34EB3D90-- From cryptlib@mbsks.franken.de Sun Apr 29 11:44:19 2001 From: cryptlib@mbsks.franken.de (xli) Date: Sun, 29 Apr 2001 18:44:19 +0800 Subject: [Cryptlib] client certificate was not comparible with IE5 and IIS5 Message-ID: <005b01c0d099$58b8e5a0$0dccfea9@free> This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C0D0DC.66B2F2C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGw6DQoNCkkgYW0gdmVyeSBzb3JyeSBmb3IgbXkgbGFzdCBjYXJlbGVzcyBlbWFpbC4g VGhlIHBhc3N3b3JkIG9mICJjbGllbnQucGZ4IiBpcyAiMjAwMCIuDQoNCnRoYW5rcyENCg0KbGl4 aW4NCg0K ------=_NextPart_000_0058_01C0D0DC.66B2F2C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40MTM0LjYwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48Rk9OVCBzaXpl PTI+PEZPTlQgc2l6ZT0zPkRlYXIgQWxsOjxCUj48QlI+SSZuYnNwO2FtIHZlcnkgc29ycnkgZm9y IG15IGxhc3QgDQpjYXJlbGVzcyBlbWFpbC4gVGhlIHBhc3N3b3JkIG9mICJjbGllbnQucGZ4IiBp cyAiMjAwMCIuPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIA0K c2l6ZT0zPjxCUj50aGFua3MhPEJSPjxCUj5saXhpbjwvRk9OVD48QlI+PC9ESVY+PC9GT05UPjwv Rk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0058_01C0D0DC.66B2F2C0-- From cryptlib@mbsks.franken.de Sun Apr 29 20:30:47 2001 From: cryptlib@mbsks.franken.de (Fidel Liberal Malaina) Date: Sun, 29 Apr 2001 21:30:47 +0200 (CEST) Subject: [Cryptlib] Silly question: generating RSA key pair Message-ID: Well, I think it's the simplest thing to do but I don't know if the manual is right and I'm completely stupid because it isn't like testlib.c examples. It's quite a simple question, I need to generate a public and the corresping private key. I need two encryption context or no? I think the way to do that is (based on loadRSAContext in testlib.c): CRYPT_CONTEXT pubContext, privContext; CRYPT_PKCINFO_RSA *rsakey; rsakey=(CRYPT_PKCINFO_RSA *)malloc(seizeof(CRYPT_PKCINFO_RSA)); create_both_context; cryptSetAttribute(pubContext,CRYPT_CTXINFO_LABEL,PUB_LABEL,strlen(PUB_LABEL); cryptSetAttribute(privContext, CRYPT_CTXINFO_LABEL, PRIV_LABEL,strlen(PRIV_LABEL); /*Generate pub key */ cryptGenerateKey(pubContext); /*Extract somehow public key info to generate associated private-key*/ crypGetAttributeString(pubContext,CRYPT_CTXINFO_KEY_COMPONENTS, rsakey,NULL); ====> I get -21 error code here so I can't use this info to generate anything I suppose it should be a trivial thing but.... Any help? Thanks in advance. Fidel Liberal Malaina ETSIT Bilbao (Spain)