From tthomas at chubb.com Mon May 2 13:38:35 2005 From: tthomas at chubb.com (Tod Thomas) Date: Mon May 2 13:40:11 2005 Subject: libgcrypt - Initialization Vector In-Reply-To: <200504300925.34970.bradh@frogmouth.net> References: <42711F97.3040901@chubb.com> <200504290753.41716.bradh@frogmouth.net> <42723AE5.3080103@chubb.com> <200504300925.34970.bradh@frogmouth.net> Message-ID: <4276113B.5010505@chubb.com> Brad Hards wrote: > On Fri, 29 Apr 2005 23:47 pm, Tod Thomas wrote: > >>But what if I take my testing scenario from above and rather than >>running them both on the same machine piping the output of one to the >>other, instead run each program on a seperate machine? > > You must have the same IV on each machine. > > >>Using your description wouldn't I have to pass the IV's value along with >>the ciphertext to be able to decrypt it on the other end? Wouldn't I >>then have the burden of passing the IV in a secured fashion instead of >>just needing to pass the resulting ciphertext? Maybe I wouldn't want to >>use symmetric encryption for that kind of task? > > The IV doesn't need to remain secret. You can pass it any way you like. > > >>What I want to do is be able to encrypt a value using libgcrypt and then >>provide the decryption algorithm to an internal customer so they can >>decrypt it for their own purposes. > > OK. > > >>I see now that it is more of a random value used to 'mask' the key value >>on an encryption by encryption basis. But this unique quality prevents >>its value from being reproduced, requiring that it somehow be made >>available to the process that will ultimately perform the decryption. > > I think of it as an extra bit of plain text that goes at the front of the > plain text, that masks the plain text and makes it harder for an attacker to > pre-compute all the possible plaintext/ciphertext combinations. > > >>This would mean either the decryption routine would need to know how to >>replicate the salt (not likely due to its randomness) or have it passed >>as a value along with the ciphertext. > > You must pass it. > > >>Please bear with me, I'm just learning the inner workings of encryption >>so my conceptual knowledge is just beginning to grow. > > It would be well worth looking at how Electronic Code Book mode varies from > Cipher Block Chaining mode. ECB works on just a key, and has some serious > limitations / weaknesses if you don't use it exactly as intended. CBC (or > CFB, or OFB - look those up too!) is much more robust. > > Brad Will do. Thanks for the feedback. Tod From tthomas at chubb.com Mon May 2 15:36:12 2005 From: tthomas at chubb.com (Tod Thomas) Date: Mon May 2 15:37:33 2005 Subject: libgcrypt - Portable? Message-ID: <42762CCC.2080903@chubb.com> I wrote two separate programs using libgcrypt, one to perform encryption and one to perform decryption. Whan I pass a string to the encryption module and then pipe its output to the decryption module I get the correct value returned. This is on a Redhat 8 box. When I move the exact same code over and try the same test I get garbage output. This is on an old Sun Ultra-1 box running Solaris 8. I built the library from scratch on both machines. Outside of programmer error is there anything I should be taking into consideration that might point to my problem? Thanks - Tod From tthomas at chubb.com Thu May 12 14:29:31 2005 From: tthomas at chubb.com (Tod Thomas) Date: Thu May 12 14:28:24 2005 Subject: libgcrypt - Portable? In-Reply-To: <42762CCC.2080903@chubb.com> References: <42762CCC.2080903@chubb.com> Message-ID: <42834C2B.9030209@chubb.com> Tod Thomas wrote: > I wrote two separate programs using libgcrypt, one to perform encryption > and one to perform decryption. Whan I pass a string to the encryption > module and then pipe its output to the decryption module I get the > correct value returned. This is on a Redhat 8 box. > > When I move the exact same code over and try the same test I get garbage > output. This is on an old Sun Ultra-1 box running Solaris 8. > > I built the library from scratch on both machines. Outside of > programmer error is there anything I should be taking into consideration > that might point to my problem? It was programmer error, fread() call problem. Incidentally, I'd be willing to donate my test programs should anyone be interested. Tod From tthomas at chubb.com Fri May 20 21:24:48 2005 From: tthomas at chubb.com (Tod Thomas) Date: Fri May 20 21:20:56 2005 Subject: Little help please... Message-ID: <428E3980.3010505@chubb.com> I have two test programs, one encrypts, the other decrypts. When I pipe a string to the encryption program and pipe its output to the decryption program I get the original string back. This is on Redhat 8. I took the code from the encryption program and wrote a server plugin to perform password encryption to replace an out of the box hashing algorithm. The defined need is to be able to construct our own encryption that can be decrypted later on another server. This server encryption plugin works and was been developed on a Solaris 8 box. The problem is I can't get the Sun server encrypted password to decrypt on the RH box. I have debug statements that display the password both before and after encryption and decryption, in both hex and binary. The encrypted password generated on the server side doesn't match its counterpart on the RH side. Since I expected I would be able to just take the encrypted value on the server side and decrypt it using the test decryption program I wrote I suspected there was a problem in the server plugin. So I added a call to the decryption function there to display it to see if the password was getting corrupted somehow. It decrypted to the correct value. So now I'm stumped and have a couple of questions. Should this work? Is it reasonable to believe I can decrypt a string produced using the exact same setup (iv, key, mode, and algorithm) on one platform (Solaris), on a different platform (RH)? If not is there another solution? This is the gcrypt developer's list, I couldn't find a gcrypt-user's list. Is this the best place to ask these types of questions? Thanks in advance. Tod gcc 4.0.0 libgcrypt.so.11.2.0 libgpg-error.so.0.1.3 From wren at hunt.org Sun May 22 14:39:30 2005 From: wren at hunt.org (J. Wren Hunt) Date: Sun May 22 15:36:34 2005 Subject: Little help please... In-Reply-To: <428E3980.3010505@chubb.com> References: <428E3980.3010505@chubb.com> Message-ID: <42907D82.8000004@hunt.org> Tod Thomas wrote: > I have two test programs, one encrypts, the other decrypts. When I pipe > a string to the encryption program and pipe its output to the decryption > program I get the original string back. This is on Redhat 8. > > I took the code from the encryption program and wrote a server plugin to > perform password encryption to replace an out of the box hashing > algorithm. The defined need is to be able to construct our own > encryption that can be decrypted later on another server. This server > encryption plugin works and was been developed on a Solaris 8 box. > > The problem is I can't get the Sun server encrypted password to decrypt > on the RH box. > > I have debug statements that display the password both before and after > encryption and decryption, in both hex and binary. The encrypted > password generated on the server side doesn't match its counterpart on > the RH side. > > Since I expected I would be able to just take the encrypted value on the > server side and decrypt it using the test decryption program I wrote I > suspected there was a problem in the server plugin. So I added a call > to the decryption function there to display it to see if the password > was getting corrupted somehow. It decrypted to the correct value. So > now I'm stumped and have a couple of questions. > > Should this work? Is it reasonable to believe I can decrypt a string > produced using the exact same setup (iv, key, mode, and algorithm) on > one platform (Solaris), on a different platform (RH)? If not is there > another solution? > > This is the gcrypt developer's list, I couldn't find a gcrypt-user's > list. Is this the best place to ask these types of questions? > Hi Tod! Did you get this working yet? If not can you post a link to your code? I can help test on different-endian platforms if you like. -- Cheers! J. Wren Hunt Cambridge, MA. USA ------------ "I have never killed anyone, but I have read some obituaries with some satisfaction." - Clarence Darrow. +------------------------------------------------------------------+ | v-card http://wrenhunt.homelinux.org/data/wren.vcf | | x.509 http://wrenhunt.homelinux.org/data/thawte_wren_hunt.cer | | OpenPGP ADF5 1432 A59E 8F4D 4AE7 4DFE 03FA 91E1 4A24 D6F4 | +------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3188 bytes Desc: S/MIME Cryptographic Signature Url : /pipermail/attachments/20050522/578df9f7/smime.bin From tthomas at chubb.com Mon May 23 15:46:23 2005 From: tthomas at chubb.com (Tod Thomas) Date: Mon May 23 15:43:00 2005 Subject: **SPAM** Re: Little help please... In-Reply-To: <42907D82.8000004@hunt.org> References: <428E3980.3010505@chubb.com> <42907D82.8000004@hunt.org> Message-ID: <4291DEAF.2070001@chubb.com> J. Wren Hunt wrote: > Tod Thomas wrote: > >>I have two test programs, one encrypts, the other decrypts. When I pipe >>a string to the encryption program and pipe its output to the decryption >>program I get the original string back. This is on Redhat 8. >> >>I took the code from the encryption program and wrote a server plugin to >>perform password encryption to replace an out of the box hashing >>algorithm. The defined need is to be able to construct our own >>encryption that can be decrypted later on another server. This server >>encryption plugin works and was been developed on a Solaris 8 box. >> >>The problem is I can't get the Sun server encrypted password to decrypt >>on the RH box. >> >>I have debug statements that display the password both before and after >>encryption and decryption, in both hex and binary. The encrypted >>password generated on the server side doesn't match its counterpart on >>the RH side. >> >>Since I expected I would be able to just take the encrypted value on the >>server side and decrypt it using the test decryption program I wrote I >>suspected there was a problem in the server plugin. So I added a call >>to the decryption function there to display it to see if the password >>was getting corrupted somehow. It decrypted to the correct value. So >>now I'm stumped and have a couple of questions. >> >>Should this work? Is it reasonable to believe I can decrypt a string >>produced using the exact same setup (iv, key, mode, and algorithm) on >>one platform (Solaris), on a different platform (RH)? If not is there >>another solution? >> >>This is the gcrypt developer's list, I couldn't find a gcrypt-user's >>list. Is this the best place to ask these types of questions? >> > > > Hi Tod! > > Did you get this working yet? If not can you post a link to your code? I > can help test on different-endian platforms if you like. Not yet. I don't have a link I can post the code to at the moment. I can summarize it real quick: encode ------- fread() the plaintext err = gcry_cipher_open(&hd, GCRY_CIPHER_TWOFISH, GCRY_CIPHER_MODE_CFB, (unsigned int)NULL); err = gcry_cipher_setkey(hd, key, keylen); err = gcry_cipher_setiv(hd, NULL, 0); err = gcry_cipher_encrypt(hd,ciphertext,MAXSIZE,plaintext,strlen(plaintext)); fprintf(stderr,"Resulting ciphertext (hex): "); for(i=0;i (Tod Thomas's message of "Mon, 23 May 2005 09:46:23 -0400") References: <428E3980.3010505@chubb.com> <42907D82.8000004@hunt.org> <4291DEAF.2070001@chubb.com> Message-ID: <873bsexcd8.fsf@wheatstone.g10code.de> On Mon, 23 May 2005 09:46:23 -0400, Tod Thomas said: > err = gcry_cipher_setkey(hd, key, keylen); Use a fixed key for testing, like err = gcry_cipher_setkey(hd, "123456789abcdef0", 16 ); > gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen(ciphertext)); This won't work: You can't use strlen on CIPHERTEXT becuase that one is binary. Shalom-Salam, Werner From mkoegler at auto.tuwien.ac.at Sun May 29 15:41:01 2005 From: mkoegler at auto.tuwien.ac.at (Martin Koegler) Date: Tue May 31 16:49:52 2005 Subject: Compiling problem with MS VC 6 Message-ID: <20050529134101.GA30947@ahab.auto.tuwien.ac.at> I tried compiling libgcrypt 1.2.1 with MS Visual C++ 6 on Windows and discovered the following problems: * cipher/random.c includes unconditionally sys/time.h and unistd.h. Using #if HAVE_SYS_TIME_H #include #else #include #endif and AC_CHECK_HEADERS for sys/time.h should make the library more portable. (MS VC has no sys/time.h, using only time.h works). unistd.h should also be included only, if it is present (unistd.h needs to be added to AC_CHECK_HEADERS too): #ifdef HAVE_UNISTD_H #include #endif Some definitions, which are expected to be in unistd.h, can be found in the file io.h. (It can be included by config.h or by the c source file). * src/ath.c also includes unconditionally sys/time.h and unistd.h. It should be changed in the same way. * src/gcrypt.h includes unconditionally sys/time.h. Here a conditional include will not work. * if src/gcrypt.h is included in a program, pid_t, ssize_t and socklen_t must be defined by the program before. * Some functions have inconsitent prototypes, eg: mpi/mpi-cmp.c:gcry_mpi_cmp_ui( gcry_mpi_t u, unsigned long v ) src/gcrypt.h:int gcry_mpi_cmp_ui (const gcry_mpi_t u, unsigned long v); src/mpi.h:int gcry_mpi_cmp_ui( gcry_mpi_t u, ulong v ); mpi/mpi-cmp.c:gcry_mpi_cmp( gcry_mpi_t u, gcry_mpi_t v ) src/gcrypt.h:int gcry_mpi_cmp (const gcry_mpi_t u, const gcry_mpi_t v); rc/mpi.h:int gcry_mpi_cmp( gcry_mpi_t u, gcry_mpi_t v ); * in crypt/tiger.c the postfix LL is used instead of the macro U64_C: cipher/tiger.c: hd->a = 0x0123456789abcdefLL; cipher/tiger.c: hd->b = 0xfedcba9876543210LL; cipher/tiger.c: hd->c = 0xf096a5b4c3b2e187LL; cipher/tiger.c: x[0] -= x[7] ^ 0xa5a5a5a5a5a5a5a5LL; cipher/tiger.c: x[7] -= x[6] ^ 0x0123456789abcdefLL; All other problems are solveable in the config.h file: #define HAVE_DOSISH_SYSTEM #define HAVE_MEMMOVE #define HAVE_RAND #define VERSION "1.2.1" typedef unsigned __int64 uint64_t; #define UINT64_C(C) (C) #define SIZEOF_UINT64_T 8 #define _GCRYPT_IN_LIBGCRYPT #define S_IWUSR _S_IWRITE #define S_IRUSR _S_IREAD #define S_ISREG(A) (1) #define pid_t int #define ssize_t int #define socklen_t int #define USE_RNDW32 1 /* select of enabled features follow */ With these changes, it is possible to get a gcrypt, where all features I need for gnutls work. In the current CVS version, all these problems are still present. mfg Martin K?gler e9925248@stud4.tuwien.ac.at From wk at gnupg.org Tue May 31 21:28:07 2005 From: wk at gnupg.org (Werner Koch) Date: Tue May 31 21:25:57 2005 Subject: Compiling problem with MS VC 6 In-Reply-To: <20050529134101.GA30947@ahab.auto.tuwien.ac.at> (Martin Koegler's message of "Sun, 29 May 2005 15:41:01 +0200") References: <20050529134101.GA30947@ahab.auto.tuwien.ac.at> Message-ID: <87vf4z2o1k.fsf@wheatstone.g10code.de> On Sun, 29 May 2005 15:41:01 +0200, Martin Koegler said: > I tried compiling libgcrypt 1.2.1 with MS Visual C++ 6 on Windows and discovered the following Just a quick note: We don't support any Microsoft compiler and we won't clutter the code with unneeded ifdefs. unistd.h is POSIX and thus fine - if your compiler does not support it, change the compiler. mingw32 is the toolchain we use. > * in crypt/tiger.c the postfix LL is used instead of the macro U64_C: Thanks for noting. Shalom-Salam, Werner