RE: Blowfish Encrypt / Decrypt (also base64)
> From: owner-openssl-us...@openssl.org On Behalf Of emyr
> Sent: Monday, 18 October, 2010 07:33
> Anyway, I now have another issue.
> What I'm trying to do is to encrypt a password using blowfish, then
> base64 it for writing as a string into a config file [and reverse]
> http://www.ioncannon.net/programming/34/howto-base64-encode-wi
th-cc-and-openssl/
> http://www.ioncannon.net/programming/122/howto-base64-decode-w
ith-cc-and-openssl/
>
Those have a lot of unnecessary headers, and are oddly asymmetric:
encode chops the last char, which will always be a newline, but
the decode example has the newline plus a useless null.
Personally I consider it a waste of effort to go through the BIO
structure unless you're streaming, or un/base64ing a whole file
that is conveniently or even better accessed by BIO. When you do,
b64BIO output by default generates and b64BIO input by default
REQUIRES a newline at the end, and intermediate ones depending on
the length of the data. This is correct for the PEM (S/)MIME and
HTTP formats where base64 is most widespread, but often inconvenient
for things like a 'string in a config file', so you may want/need to
BIO_set_flags(b64bio,BIO_FLAGS_BASE64_NO_NL).
> which are handy but I don't think this will work as it
> doesn't tell you
> the exact length of the decoded binary buffer - i.e it just uses the
> length of the input string which will always be longer than
> the actual
> binary for b64. I will need this for the decrypting to work
> correctly.
> Is it possible to get the exact length of the base64 decoded binary
> using the SSL library?
>
Yes, that code fails to capture the decoded length. Using b64BIO
like that, the number of bytes decoded is the return from BIO_read.
(In general, the return from BIO_read is the data read; for b64BIO,
data read is bytes decoded from chars read from the underlying BIO;
for b64BIO/memBIO-in, it's bytes decoded from chars in the buffer.)
Personally for small in-memory without newlines like this, I just call
EVP_{Encode|Decode}Block. (Or in cases where openssl isn't convenient,
use my own code; it's only about 10 lines to encode and 20 to decode.)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
I have now created an actual patch to fix this.
It turns out to be a small pattern bug in x86_64xlate.pl
Patch attached as openssl-1.0.0a-x86_64attr.patch.
While debugging this patch I ran into an unrelated issue where nmake
would invoke nasm before the .asm file had been completely output.
This is probably a bug in the perl build used on one of the test
machines, but I think the patch to kludge around that race condition
might be useful too.
Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch.
Comment: This patch fixes incorrect attributes of the ".init" segment in
translated assemply for x86_64 when linked with Visual C code.
This fix is applicable even if it is also decided to not use an .init
seg anymore in x86_64cpuid.pl.
Author: WiseMo A/S, licensed under the Openssl license
diff -Naur openssl-1.0.0a.orig/crypto/perlasm/x86_64-xlate.pl
openssl-1.0.0a/crypto/perlasm/x86_64-xlate.pl
--- openssl-1.0.0a.orig/crypto/perlasm/x86_64-xlate.pl 2010-06-01
05:57:26.0 +
+++ openssl-1.0.0a/crypto/perlasm/x86_64-xlate.pl 2010-10-13
17:53:21.0 +
@@ -542,16 +542,16 @@
$line = ".CRT\$XCU" if ($line eq ".init");
if ($nasm) {
$v="section $line";
- if ($line=~/\.([px])data/) {
+ if ($line=~/\.(pdata|xdata|CRT\$)/) {
$v.=" rdata align=";
- $v.=$1 eq "p"? 4 : 8;
+ $v.=$1 eq "pdata"? 4 : 8;
}
} else {
$v="$current_segment\tENDS\n" if
($current_segment);
$v.="$line\tSEGMENT";
- if ($line=~/\.([px])data/) {
+ if ($line=~/\.(pdata|xdata|CRT\$)/) {
$v.=" READONLY";
- $v.=" ALIGN(".($1 eq "p" ? 4 :
8).")" if ($masm>=$masmref);
+ $v.=" ALIGN(".($1 eq "pdata" ? 4 :
8).")" if ($masm>=$masmref);
}
}
$current_segment = $line;
Comment: Some perl interpreters will not always wait for the child pipe
filter to exit before the parent perl interpreter exits (on platforms
where doing so does not kill the filter process). This in turn causes
a race condition between the x86_64-xlate.pl script and make invoking the
assembler on the output file.
This patch tries harder to avoid that race condition by increasing the
flush mode of perl just before closing the pipe AND adding a grace sleep
after closing the pipe.
Author: WiseMo A/S, licensed under the Openssl license
diff -Naur openssl-1.0.0a.orig/crypto/x86_64cpuid.pl
openssl-1.0.0a/crypto/x86_64cpuid.pl
--- openssl-1.0.0a.orig/crypto/x86_64cpuid.pl 2010-04-14 19:25:09.0
+
+++ openssl-1.0.0a/crypto/x86_64cpuid.pl2010-10-13 17:31:32.0
+
@@ -229,4 +229,6 @@
.size OPENSSL_wipe_cpu,.-OPENSSL_wipe_cpu
___
+$|=1; # flush more thoroughly
close STDOUT; # flush
+sleep(2); # Break race against background pipe completion
Re: Blowfish Encrypt / Decrypt (also base64)
Hi,
Ah yes... thanks for that Dave. Been doing C++ too much and a bit rusty
on the nuances of pointer stuff...
Anyway, I now have another issue.
What I'm trying to do is to encrypt a password using blowfish, then
base64 it for writing as a string into a config file (it has to be a
plain ascii string - no binary - hence using b64). I then want to read
in the string, UNbase64 it, then decrypt it to recover the correct password.
I found the following...
http://www.ioncannon.net/programming/34/howto-base64-encode-with-cc-and-openssl/
http://www.ioncannon.net/programming/122/howto-base64-decode-with-cc-and-openssl/
which are handy but I don't think this will work as it doesn't tell you
the exact length of the decoded binary buffer - i.e it just uses the
length of the input string which will always be longer than the actual
binary for b64. I will need this for the decrypting to work correctly.
Is it possible to get the exact length of the base64 decoded binary
using the SSL library?
Regards,
Emyr
On 15/10/10 21:16, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of emyr
Sent: Friday, 15 October, 2010 12:23
The program fails when I try to decrypt an encrypted buffer
and fails on the EVP_CipherFinal_ex() call.
int do_crypt(unsigned char *inbuf, int inlen,
unsigned char *outbuf, int *outlen, int do_encrypt) {
outbuf=(unsigned char*) malloc(inlen+EVP_MAX_BLOCK_LENGTH);
Asides: you need up to an extra block on CBC *encrypt*.
You don't need extra space on *decrypt*, but it does no harm.
And you don't need to cast the return of malloc if it has been
properly declared by #include'ing which it should be;
there are some systems where the C89-default declaration as int()
doesn't work, and on C99 'implicit int' is gone altogether.
if(!EVP_CipherFinal_ex(&ctx, outbuf+db,&tmplen)) {
Whenever you get an error from libcrypto routines (and
in most cases libssl routines also) you should display
the OpenSSL error queue. The simplest way is just call
ERR_print_errors_fp(stderr);
after having done SSL_load_error_strings() at startup.
Or there are more customizable options.
int main(int argc, char **argv) {
char *plain="the quick brown fox jumps over the lazy dog";
int plain_len=strlen(plain);
printf("plain_len=%d\n",plain_len);
unsigned char *cipher;
int cipher_len;
printf("* ENCRYPT *\n");
if (!do_crypt((unsigned char*) plain, strlen(plain), cipher,
&cipher_len, 1)) {
printf("failed to encrypt\n");
return 1;
}
printf("cipher_len=%d\n",cipher_len);
But this is your problem. You call do_crypt(1) with an
uninitialized output pointer 'cipher'. do_crypt allocates
the buffer and puts the data there, but 'cipher' in main()
has no idea about this buffer so ...
char *decrypt;
int decrypt_len;
printf("* DECRYPT *\n");
if(!do_crypt(cipher, cipher_len, decrypt,&decrypt_len, 0)) {
printf("failed to decrypt\n");
return 1;
}
... this call at best passes garbage to be decrypted,
and could easily even cause SEGV or similar faults.
And similarly even if 'cipher' had been good on that call
'decrypt' wouldn't be for the same reason.
And if decrypt really is char*, the compiler should have required
a cast to unsigned char* there (like for plain in the encrypt call).
printf("decrypt=\"%s\"\n",decrypt);
printf("decrypt_len=%d\n",decrypt_len);
return 0;
See www.c-faq.com number 4.8.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Question of openssl compilation
Thank you for your response. I have modified many places in Makefile and Makefile.shared and finally it can work. Best Regards, Arkie From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of So Gerald Sent: 2010年10月18日 17:27 To: openssl-users@openssl.org Subject: Re: Question of openssl compilation You might edit that Makefile for this yourself. 2010/10/8 HU Chengzhe Hello, I use follow command to compile openssl-0.9.8o 1) ./Configure solaris-sparcv9-cc --prefix=MY_OPENSSL_INSTALL_DIRECTORY shared 2) make 3) make install I can compile it successfully and under MY_OPENSSL_INSTALL_DIRECTORY/lib I can find some files like below: -rw-r--r-- 1 arkie bjumts 3623300 Aug 5 15:41 libcrypto.a lrwxrwxrwx 1 arkie bjumts18 Aug 5 15:41 libcrypto.so -> libcrypto.so.0.9.8 -r-xr-xr-x 1 arkie bjumts 2567624 Aug 5 15:41 libcrypto.so.0.9.8 -rw-r--r-- 1 arkie bjumts588036 Aug 5 15:41 libssl.a lrwxrwxrwx 1 arkie bjumts15 Aug 5 15:41 libssl.so -> libssl.so.0.9.8 -r-xr-xr-x 1 arkie bjumts424320 Aug 5 15:41 libssl.so.0.9.8 As we can see, there are two dynamic lib file libcrypto.so.0.9.8 and libcrypto.so.0.9.8. But my question is 1) How can I make the generated dynamic lib name as libcrypto.0.9.8.so and libcrypto.0.9.8.so, not the default name? 2) If dynamic lib name is changed successfully, How to make sure the link time name is same as the changed dynamic lib name? Is there some option similar with "-soname" which can specify the link time name? For example: =>ldd libssl.so.0.9.8 libcrypto.so.0.9.8 => . After change name to libssl.0.9.8.so, result should be: =>ldd libssl.0.9.8.so libcrypto.0.9.8.so =>. . Thank you. Best Regards, Arkie
Re: Question of openssl compilation
You might edit that Makefile for this yourself. 2010/10/8 HU Chengzhe > > Hello, > >I use follow command to compile openssl-0.9.8o >1) ./Configure solaris-sparcv9-cc > --prefix=MY_OPENSSL_INSTALL_DIRECTORY shared >2) make > 3) make install > > I can compile it successfully and under MY_OPENSSL_INSTALL_DIRECTORY/lib > I can find some files like below: > > -rw-r--r-- 1 arkie bjumts 3623300 Aug 5 15:41 libcrypto.a > lrwxrwxrwx 1 arkie bjumts18 Aug 5 15:41 libcrypto.so -> > libcrypto.so.0.9.8 > -r-xr-xr-x 1 arkie bjumts 2567624 Aug 5 15:41 libcrypto.so.0.9.8 > -rw-r--r-- 1 arkie bjumts588036 Aug 5 15:41 libssl.a > lrwxrwxrwx 1 arkie bjumts15 Aug 5 15:41 libssl.so -> > libssl.so.0.9.8 > -r-xr-xr-x 1 arkie bjumts424320 Aug 5 15:41 libssl.so.0.9.8 > > As we can see, there are two dynamic lib file libcrypto.so.0.9.8 > andlibcrypto.so.0.9.8 > . > > But my question is > 1) How can I make the generated dynamic lib name as libcrypto.0.9.8.so > and libcrypto.0.9.8.so, not the default name? > 2) If dynamic lib name is changed successfully, How to make sure the link > time name is same as the changed dynamic lib name? Is there some option > similar with "-soname" which can specify the link time name? > > For example: > =>ldd libssl.so.0.9.8 >libcrypto.so.0.9.8 => >. > After change name to libssl.0.9.8.so, result should be: > =>ldd libssl.0.9.8.so > libcrypto.0.9.8.so =>. > . > > Thank you. > > Best Regards, > Arkie >
