From wk at gnupg.org Wed Feb 16 18:51:47 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Feb 2011 18:51:47 +0100 Subject: AES improvements on Intel CPUs Message-ID: <87pqqr7tqk.fsf@vigenere.g10code.de> Hi! The last days a played a bit with a loaned box from Intel (Core i5) and implemented asm code to use the AES-NI instructions. It is quite an improvement over the pure C code: First without AES-NI (AES-128, AES-192 and AES-256): $ ./benchmark --cipher-repetitions 100 --alignment 16 \ --disable-hwf intel-aesni cipher aes aes192 aes256 ECB/Stream CBC CFB OFB CTR -------------- --------------- --------------- --------------- --------------- 1360ms 1350ms 1170ms 1180ms 1120ms 1120ms 1550ms 1570ms 1730ms 1740ms 1560ms 1570ms 1370ms 1400ms 1320ms 1320ms 1750ms 1770ms 1930ms 1930ms 1770ms 1770ms 1560ms 1600ms 1520ms 1520ms 1950ms 1970ms 2140ms 2130ms Now with AES-NI (AES-128, AES-192 and AES-256): $ ./benchmark --cipher-repetitions 100 --alignment 16 \ cipher aes aes192 aes256 ECB/Stream CBC CFB OFB CTR --------------- --------------- --------------- --------------- --------------- 80ms 90ms 250ms 220ms 140ms 70ms 300ms 290ms 440ms 430ms 110ms 110ms 260ms 250ms 160ms 80ms 320ms 320ms 450ms 450ms 130ms 130ms 290ms 260ms 200ms 100ms 340ms 340ms 470ms 470ms Of course, most other crypto libs use these instructions also. CFB mode has been optimized because that is what OpenPGP requires. CBC and CTR will follow as time permits. 64 bit is not yet supported. There is a lot of room for more improvements of course. We are using inline asm and this may result in problems with some gcc versions. Please report such problems. There is a configure option to disable the use of AES-NI. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tom at ritter.vg Wed Feb 16 20:34:42 2011 From: tom at ritter.vg (Tom Ritter) Date: Wed, 16 Feb 2011 14:34:42 -0500 Subject: AES improvements on Intel CPUs Message-ID: Very cool. Is the benchmark code you're using public? It looks pretty powerful, and I'd love a suite to play with... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradh at frogmouth.net Wed Feb 16 21:37:52 2011 From: bradh at frogmouth.net (Brad Hards) Date: Thu, 17 Feb 2011 07:37:52 +1100 Subject: AES improvements on Intel CPUs In-Reply-To: References: Message-ID: <201102170737.53129.bradh@frogmouth.net> On Thursday, February 17, 2011 06:34:42 am Tom Ritter wrote: > Very cool. Is the benchmark code you're using public? It looks pretty > powerful, and I'd love a suite to play with... Its in the gcrypt source tree. Brad From smueller at chronox.de Thu Feb 17 11:15:46 2011 From: smueller at chronox.de (Stephan Mueller) Date: Thu, 17 Feb 2011 11:15:46 +0100 Subject: AES improvements on Intel CPUs In-Reply-To: <87pqqr7tqk.fsf@vigenere.g10code.de> References: <87pqqr7tqk.fsf@vigenere.g10code.de> Message-ID: <201102171115.47247.smueller@chronox.de> Am Mittwoch, 16. Februar 2011, um 18:51:47 schrieb Werner Koch: Hi Werner, > Hi! > > The last days a played a bit with a loaned box from Intel (Core i5) and > implemented asm code to use the AES-NI instructions. It is quite an > improvement over the pure C code: > Impressive numbers! What are your plans on using the AES-NI instruction when you merge your code? Do you want the caller to select the used code (i.e. have a cipher implementation of, say, AES-NI that the caller must explicitly use) or do you plan to allow libgcrypt to select the use of the AES-NI optimized version "on the fly" without allowing the caller to even detect that. I guess you know where I am coming from: it would be great when it is possible for the caller/administrator (at least in FIPS mode) to allow or disallow that AES-NI cipher use. Thanks Stephan -- | Cui bono? | From ypagani at aps.edu.pl Thu Feb 17 14:00:21 2011 From: ypagani at aps.edu.pl (Yves Pagani) Date: Thu, 17 Feb 2011 14:00:21 +0100 Subject: no error returns when a wrong key/iv is used for decrypting Message-ID: <20110217130021.GA3140@yves.aps.edu.pl> Hi all, I'm doing some tests with the symmetric crypting functions of gcrypt. I observed that when I give a wrong key or/and a wrong initialization vector for decrypting data via the gcry_cipher_decrypt function, it returns 0 instead of an error code. Of course, with a wrong key/iv, data are not correctly decrypted. The code given below shows this fact if uncommenting the second "gcry_randomize(key,key_size,GCRY_STRONG_RANDOM)" line. To be complete, I'm using : - the gcrypt 1.4.5 version of fedora 14 - gcc 4.5.1 (fedora 14 version too) - all is done in the secure memory Is it a bug or did I miss something ? Thanks in advance. Here is the example code : #include #include #include #include #define CIPHER_CHOICE GCRY_CIPHER_SERPENT256 #define CIPHER_MODE_CHOICE GCRY_CIPHER_MODE_CBC #define CIPHER_FLAGS_CHOICE GCRY_CIPHER_SECURE|GCRY_CIPHER_CBC_CTS #define SECURE_MEMORY_SIZE 60000 int main(void) { gcry_cipher_hd_t hd; /* handle a initialiser */ gcry_error_t error; /* valeur de retour des fonctions gcry */ char *key=NULL; char *iv=NULL; char a[1024]="Hello World!"; char tmp[1024]; int key_size; int iv_size; if ( !gcry_check_version ( GCRYPT_VERSION ) ) { exit ( EXIT_FAILURE ); } gcry_control ( GCRYCTL_SUSPEND_SECMEM_WARN ); gcry_control ( GCRYCTL_INIT_SECMEM, SECURE_MEMORY_SIZE ,0 ); gcry_control ( GCRYCTL_RESUME_SECMEM_WARN ); gcry_control ( GCRYCTL_INITIALIZATION_FINISHED,0 ); error=gcry_cipher_open(&hd,CIPHER_CHOICE,CIPHER_MODE_CHOICE,CIPHER_FLAGS_CHOICE); printf("Initialization of handler for encryption=%d,%s\n",error,gcry_strerror(error)); /* allocation and creation of a randomized key and randomized IV*/ key_size=gcry_cipher_get_algo_keylen(CIPHER_CHOICE); if ( NULL== ( key=gcry_calloc_secure ( key_size,1) ) ) { printf("Can not allocate memory for the key. Aborting\n."); exit ( EXIT_FAILURE ); } gcry_randomize(key,key_size,GCRY_STRONG_RANDOM); iv_size=gcry_cipher_get_algo_blklen(CIPHER_CHOICE); if ( NULL== ( iv=gcry_calloc_secure ( iv_size,1) ) ) { printf("Can not allocate memory for the IV. Aborting\n."); gcry_free(key); key=NULL; exit ( EXIT_FAILURE ); } gcry_randomize(iv,iv_size,GCRY_STRONG_RANDOM); error=gcry_cipher_setkey(hd,key,key_size); printf("Set the key=%d,%s\n",error,gcry_strerror(error)); error=gcry_cipher_setiv(hd,iv,iv_size); printf("Set the IV=%d,%s\n",error,gcry_strerror(error)); error=gcry_cipher_encrypt ( hd,tmp,sizeof ( tmp ),a,sizeof(a) ); printf("Encryption=%d,%s\n",error,gcry_strerror(error)); /* should be useless but just in case...*/ gcry_cipher_close ( hd ); error=gcry_cipher_open(&hd,CIPHER_CHOICE,CIPHER_MODE_CHOICE,CIPHER_FLAGS_CHOICE); printf("Initialization of handler for decryption=%d,%s\n",error,gcry_strerror(error)); /* if we uncomment this line, decryption will be wrong but no error is returns */ /* gcry_randomize(key,key_size,GCRY_STRONG_RANDOM); */ error=gcry_cipher_setkey(hd,key,key_size); printf("Set the key=%d,%s\n",error,gcry_strerror(error)); /* same as above */ /* gcry_randomize(iv,iv_size,GCRY_STRONG_RANDOM); */ error=gcry_cipher_setiv(hd,iv,iv_size); printf("Set the IV=%d,%s\n",error,gcry_strerror(error)); error=gcry_cipher_decrypt ( hd,tmp,sizeof ( tmp ),NULL,0 ); printf("Decryption=%d,%s\n",error,gcry_strerror(error)); gcry_cipher_close ( hd ); gcry_free(key); key=NULL; gcry_free(iv); iv=NULL; gcry_control(GCRYCTL_TERM_SECMEM); printf("a=%s\n",a); printf("tmp=%s\n",tmp); exit(EXIT_SUCCESS); } -- There are three rules for writing a novel. Unfortunately, no one knows what they are. -- Somerset Maugham -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From nmav at gnutls.org Thu Feb 17 15:03:15 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Feb 2011 15:03:15 +0100 Subject: no error returns when a wrong key/iv is used for decrypting In-Reply-To: <20110217130021.GA3140@yves.aps.edu.pl> References: <20110217130021.GA3140@yves.aps.edu.pl> Message-ID: On Thu, Feb 17, 2011 at 2:00 PM, Yves Pagani wrote: > Hi all, > I'm doing some tests with the symmetric crypting functions of gcrypt. > I observed that when I give a wrong key or/and a wrong initialization vector for decrypting data via the gcry_cipher_decrypt function, it returns 0 instead of an error code. > Of course, with a wrong key/iv, data are not correctly decrypted. It is not possible for libgcrypt to know whether data are wrongly decrypted (you have to define wrong). What you want is to add an authentication layer to that. I.e. add an HMAC to your encrypted data. regards, Nikos From wk at gnupg.org Thu Feb 17 18:24:27 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Feb 2011 18:24:27 +0100 Subject: AES improvements on Intel CPUs In-Reply-To: <201102171115.47247.smueller@chronox.de> (Stephan Mueller's message of "Thu, 17 Feb 2011 11:15:46 +0100") References: <87pqqr7tqk.fsf@vigenere.g10code.de> <201102171115.47247.smueller@chronox.de> Message-ID: <8762si7ewk.fsf@vigenere.g10code.de> On Thu, 17 Feb 2011 11:15, smueller at chronox.de said: > What are your plans on using the AES-NI instruction when you merge your code? Already merged, it will go into 1.5.0. > implementation of, say, AES-NI that the caller must explicitly use) or do you > plan to allow libgcrypt to select the use of the AES-NI optimized version "on > the fly" without allowing the caller to even detect that. Libgcrypt does hardware detection at initialization time. We use that for quite some time for the Padlock engine of VIA CPUs. With my last commit it does now really work on all Intel CPUs. There is even a way to disable the use of AES-NI: @item GCRYCTL_DISABLE_HWF; Arguments: const char *name Libgcrypt detects certain features of the CPU at startup time. For performace tests it is sometimes required not to use such a feature. This option may be used to disabale a certain feature; i.e. Libgcrypt behaves as if this feature has not been detected. Note that the detection code might be run if the feature has been disabled. This command must be used at initialization time; i.e. before calling @code{gcry_check_version}. > I guess you know where I am coming from: it would be great when it is possible > for the caller/administrator (at least in FIPS mode) to allow or disallow that > AES-NI cipher use. If you run in FIPS mode, no hardware features will be detected. Of course that can easily be changed. Details need to be discussed; e.g. whether it is allowed to run the detection code in fips mode or whether it is sufficient to mask out the features which are not to be validated. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 17 18:28:11 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Feb 2011 18:28:11 +0100 Subject: no error returns when a wrong key/iv is used for decrypting In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 17 Feb 2011 15:03:15 +0100") References: <20110217130021.GA3140@yves.aps.edu.pl> Message-ID: <871v367eqc.fsf@vigenere.g10code.de> On Thu, 17 Feb 2011 15:03, nmav at gnutls.org said: > decrypted (you have to define wrong). What you want is to add an > authentication layer to that. I.e. add an HMAC to your encrypted data. Or do a plaintext detection to see whether you got the right key. OpenPGP uses such a feature without introducing the HMAC overhead. The advantage of such a detection feature is that you can check the key right after decrypting a few blocks and not only after having decrypted a few gigs of ciphertext. Anyway, it is all a matter of the protocol and not of the crypto building blocks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nmav at gnutls.org Fri Feb 18 02:24:51 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 18 Feb 2011 02:24:51 +0100 Subject: no error returns when a wrong key/iv is used for decrypting In-Reply-To: <871v367eqc.fsf@vigenere.g10code.de> References: <20110217130021.GA3140@yves.aps.edu.pl> <871v367eqc.fsf@vigenere.g10code.de> Message-ID: <4D5DCA63.7060301@gnutls.org> On 02/17/2011 06:28 PM, Werner Koch wrote: > On Thu, 17 Feb 2011 15:03, nmav at gnutls.org said: > >> decrypted (you have to define wrong). What you want is to add an >> authentication layer to that. I.e. add an HMAC to your encrypted data. > > Or do a plaintext detection to see whether you got the right key. > OpenPGP uses such a feature without introducing the HMAC overhead. The > advantage of such a detection feature is that you can check the key > right after decrypting a few blocks and not only after having decrypted > a few gigs of ciphertext. Anyway, it is all a matter of the protocol > and not of the crypto building blocks. This is ok if a quick verification is required, but if malicious parties are expected, then this method is dangerous. That is because it depends on the encryption mode. For example in ECB mode, I can make the plaintext detection work, but rearrange message in any way I want. In CTR if the plaintext is known one could modify it at will, and even modify any hash appended to it without detection. If malicious parties are considered then an HMAC or authenticated encryption should be used. regards, Nikos From smueller at chronox.de Fri Feb 18 07:20:37 2011 From: smueller at chronox.de (Stephan Mueller) Date: Fri, 18 Feb 2011 07:20:37 +0100 Subject: AES improvements on Intel CPUs In-Reply-To: <8762si7ewk.fsf@vigenere.g10code.de> References: <87pqqr7tqk.fsf@vigenere.g10code.de> <201102171115.47247.smueller@chronox.de> <8762si7ewk.fsf@vigenere.g10code.de> Message-ID: <201102180720.37736.smueller@chronox.de> Am Donnerstag, 17. Februar 2011, um 18:24:27 schrieb Werner Koch: Hi Werner, > > There is even a way to disable the use of AES-NI: > > @item GCRYCTL_DISABLE_HWF; Arguments: const char *name Thank you very much for pointing that out. > > > I guess you know where I am coming from: it would be great when it is > > possible for the caller/administrator (at least in FIPS mode) to allow > > or disallow that AES-NI cipher use. > > If you run in FIPS mode, no hardware features will be detected. Of > course that can easily be changed. Details need to be discussed; > e.g. whether it is allowed to run the detection code in fips mode or > whether it is sufficient to mask out the features which are not to be > validated. That sounds great. As we all do not know what the next FIPS validation will cover, all that would be interesting is an easy way (even with a small code change) to define with cipher implementations will be available in FIPS mode and which not. And that seems the case for AES-NI. I would guess that is also the case for padlock. For example, is it possible to easily flip the FIPS switch for either padlock or AES-NI in cipher.c:cipher_table? Thanks Stephan -- | Cui bono? | From wk at gnupg.org Fri Feb 18 08:59:43 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Feb 2011 08:59:43 +0100 Subject: no error returns when a wrong key/iv is used for decrypting In-Reply-To: <4D5DCA63.7060301@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 18 Feb 2011 02:24:51 +0100") References: <20110217130021.GA3140@yves.aps.edu.pl> <871v367eqc.fsf@vigenere.g10code.de> <4D5DCA63.7060301@gnutls.org> Message-ID: <87ipwh6ads.fsf@vigenere.g10code.de> On Fri, 18 Feb 2011 02:24, nmav at gnutls.org said: > This is ok if a quick verification is required, but if malicious > parties are expected, then this method is dangerous. That is because It all depends on how you employ it. We all know that providing an oracle can be dangereous. In OpenPGP this is not the case given that it is properly implemented. See the OpenPGP WG archives from 1998 or so for lengthly discussions on this topic. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 18 09:04:00 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Feb 2011 09:04:00 +0100 Subject: AES improvements on Intel CPUs In-Reply-To: <201102180720.37736.smueller@chronox.de> (Stephan Mueller's message of "Fri, 18 Feb 2011 07:20:37 +0100") References: <87pqqr7tqk.fsf@vigenere.g10code.de> <201102171115.47247.smueller@chronox.de> <8762si7ewk.fsf@vigenere.g10code.de> <201102180720.37736.smueller@chronox.de> Message-ID: <87ei756a6n.fsf@vigenere.g10code.de> On Fri, 18 Feb 2011 07:20, smueller at chronox.de said: > For example, is it possible to easily flip the FIPS switch for either padlock > or AES-NI in cipher.c:cipher_table? No, you would change void _gcry_detect_hw_features (unsigned int disabled_features) { hw_features = 0; if (fips_mode ()) return; /* Hardware support is not to be evaluated. */ #if defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4 #ifdef __GNUC__ detect_ia32_gnuc (); #endif #elif defined (__i386__) && SIZEOF_UNSIGNED_LONG == 8 #ifdef __GNUC__ #endif #endif hw_features &= ~disabled_features; } to something like void _gcry_detect_hw_features (unsigned int disabled_features) { hw_features = 0; #if defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4 #ifdef __GNUC__ detect_ia32_gnuc (); #endif #elif defined (__i386__) && SIZEOF_UNSIGNED_LONG == 8 #ifdef __GNUC__ #endif #endif if (fips_mode ()) hw_features &= MASK_OF_FIPS_ALLOWED_FEATURES; hw_features &= ~disabled_features; } and those features are disabled. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ypagani at aps.edu.pl Fri Feb 18 09:55:36 2011 From: ypagani at aps.edu.pl (Yves Pagani) Date: Fri, 18 Feb 2011 09:55:36 +0100 Subject: no error returns when a wrong key/iv is used for decrypting In-Reply-To: <871v367eqc.fsf@vigenere.g10code.de> References: <20110217130021.GA3140@yves.aps.edu.pl> <871v367eqc.fsf@vigenere.g10code.de> Message-ID: <20110218085536.GB3140@yves.aps.edu.pl> On Thu, Feb 17, 2011 at 06:28:11PM +0100, Werner Koch wrote: > On Thu, 17 Feb 2011 15:03, nmav at gnutls.org said: > > > decrypted (you have to define wrong). What you want is to add an > > authentication layer to that. I.e. add an HMAC to your encrypted data. > > Or do a plaintext detection to see whether you got the right key. > OpenPGP uses such a feature without introducing the HMAC overhead. The > advantage of such a detection feature is that you can check the key > right after decrypting a few blocks and not only after having decrypted > a few gigs of ciphertext. Anyway, it is all a matter of the protocol > and not of the crypto building blocks. Hi Nikos, Hi Werner, Thanks for your quick answers. I, indeed, though that checking the error code of the cipher_decrypt will allow me to warn the user (me in my case :) ) if a wrong key is given (like gpg does when a wrong passphrase is entered). Now, with your explanations I have a clearer understanding how to do it properly/working. By the way, many thanks to all the developpers who done this great library and other related tools (gnutls, gnupg and so on). Have a nice day. Best regards, Yves Pagani -- Darth Vader sleeps with a Teddywookie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From n3npq at mac.com Fri Feb 18 14:54:26 2011 From: n3npq at mac.com (Jeff Johnson) Date: Fri, 18 Feb 2011 08:54:26 -0500 Subject: AES improvements on Intel CPUs In-Reply-To: <87ei756a6n.fsf@vigenere.g10code.de> References: <87pqqr7tqk.fsf@vigenere.g10code.de> <201102171115.47247.smueller@chronox.de> <8762si7ewk.fsf@vigenere.g10code.de> <201102180720.37736.smueller@chronox.de> <87ei756a6n.fsf@vigenere.g10code.de> Message-ID: <2BA2DC14-9575-436A-BF82-2D7CC17753DE@mac.com> On Feb 18, 2011, at 3:04 AM, Werner Koch wrote: > On Fri, 18 Feb 2011 07:20, smueller at chronox.de said: > >> For example, is it possible to easily flip the FIPS switch for either padlock >> or AES-NI in cipher.c:cipher_table? > > No, you would change > ... > and those features are disabled. > Have you looked at the ELF functionality hinted at "Automatic use of optimized function" here: http://udrepper.livejournal.com/ 73 de Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4645 bytes Desc: not available URL: From wk at gnupg.org Fri Feb 18 19:23:18 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Feb 2011 19:23:18 +0100 Subject: AES improvements on Intel CPUs In-Reply-To: <2BA2DC14-9575-436A-BF82-2D7CC17753DE@mac.com> (Jeff Johnson's message of "Fri, 18 Feb 2011 08:54:26 -0500") References: <87pqqr7tqk.fsf@vigenere.g10code.de> <201102171115.47247.smueller@chronox.de> <8762si7ewk.fsf@vigenere.g10code.de> <201102180720.37736.smueller@chronox.de> <87ei756a6n.fsf@vigenere.g10code.de> <2BA2DC14-9575-436A-BF82-2D7CC17753DE@mac.com> Message-ID: <8762sh5hih.fsf@vigenere.g10code.de> On Fri, 18 Feb 2011 14:54, n3npq at mac.com said: > Have you looked at the ELF functionality hinted at The problem with such an approach is that it is not portable. There is more than just ELF in our world. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Feb 21 17:27:31 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Feb 2011 17:27:31 +0100 Subject: Libgcrypt 1.5.0-beta1 released Message-ID: <87oc652w0c.fsf@vigenere.g10code.de> Hi, to help with testing the new ECC code in GnuPG, I just uploaded a beta version of libgcrypt 1.5: ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.5.0-beta1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.5.0-beta1.tar.bz2.sig Changes are: * Support for WindowsCE. * Support ECDH. * gcry_sexp_build does now support opaque MPIs with "%m". * New functions gcry_pk_get_curve and gcry_pk_get_param to map ECC parameters to a curve name and to retrieve parameter values. * gcry_mpi_cmp applied to opaque values has a defined semantic now. * Uses the Intel AES-NI instructions if available. * The use of the deprecated Alternative Public Key Interface (gcry_ac_*) will now print compile time warnings. * The module register subsystem has been deprecated. This subsystem is not flexible enough and would always require ABI changes to extend the internal interfaces. It will eventually be removed. Please contact us on the gcrypt-devel mailing list to discuss whether you really need this feature or how it can be replaced by an internal plugin mechanism. * New variants of the TIGER algorithm. [also in 1.4.6] * New cipher algorithm mode for AES-WRAP. [also in 1.4.6] * Fixed minor memory leak in DSA key generation. [also in 1.4.5] * No more switching to FIPS mode if /proc/version is not readable. [also in 1.4.5] * Fixed sigill during Padlock detection on old CPUs. [also in 1.4.5] * Fixed a hang on some W2000 machines. [also in 1.4.5] * Boosted SHA-512 performance by 30% on ia32 boxes and gcc 4.3; SHA-256 went up by 25%. [also in 1.4.5] * Interface changes relative to the 1.4.2 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_PK_ECDH NEW. gcry_pk_get_curve NEW. gcry_pk_get_param NEW. GCRYCTL_DISABLE_HWF NEW. GCRY_CIPHER_MODE_AESWRAP NEW. [also in 1.4.6] GCRY_MD_TIGER1 NEW. [also in 1.4.6] GCRY_MD_TIGER2 NEW. [also in 1.4.6] Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.