From wk at gnupg.org Tue Feb 22 09:49:09 2000 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Feb 2000 09:49:09 +0100 Subject: Let's do a GNU TSL Message-ID: <20000222094909.I24590@frodo.gnupg.de> After some discussion, we decided to start a GNU TSL (rfc2246) implementation. From nmav at hellug.gr Thu Feb 24 19:08:23 2000 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Thu, 24 Feb 2000 20:08:23 +0200 Subject: Let's do a GNU TSL In-Reply-To: <20000224172855.D7673@frodo.gnupg.de>; from wk@gnupg.org on Thu, Feb 24, 2000 at 05:28:55PM +0100 References: <20000222094909.I24590@frodo.gnupg.de> <20000224181224.A18835@i-net.paiko.gr> <20000224172855.D7673@frodo.gnupg.de> Message-ID: <20000224200823.B846@i-net.paiko.gr> On Thu, Feb 24, 2000 at 05:28:55PM +0100, Werner Koch wrote: > > To implement this we need an hmac implementation (i've already done one > > for libmhash so it is no problem to make that again) > I also did one which is still in this gsti library used as libgcrypt > testbed but it will be moved to libgcrypt. ok. > > Also a pseudorandom function is needed in order to compute keys (the PRF in > > the standard). > Why a pseudorandom function - predictable keys are use in SSL? I > can't beleive. libgcrypt has a CSPRNG. No the pseudorandom function here (i think the name is not a good choice) just expands a secret(key). (just like the s2k algorithms in openpgp). > > Maybe we'll need also a compression algorithm (the standard does not specify any), > > and rc4( so arcfour), rc2, des, 3des, and idea implementations. > Are these all MUST algorithms? If they are SHOULD we don't need > to implement rc2 and idea becuase the are patent encumbered. no they are not must algorithms. The only must algorithm is 3des. However i do not think rc2 is patented since rfc2268 describes rc2 and does not mention anything about patents. RC4 is used in almost all ssl implementations so i think it is a good thing to have it. > Nikos, can we take this to the new mailinglist? I thought i've send that to the mailinglist, i've just forward it! > Werner -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From wk at gnupg.org Thu Feb 24 19:15:35 2000 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Feb 2000 19:15:35 +0100 Subject: Let's do a GNU TSL In-Reply-To: <20000224200823.B846@i-net.paiko.gr>; from nmav@hellug.gr on Thu, Feb 24, 2000 at 08:08:23PM +0200 References: <20000222094909.I24590@frodo.gnupg.de> <20000224181224.A18835@i-net.paiko.gr> <20000224172855.D7673@frodo.gnupg.de> <20000224200823.B846@i-net.paiko.gr> Message-ID: <20000224191535.A7856@frodo.gnupg.de> On Thu, 24 Feb 2000, Nikos Mavroyanopoulos wrote: > No the pseudorandom function here (i think the name is not a good choice) > just expands a secret(key). (just like the s2k algorithms in openpgp). I see. > However i do not think rc2 is patented since rfc2268 describes rc2 and does not > mention anything about patents. RC4 is used in almost all ssl implementations According to the HAC: "RC2 is a block cipher proprietary to RSA Data Security. (as is the stream cipher RC4)." I don,t see a reason to support such things. We better keep with standard block ciphers. RC4 is a different thing becuase it seems it is widely used and an independet but compatibel algoritm called arcfour exists. Even if it is not patented, it is possible to violate the copyright. Anyway, not a problem we can discuss this later and start with the MUST algorithms. Werner From tarunupadhyay at yahoo.com Fri Feb 25 06:11:49 2000 From: tarunupadhyay at yahoo.com (Tarun Upadhyay) Date: Thu, 24 Feb 2000 21:11:49 -0800 (PST) Subject: implementation details Message-ID: <20000225051149.1070.qmail@web1402.mail.yahoo.com> > 1. We have the RECORD protocol as nikos and werner pointed out, we have implementation of most things. I think we should concentrate on MUST things for now (3DES). RC2 and compression could wait to be added later. > 2. The difficult part seems to be the HANDSHAKE > protocol. This is not as difficult as it looks. most of things are available in libgrcrypt. PKCS and ASN.1 are, as werner pointed out, is available in openPGP (even otherwise they are not very difficult to implement). My company is doing a SET implementation for India which also uses PKCS and ASN.1 for formatting and padding. with warm regards tarun __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From nmav at hellug.gr Fri Feb 25 09:30:33 2000 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Fri, 25 Feb 2000 10:30:33 +0200 Subject: interface Message-ID: <20000225103033.A496@i-net.paiko.gr> What do you think on this api? I think it is high level enough. GNUTLS_STATE *state=malloc(SIZEOF_GNUTLS_STATE); [in case we support session resuming: GNUTLS_SESSIONS *sessions=malloc(20*SIZEOF_SESSION); /* keep a buffer of the last 20 sessions. A single session should * have a timestamp, so it will expire in a few hours * * in case of client: GNUTLS_SESSIONS *session=malloc(1*SIZEOF_SESSION); ] gnutls_init(state, GNUTLS_SERVER); /* or in case of a client: gnutls_init(state, GNUTLS_CLIENT); */ /* This file should have the certificate of the client/server */ gnutls_set_certificate(state, "/home/nmav/certificate"); /* or NULL in case of client */ /* This file should have the public keys of the trusted CAs */ gnutls_set_certificate_authorities(state, "/home/nmav/cas"); [connect to a tls host using a descriptor (cd), or receive a connection(server)] /* This changes the state which was initialized to null * eg. 3des is now used instead of plaintext * This actually handles all the dirty job (handshake and certification * verify) */ error=gnutls_handshake(cd, state, NULL); [or error=gnutls_handshake(cd, state, sessions); /* gnutls_handshake should add the current session into sessions, or * resume from a previous session if the client requests so (and the * session is not expired) */ /* in case of a client who wants to resume a previous session later: */ error=gnutls_handshake(cd, state, session); /* if the client wants to keep the current session identifier: */ gnutls_save_current_session(state, session); ] /* that way the client/server application needs to know nothing * about certification. I do not know if this is good or not. */ if (gnutls_is_fatal(error)!=0) return 2); if (error==GNUTLS_NULL_CERTIFICATE) return 3; /* a client may send a null certificate, but a server should send a valid one */ ret=gnutls_send(cd, state, data, sizeofdata); if (gnutls_is_fatal(ret)!=0) return 4; if (ret==GNUTLS_END_SESSION) End_session(); /* session was closed by peer */ ret=gnutls_receive(cd, state, input, sizeofinput); if (gnutls_is_fatal(ret)!=0) return 4; if (ret==GNUTLS_END_SESSION) End_session(); gnutls_finish(cd, state); free(state); <---------------------------------------------------> gnutl_send/receive() will process messages of all types (alert, change_cipher_spec, handshake, application_data). So gnutls_handshake will be able to use these functions internally. -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From wk at gnupg.org Fri Feb 25 16:08:25 2000 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Feb 2000 16:08:25 +0100 Subject: interface In-Reply-To: <20000225103033.A496@i-net.paiko.gr>; from nmav@hellug.gr on Fri, Feb 25, 2000 at 10:30:33AM +0200 References: <20000225103033.A496@i-net.paiko.gr> Message-ID: <20000225160825.H8974@frodo.gnupg.de> On Fri, 25 Feb 2000, Nikos Mavroyanopoulos wrote: > GNUTLS_STATE *state=malloc(SIZEOF_GNUTLS_STATE); There is not need, that SIZEOF_GNUTLS_STATE is know for users of gnutls. Better initialize the state with an init function: > gnutls_init(state, GNUTLS_SERVER); > /* or in case of a client: gnutls_init(state, GNUTLS_CLIENT); */ int gnutls_init( *ret_state, GNUTLS_SERVER ); > free(state); gnutls_deinit(state) > gnutl_send/receive() will process messages of all types (alert, > change_cipher_spec, handshake, application_data). So gnutls_handshake > will be able to use these functions internally. That looks easy. However, I don't know much about TLS. Werner From mau94319 at cse.iitd.ernet.in Sat Feb 26 09:09:59 2000 From: mau94319 at cse.iitd.ernet.in (Tarun Upadhyaya) Date: Sat, 26 Feb 2000 13:39:59 +0530 Subject: interface References: <20000225103033.A496@i-net.paiko.gr> Message-ID: <38B78A57.C2B24166@cse.iitd.ernet.in> >> GNUTLS_STATE *state=malloc(SIZEOF_GNUTLS_STATE); >There is not need, that SIZEOF_GNUTLS_STATE is know for users of >gnutls. Better initialize the state with an init function: actually no. size of GNUTLS_STATE will vary during the session anyways. however, an init function should be used anyway as GNUTLS_STATE could be initialized to different values based on client's environment params, preferences for this session etc. (or will this be handled by the gnutls_init later down with other initializations?) > GNUTLS_STATE *state=malloc(SIZEOF_GNUTLS_STATE); > > [in case we support session resuming: > GNUTLS_SESSIONS *sessions=malloc(20*SIZEOF_SESSION); > /* keep a buffer of the last 20 sessions. A single session should > * have a timestamp, so it will expire in a few hours > * > * in case of client: > GNUTLS_SESSIONS *session=malloc(1*SIZEOF_SESSION); > ] I am not very experienced but 20 sessions looks like an overkill to me in most cases. Can we replace that with a sorted list or something? Also, why should client keep only one session? I dont know but are there absolutely no circumstances when client would like to revert to a previously negotiated session? > /* This file should have the certificate of the client/server */ > gnutls_set_certificate(state, "/home/nmav/certificate"); > /* or NULL in case of client */ > > /* This file should have the public keys of the trusted CAs */ > gnutls_set_certificate_authorities(state, "/home/nmav/cas"); we can add checking of return status with both of the above. otherwise nice work nikos. looks okay to me. with warm regards tarun From nmav at hellug.gr Sat Feb 26 21:43:26 2000 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Sat, 26 Feb 2000 22:43:26 +0200 Subject: interface In-Reply-To: <38B78A57.C2B24166@cse.iitd.ernet.in>; from mau94319@cse.iitd.ernet.in on Sat, Feb 26, 2000 at 01:39:59PM +0530 References: <20000225103033.A496@i-net.paiko.gr> <38B78A57.C2B24166@cse.iitd.ernet.in> Message-ID: <20000226224326.A636@i-net.paiko.gr> On Sat, Feb 26, 2000 at 01:39:59PM +0530, Tarun Upadhyaya wrote: > however, an init function should be used anyway as GNUTLS_STATE could be > initialized to different values based on client's environment params, > preferences for this session etc. (or will this be handled by the > gnutls_init later down with other initializations?) Well, i agree that gnutls_init should handle all these. So lets remove that malloc. > > [in case we support session resuming: > > GNUTLS_SESSIONS *sessions=malloc(20*SIZEOF_SESSION); > > /* keep a buffer of the last 20 sessions. A single session should > > * have a timestamp, so it will expire in a few hours > > * > > * in case of client: > > GNUTLS_SESSIONS *session=malloc(1*SIZEOF_SESSION); > I am not very experienced but 20 sessions looks like an overkill to me > in most cases. Can we replace that with a sorted list or something? Well i do not think that it is really needed. The server may do after every session: i++; sessions=realloc(sessions, i*SIZEOF_SESSION); in order to fit all sessions he needs. We may also add the functions: int gnutls_how_many_expired_sessions(GNUTLS_SESSIONS * sessions); int gnutls_strip_expired_sessions(GNUTLS_SESSIONS* old_sessions, GNUTLS_SESSIONS* new_sessions); which will copy old_sessions to new sessions removing the expired sessions. so the user can: new_sessions=malloc( (current_session_num-gnutls_how_many_expired_sessions(sessions)) * SIZEOF_SESSION); gnutls_strip_expired_sessions(sessions, new_sessions); We can however make gnutls_clear_expired_sessions() to automatically allocate the space it needs, but i do not think that calling malloc() in a library function is a good idea. If you have any other idea one these functions, i'd like to hear... I do not like them:) > Also, why should client keep only one session? I dont know but are there > absolutely no circumstances when client would like to revert to a > previously negotiated session? This is one the client implementation side. It has nothing to do with the library. The client can hold as many sessions as it likes. > with warm regards > tarun -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From nmav at hellug.gr Mon Feb 28 19:18:35 2000 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Mon, 28 Feb 2000 20:18:35 +0200 Subject: interface In-Reply-To: <20000225103033.A496@i-net.paiko.gr>; from nmav@hellug.gr on Fri, Feb 25, 2000 at 10:30:33AM +0200 References: <20000225103033.A496@i-net.paiko.gr> Message-ID: <20000228201835.A1417@i-net.paiko.gr> On Fri, Feb 25, 2000 at 10:30:33AM +0200, Nikos Mavroyanopoulos wrote: > ret=gnutls_send(cd, state, data, sizeofdata); > ret=gnutls_receive(cd, state, input, sizeofinput); I'm going to implement these functions. I'll leave the gnutls_handshake as the last one. These will be a wrap over the internals: gnutls_send( content, cd, state, data, sizeofdata); gnutls_receive( content, cd, state, data, sizeofdata); with content application_data (content may also be change_cipher_spec, alert or handshake). I'll contact you again when i'm ready. An other point i'd like to ask you... Are we going to implement exportable ciphers? The standard suggests des40, but this seems to be too weak. -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From wk at gnupg.org Mon Feb 28 20:21:18 2000 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Feb 2000 20:21:18 +0100 Subject: interface In-Reply-To: <20000228201835.A1417@i-net.paiko.gr>; from nmav@hellug.gr on Mon, Feb 28, 2000 at 08:18:35PM +0200 References: <20000225103033.A496@i-net.paiko.gr> <20000228201835.A1417@i-net.paiko.gr> Message-ID: <20000228202118.D26817@frodo.gnupg.de> On Mon, 28 Feb 2000, Nikos Mavroyanopoulos wrote: > An other point i'd like to ask you... Are we going to implement exportable > ciphers? The standard suggests des40, but this seems to be too weak. All cipher algorithms are exportable from most countries of the world. The reason why there is no GNU crypto project in the U.S. is obvious. No, it does not make sense to implement crippeled algorithms. Werner From nmav at hellug.gr Tue Feb 29 13:15:47 2000 From: nmav at hellug.gr (Nikos Mavroyanopoulos) Date: Tue, 29 Feb 2000 14:15:47 +0200 Subject: libgcrypt Message-ID: <20000229141547.A12652@i-net.paiko.gr> Hello, Werner you'd told me about a program that uses libgcrypt so I can use it as reference. I've lost that email and i do not it's name and where is it located. It would be nice to add some examples in the documentation... -- Nikos Mavroyanopoulos mailto:nmav at hellug.gr From wk at gnupg.org Tue Feb 29 16:00:14 2000 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Feb 2000 16:00:14 +0100 Subject: libgcrypt In-Reply-To: <20000229141547.A12652@i-net.paiko.gr>; from nmav@hellug.gr on Tue, Feb 29, 2000 at 02:15:47PM +0200 References: <20000229141547.A12652@i-net.paiko.gr> Message-ID: <20000229160014.B1847@frodo.gnupg.de> On Tue, 29 Feb 2000, Nikos Mavroyanopoulos wrote: > Werner you'd told me about a program that uses libgcrypt so > I can use it as reference. I've lost that email and i do not it's name and > where is it located. It would be nice to add some examples in the It is called GSTI: ftp://ftp.gnupg.org/pub/devel/gsti-0.x.x.tar.gz grep for gcry_ in src/*.c Werner