On Mon, Dec 09, 2002 at 05:45:47PM +0100, Richard Levitte - VMS Whacker wrote:
> In message <20021209122438.GB16737@folly> on Mon, 9 Dec 2002 13:24:38 +0100, Markus
>Friedl <[EMAIL PROTECTED]> said:
>
> markus> On Sun, Dec 08, 2002 at 12:39:04PM +0100, Martin MOKREJ? wrote:
> markus> > cc: Error:
In message <20021209122438.GB16737@folly> on Mon, 9 Dec 2002 13:24:38 +0100, Markus
Friedl <[EMAIL PROTECTED]> said:
markus> On Sun, Dec 08, 2002 at 12:39:04PM +0100, Martin MOKREJ? wrote:
markus> > cc: Error: /usr/local/openssl/include/openssl/mdc2.h, line 79: Missing type
specifier or type qua
On Sun, Dec 08, 2002 at 12:39:04PM +0100, Martin MOKREJ? wrote:
> cc: Error: /usr/local/openssl/include/openssl/mdc2.h, line 79: Missing type
>specifier or type qualifier. (missingtype)
> DES_cblock h,hh;
> ^
i don't think openssl's evp.h should include mdc2.h
Hi,
I've seen that openssh will have different function names for des, I
think thats great. As kerberos4 nor kerbero5 from KTH in Sweden support
those new calls yet, I thought it would be best for me to switch back to
the old behaviour, i.e. have kerberized libkrb and other libs with
dis
I set the plaintext and ciphertext strings to 32 characters as below and
test_evp is now OK, encrypt/decrypt.
Chris Brook
// DES CBC tests (from destest)
"DES-CBC:0123456789abcdef:fedcba9876543210:37363534333231204E6F7720697320746
8652074696D6520666F7220003
Chris Brook wrote:
Forget my previous email. destest is actually only passing 29 bytes I see,
so the predicted ciphertext will of course be wrong if I pass 32 bytes for
encryption.
So what was the correct test entry in the end?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://
Forget my previous email. destest is actually only passing 29 bytes I see,
so the predicted ciphertext will of course be wrong if I pass 32 bytes for
encryption.
Chris Brook
__
OpenSSL Project http
I added the DES CBC test vectors in destest.c to test/evptests.txt thus:
# DES CBC tests (from destest)
DES-CBC:0123456789abcdef:fedcba9876543210:37363534333231204E6F77206973207468
652074696D6520666F72200031:ccd173ffab2039f4acd8aefddfd8a1eb468e91157888b
a681d269397f7fe62b4
which corresponds
[EMAIL PROTECTED] wrote:
> levitte 06-Oct-2002 02:23:34
>
> Modified: crypto/des Tag: OpenSSL_0_9_7-stable des_old.h
> Log:
> Do not define crypt(). The supported function is DES_crypt() (an des_crypt()
> when backward compatibility is desired).
Hooray!
Cheer
Hello there!
I'm just a stranger here, so, please, bear with my, probably, wrong
remark. I was going to look at how the DES weak keys are handled during
the key generation in SSLeay and was surpised when I saw it.
The weak_keys (file set_key.c) array contains odd-parity adjusted keys. O
Hi,
For DES or RC4 or other algorithm Encrypt / decrypt you can look at openssl test file
using evp.
This file is in openssl-xxx/test
Hope it will help.
Fred
-Message d'origine-
De : J [mailto:[EMAIL PROTECTED]]
Envoyé : jeudi 1 août 2002 23:25
À : [EMAIL PROTECTED]
Cc : [
Hello Everyone,
Has anyone had any experience using DES Decryption routines to decrypt a 16 byte
ciphertext into the original using an IV??
I am receiving the IV and the Encrypted Data from a server that is using the MS Crypto
API for des encryption and decryption. The mode is CBC (Cipher
hi Michael,
On Fri, Jul 19, 2002 at 12:17:23PM +0200, Michael Schmidt wrote:
> Hi Vadim,
>
> Vadim Fedukovich schrieb:
>
> >> For a research project I'm working on, I want to use OpenSSL with
> >> ADH-DES-CBC3-SHA (TLSv1). This means I want to use neith
Hi Vadim,
Vadim Fedukovich schrieb:
>> For a research project I'm working on, I want to use OpenSSL with
>> ADH-DES-CBC3-SHA (TLSv1). This means I want to use neither a
>> server-side nor a client-side certificate; and the pre-master
>> secret shall be estab
On Fri, Jul 19, 2002 at 09:37:22AM +0200, Michael Schmidt wrote:
> Hi,
>
> For a research project I'm working on, I want to use OpenSSL with
> ADH-DES-CBC3-SHA (TLSv1). This means I want to use neither a server-side
> nor a client-side certificate; and the pre-ma
Hi,
For a research project I'm working on, I want to use OpenSSL with
ADH-DES-CBC3-SHA (TLSv1). This means I want to use neither a server-side
nor a client-side certificate; and the pre-master secret shall be
established via Diffie-Hellman key exchange.
I understand that the cu
On Thu, Apr 04, 2002 at 04:07:47AM -0700, James Yonan wrote:
>
> I was thinking more about maintaining proper key parity. Does a client of
> EVP need to worry about making sure that if DES is the underlying cipher,
> that passed keys have the proper parity?
Generally, people jus
> Out of 2^56 DES keys, there are four weak keys and 12 semi-weak keys.
> The odds of getting a weak key are incredibly slight. Most people
> don't bother to check, and it isn't considered a security risk.
True, weak or semi-weak keys are improbable.
I was thinking mor
On Wed, Apr 03, 2002 at 11:12:40PM -0700, James Yonan wrote:
>
> (b) Some kind of *optional* EVP method (so it doesn't break interoperability
> with non-OpenSSL clients) that, given an EVP_CIPHER and key, will
> deterministically mutate the key into a correct form.
Out of 2^5
I think it fundamentally breaks the encapsulation of the EVP layer for there
to be cipher-specific magic that clients have to explicitly know about such
as DES parity.
I propose:
(a) That EVP_CipherInit() return an error status on bad key (nobody seems to
disagree with this one).
(b) Some kind
To: [EMAIL PROTECTED]
Subject: Re: EVP_CipherInit() doesn't check for weak DES keys (0.9.6)
> James Yonan wrote:
> >
> > Given that the EVP level is supposed to offer callers a
cipher-independent
> > interface, where the caller doesn't necessarily know the idiosyncra
> > des_set_key_checked() instead of des_set_key_unchecked() and return an
error
> > status in the case of a weak key?
>
> Makes sense to me!
Maybe EVP_CipherInit should silently mutate a bad key (such as DES weak,
semi-weak, or bad parity) using some kind of deterministic tra
James Yonan wrote:
>
> Given that the EVP level is supposed to offer callers a cipher-independent
> interface, where the caller doesn't necessarily know the idiosyncracies of
> the underlying cipher, wouldn't it make sense for evp/e_des3.c to call
> des_set_key_checked() instead of des_set_key_un
Given that the EVP level is supposed to offer callers a cipher-independent
interface, where the caller doesn't necessarily know the idiosyncracies of
the underlying cipher, wouldn't it make sense for evp/e_des3.c to call
des_set_key_checked() instead of des_set_key_unchecked() and return an error
On Thu, Mar 21, 2002 at 02:45:18PM -0500, Jeffrey Altman wrote:
>>> I prefer that des_old.h be compatible with libdes since that apps that
>>> are built using it assume that the api they were using was constant
>>> and unchanging.
>> The way things work now, there is at least no clash with lib
Rodney Thayer wrote:
>
> At 09:29 PM 3/21/2002 +, S.Henson wrote:
> >Is there some particular reason why such applications couldn't use the
> >EVP layer? An attempt has been made to keep this consistent and to make
> >any enhancements backwards compatible. In fact some of the more recent
> >c
At 09:29 PM 3/21/2002 +, S.Henson wrote:
>Is there some particular reason why such applications couldn't use the
>EVP layer? An attempt has been made to keep this consistent and to make
>any enhancements backwards compatible. In fact some of the more recent
>changes would have been substantial
Jeffrey Altman wrote:
>
> > Jeffrey Altman wrote:
> > >
> > > > From: Jeffrey Altman <[EMAIL PROTECTED]>
> > > >
> > > > jaltman> I prefer that des_old.h be compatible with libdes since that apps that
> > > > jaltman> are built using it assume that the api they were using was constant
> > > > jal
> DES_INT is a configuration option. If given, DES_LONG will be defined
> as 'unsigned int', otherwise it will be 'unsigned long'. This has no
> impact whatsoever on 32bit machines. However, on pure 64bit machines,
> there is a size difference.
Then I agree. It should be define as the default
> The blatant exception that I know of would be DOS, where int is
jaltman> > usually a 16-bit quantity, and where DES_LONG should be 'unsigned
jaltman> > long' rather than 'unsigned int'.
jaltman>
jaltman> > As far as I know, DES_LONG is supposed to be a
> Jeffrey Altman wrote:
> >
> > > From: Jeffrey Altman <[EMAIL PROTECTED]>
> > >
> > > jaltman> I prefer that des_old.h be compatible with libdes since that apps that
> > > jaltman> are built using it assume that the api they were using was constant
> > > jaltman> and unchanging.
> > >
> > > The
Jeffrey Altman wrote:
>
> > From: Jeffrey Altman <[EMAIL PROTECTED]>
> >
> > jaltman> I prefer that des_old.h be compatible with libdes since that apps that
> > jaltman> are built using it assume that the api they were using was constant
> > jaltman> and unchanging.
> >
> > The way things work no
From: Rodney Thayer <[EMAIL PROTECTED]>
rodney> I believe this was discussed recently on this list but
rodney> I can't put my hands on the message thread. Appologies if this
rodney> is redundant.
rodney>
rodney> It turns out Mixmaster uses the DES routines in OpenSSL.
_LONG is supposed to be a 32-bit quantity.
> Have I gotten this wrong? If not, I'll make appropriate changes to
> Configure, and some problems on some 64-bit architectures may go
> away.
I'm not sure I understand the question you are looking for an answer
to. Currently there is no r
From: Jeffrey Altman <[EMAIL PROTECTED]>
jaltman> I prefer that des_old.h be compatible with libdes since that apps that
jaltman> are built using it assume that the api they were using was constant
jaltman> and unchanging.
The way things work now, there is at least no clash with libdes on the
I believe this was discussed recently on this list but
I can't put my hands on the message thread. Appologies if this
is redundant.
It turns out Mixmaster uses the DES routines in OpenSSL.
I tried compiling the current Mixmaster (mixmaster-2.9b33)
with a recent OpenSSL snapshot (openssl
> So, if I would set des_old.h to have 0.9.6c compatibility, I would
> remove the requirement to defined the macro
> OPENSSL_DES_PRE_0_9_7_COMPATIBILITY, and instead require that one
> defines OPENSSL_LIBDES_COMPATIBILITY if that's what one wants.
>
> Unfortunately, I have a hard time deciding, s
The current hack of the DES functions (the old API, i.e. the des_
variants, not the DES_ ones) is still an issue.
The reason I made the hackery that I did was because of the increased
number of reports where our slightly change API was causing clashes
with various header files out there that
From: Bodo Moeller <[EMAIL PROTECTED]>
moeller> This looks like an incompatible change (not just a bugfix), so it
moeller> definitely should be documented in CHANGES. (Or, if compatibility is
moeller> important here, the change should not be done at all.)
I'm a little unsure about how it is "in
From: Bodo Moeller <[EMAIL PROTECTED]>
moeller> If you previously used this function with a string that was mapped to
moeller> a weak key, it will now be mapped to a different key, so decryption
moeller> won't work as expected. (Arguably you don't need decryption if it was
moeller> a weak key, b
On Wed, Feb 06, 2002 at 04:40:10PM +0100, Richard Levitte - VMS Whacker wrote:
>> This looks like an incompatible change (not just a bugfix), so it
>> definitely should be documented in CHANGES. (Or, if compatibility is
>> important here, the change should not be done at all.)
> I'm a little un
On Tue, Feb 05, 2002 at 04:05:48PM +0100, [EMAIL PROTECTED] wrote:
> Apply one patch from Assar Westerlund <[EMAIL PROTECTED]>:
>
> The following patch makes sure that string2key does not use weak DES
> keys (then making them non-weak by xor:ing with 0xF0).
Richard Levitte - VMS Whacker wrote:
>
> From: Ben Laurie <[EMAIL PROTECTED]>
>
> ben> Bodo Moeller wrote:
> ben> >
> ben> > On Mon, Nov 05, 2001 at 12:32:56PM +0100, Richard Levitte - VMS Whacker wrote:
> ben> >
> ben> > >> If they are static in Kerberos, how can there be a name clash?
> ben> >
On Tue, Nov 06, 2001 at 11:58:30AM +0100, Richard Levitte - VMS Whacker wrote:
>> In OpenSSL, there are no similarly named functions for ciphers other
>> than DES; so we can simply rename DES_random_key() to DES_rnd_key() or
>> DES_rand_key() or DES_create_random_key() withou
×𾴵Ŀͻ§ÄúºÃ£º
Öйú×î´óµÄ×ʽðÏîÄ¿½»Ò×ÖÐÐÄhttp://www.cnvce.comΪÄúµÄ´´ÒµºÍ·¢Õ¹ÅÅÓǽâÄÑ£¬ÄúµÄÏîÄ¿ÔÚÕâÀï»áºÜ¿ìÕÒµ½×ʽð£¬ÄúÓÐ×ʽðÏëÕÒÏîÄ¿¸üÈÝÒ×£¬´´Òµ·¢Õ¹µÄ»ùµØ¡£ÕâÀïÿÌ춼»áÓдóÁ¿ÐµÄ×ʽðºÍÏîÄ¿¹©ÄúÑ¡Ôñ£¬µÈ´ý×ÅÄú£¡
Ïȵã»÷£¬ºóµãÇ®£¡Äú»¹µÈʲôÄØ£¿http://www.cnvce.com
Öйú×ʽðÏîÄ¿½»Ò×ÖÐÐÄ
http://www.cnv
Going back to Ben's original message and the start of this thread, it's not
entirely clear what the actual problem was. But it is a fact that static
symbols cannot cause linker clashes. Given this fact, and Ben's mention of
functions that are declared in certain broken header files, one can only
g
> From: Jeffrey Altman <[EMAIL PROTECTED]>
>
> jaltman> > ben> The ones I was referring to actually are static.
> jaltman> >
> jaltman> > Then they should not be a problem, and definitely not a source of
> jaltman> > clashing, should they?
> jaltman> >
> jaltman>
> jaltman> They are a problem
uot;we don't like the
> function names we'd use" :)
Well, that's a good point, of course. So, I guess we have to think again
about the function names, particularly since it introduces a very nasty
clash between Kerberos IV and Kerberos V, I have now discovered.
OTOH, the chan
> The problem with that idea is it is incompatible with all the other
> functions in OpenSSL. The functions that clash in Kerberos are all
> (there aren't many) static, so there aren't actually many ramifications
> to changing them in Kerberos.
Are you saying that if I want to install openssl on
Jeffrey Altman wrote:
>
> > ...I've just discovered that changing DES functions to be DES_* clashes
> > with Kerberos... for example:
> >
> > static void
> > DES_random_key(krb5_context context,
> > krb5_keyblock *key)
> >
> ...I've just discovered that changing DES functions to be DES_* clashes
> with Kerberos... for example:
>
> static void
> DES_random_key(krb5_context context,
> krb5_keyblock *key)
>
> - do we have any views on this?
>
> Cheers,
>
>
...I've just discovered that changing DES functions to be DES_* clashes
with Kerberos... for example:
static void
DES_random_key(krb5_context context,
krb5_keyblock *key)
- do we have any views on this?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is n
d. I was not making a claim that things had been broken. I
was simply reminding people to be careful because unlike other areas
of the crypto library, DES does have the potential to break a
significant number of third party libraries.
Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 B
On Wed, Aug 01, 2001 at 12:49:31PM +0100, Ben Laurie wrote:
> (incidentally, when
> did the weak_key member get introduced [in the wrong place]?).
When: SSLeay 0.9.1b.
Why: No idea.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informat
Bodo Moeller wrote:
>
> On Tue, Jul 31, 2001 at 01:49:24PM -0400, Jeffrey Altman wrote:
>
> >>> Please be very careful with the changes that are made to DES. The DES
> >>> structures and functions from OpenSSL were originally designed by Eric
> >>&g
On Tue, Jul 31, 2001 at 01:49:24PM -0400, Jeffrey Altman wrote:
>>> Please be very careful with the changes that are made to DES. The DES
>>> structures and functions from OpenSSL were originally designed by Eric
>>> to be compatible with the MIT Kerberos DE
Jeffrey Altman wrote:
>
> > > Please be very careful with the changes that are made to DES. The DES
> > > structures and functions from OpenSSL were originally designed by Eric
> > > to be compatible with the MIT Kerberos DES implementation. This has
> > >
> And no, they don't currently use OpenSSL instead of libdes by
> default. At least for Heimdal, it's only an option. I have no idea
> if MIT KRB has even gotten that far yet.
The MIT krbcore team has talked about replacing their crypto library
with OpenSSL. However, no work has started.
J
> > Please be very careful with the changes that are made to DES. The DES
> > structures and functions from OpenSSL were originally designed by Eric
> > to be compatible with the MIT Kerberos DES implementation. This has
> > allowed applications such as C-Kermit to imp
> > IIRC, libdes, which is what SSLeay has in crypto/des, and thusly
> > OpenSSL as well (or at least originally :-)), was written to be
> > compatible with MIT KRB's DES library, so EAY would be able to write
> > eBones-Kerberos, which in turn is the basis for KTH-kr
From: Ben Laurie <[EMAIL PROTECTED]>
ben> I find it hard to believe that the Kerberos data structures are as
ben> broken as the OpenSSL ones were.
ben>
ben> Are you saying that you use the same data structure for calls to
ben> Kerberos DES as to OpenSSL DES? Initialised by
Richard Levitte - VMS Whacker wrote:
>
> From: Ben Laurie <[EMAIL PROTECTED]>
>
> ben> I find it hard to believe that the Kerberos data structures are as
> ben> broken as the OpenSSL ones were.
> ben>
> ben> Are you saying that you use the same data struct
; > expect a pointer to the struct where previously they expected
> > a pointer to the first element of the array, meaning that
> > '&' has to be added when some des_key_schedule typed variable
> > is used.
> >
> > Also doc/crypto/des.pod should be update
t;
> > It got one, when I committed from the right directory!
>
> +) Rationalise EVP so it can be extended: don't include a union of
> cipher/digest structures, add init/cleanup functions. This also reduces
> the number of header dependencies.
> [Ben Laurie]
That's t
Bodo Moeller wrote:
>
> On Mon, Jul 30, 2001 at 07:47:13PM +0200, [EMAIL PROTECTED] wrote:
>
> > Index: des.h
> > ===
> > RCS file: /e/openssl/cvs/openssl/crypto/des/des.h,v
> > retrievi
On Mon, Jul 30, 2001 at 07:47:13PM +0200, [EMAIL PROTECTED] wrote:
> Index: des.h
> ===
> RCS file: /e/openssl/cvs/openssl/crypto/des/des.h,v
> retrieving revision 1.32
> retrieving revision 1.33
> dif
Richard Levitte - VMS Whacker wrote:
>
> From: Ben Laurie <[EMAIL PROTECTED]>
>
> ben> You mean binary compatibility, which we are well known not to have?
>
> True, but there have been maniacs out there building shared libraries
> anyway, and I suspect Eric kept the function around for binary
>
From: Ben Laurie <[EMAIL PROTECTED]>
ben> You mean binary compatibility, which we are well known not to have?
True, but there have been maniacs out there building shared libraries
anyway, and I suspect Eric kept the function around for binary
compatibility. I can see no other reason why he woul
Richard Levitte - VMS Whacker wrote:
>
> From: Ben Laurie <[EMAIL PROTECTED]>
>
> ben> > For compatibility with older versions of libdes, I'm sure.
> ben>
> ben> Well, its defined in the header, so I can't see why you need it for
> ben> compatibility.
>
> Share libraries...
You mean binary com
From: Ben Laurie <[EMAIL PROTECTED]>
ben> > For compatibility with older versions of libdes, I'm sure.
ben>
ben> Well, its defined in the header, so I can't see why you need it for
ben> compatibility.
Share libraries...
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Sta
Ulf Moeller wrote:
>
> On Sun, Feb 04, 2001, [EMAIL PROTECTED] wrote:
>
> > Can't remember why this was needed?
>
> For compatibility with older versions of libdes, I'm sure.
Well, its defined in the header, so I can't see why you need it for
compatibility. What I meant was I couldn't remem
From: Ulf Moeller <[EMAIL PROTECTED]>
ulf> On Sun, Feb 04, 2001, [EMAIL PROTECTED] wrote:
ulf>
ulf> > Can't remember why this was needed?
ulf>
ulf> For compatibility with older versions of libdes, I'm sure.
Very much older, as in SSLeay-era :-).
--
Richard Levitte \ Spannvägen 38, II \ [
On Sun, Feb 04, 2001, [EMAIL PROTECTED] wrote:
> Can't remember why this was needed?
For compatibility with older versions of libdes, I'm sure.
__
OpenSSL Project http://www.openssl.org
Develop
Hi
In objects.h, object identifier of DES-CBC is 1L,3L,14L,3L,2L,7L
Does above object id correspond to 'des_ncbc_encrypt' or 'des_cbc_encrypt'?
Thanks in advance.
__
OpenSSL Project
Have anyone heard of the DES-MAC?
As far as i know, there is the function "des_cbc_cksum" in openssl.
If anyone know of that function, please let me know how to use that function.
I can't figure out the parameters of that function..
i'll be apprec
Hi,
I'm using Konqueror in KDE 2 which uses OpenSSL. I have found that logging on
to a particular site has been problematic. The base address is
https://www20.secure-website.net/
What I have found is that I have to disable SSLv3 and also with version 2
RC4-64-MD5 seems to conflict. After disa
Just reply yes or no. If no, please clear my confusion...
DES-CBC3-SHA is using triple DES, yes?
DES-CBC-SHA is using DES?
Crispin
__
OpenSSL Project http://www.openssl.org
Development Mailing
Hi,
I'm testing DES CBC SHA1 between an openssl server and client.
The server is trying to decrypt a message from the client and
is reporting an ssl error SSL_R_BLOCK_CIPHER_PAD_IS_WRONG .
Any help would be appreciated.
Hi! I am interested to find out more about stong
encryption.
Can anyone tell me how can I generate the 2 keys
necessary in a triple-DES operation?
Do I need to buy a Digital Certificate from
Verisign or can I generate one on my own? I have managed to generate a 40-bits
key but how can
An UltraSPARC assembler version of Eric Youngs LibDES/SSLeay/OpenSSL
des_enc.c file is available at http://inet.uni2.dk/~svolaf/des.htm.
This brings DES on UltraSPARC from slower than Pentium at the same
clock speed to significantly faster.
On a 167 MHz UltraSPARC 1, the output from the LibDES
> The first guess would be that you didn't make libdes use the optimized
> assembler code.
You were right, but the problem is still open. I get now a speed of 15
MB/s (~ 40 % faster).
I am pretty sure that the benchmark code of OpenSSL is broken on fast
machines, and I'll have a look
as soon as p
On Fri, Mar 24, 2000 at 08:03:00AM +, Pascal JUNOD wrote:
> How do you explain following :
The first guess would be that you didn't make libdes use the optimized
assembler code.
__
OpenSSL Project
How do you explain following :
Using libdes 4.01, I get following performance on my machine (Linux
2.2.5, PIII 666Mhz)
[pjunod@lasecpc4 des]$ ../../../libdes/speed
Doing set_key for 10 seconds
4803568 set_key's in 10.00 seconds
Doing des_encrypt's for 10 seconds
15436306 des_encrypt&
I'm not sure if anyone has stumbled over this or who to send this to, but the
Makefile in the crypto/des directory lists fcrypt.c as a source file twice. My
linker complained about the multiple symbol definitions.
Doug
begin:vcard
n:Hoffman;Doug
tel;fax:(515)224-1352
tel;work:(515)327-2
If I am not mistaken, line 100 in fcrypt_b.c (the loop of fcrypt_body())
should be
#ifndef DES_UNROLL
instead of
#ifdef DES_UNROLL.
Yoram Meroz
__
OpenSSL Project http://www.openssl.org
Develo
When I use the DES-CBC-SHA mode with openssl 0.9.4:
openssl s_client -port 28000
the DES decryption of the finished message doesn't
work, the decryptes buffer doesn't look like the
waiting message.
The version selected is ssl3.0.
This appear only some times.
Does anybody has ever
> ulf> > des_read_pw_string ../libcrypto.a(evp_key.o)
> ulf>
> ulf> Is there any reason why that function is defined in the DES directory
> ulf> at all? Couldn't the implementation be moved into evp/evp_key.c?
>
> I assume it has to d
ulf> > des_read_pw_string ../libcrypto.a(evp_key.o)
ulf>
ulf> Is there any reason why that function is defined in the DES directory
ulf> at all? Couldn't the implementation be moved into evp/evp_key.c?
I assume it has to do with the EAY's thoughts abo
defined in the DES directory
at all? Couldn't the implementation be moved into evp/evp_key.c?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTEC
- Original Message -
From: Bodo Moeller <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; Alberto Velo <[EMAIL PROTECTED]>
Sent: Wednesday, August 04, 1999 7:04 PM
Subject: Re: DES
> > Wow, nothing easy for me to understand in that file.. I even tried
compiling
>>> I am able to do this with ssleay:
>>> ssleay.exe enc -des -in input.txt -out output.txt -e -a -k mypassword
>>[...] for "openssl enc", you could use, say,
>> -des_ede instead of -des. (-des_ede is two-key Triple-DES).
>&
- Original Message -
From: Bodo Moeller <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 03, 1999 8:38 PM
Subject: Re: DES
[...]
> > I am able to do this with ssleay:
> > ssleay.exe enc -des -in input.txt -out output.txt -e -a -k mypassword
&
On Tue, Aug 03, 1999 at 12:07:54PM +0200, Alberto Velo wrote:
> now I'd like to do a simple application, which gets an ascii input file and
> creates an encrypted (DES) output file.
>
> I am able to do this with ssleay:
> ssleay.exe enc -des -in input.txt -out output.txt
s an ascii input file and
creates an encrypted (DES) output file.
I am able to do this with ssleay:
ssleay.exe enc -des -in input.txt -out output.txt -e -a -k mypassword
I believe the des functions des_enc_read() or des_fcrypt() should be useful
for me, but I miss details and cannot find them i
99 12:27 PM
> To: [EMAIL PROTECTED]
> Subject: Key generation for DES
>
>
> Hi there!
>
> I would like to use X509 certificates generated by ssleay/openssl within
> a Java application I am writing. Of course the corresponding private keys
> should be encrypted. Now my p
Hi there!
I would like to use X509 certificates generated by ssleay/openssl within
a Java application I am writing. Of course the corresponding private keys
should be encrypted. Now my problem is how do I get the right DES key from
the information stored in the private key file and the users
On Tue, Jun 15, 1999 at 01:22:29PM +0200, Erwann ABALEA wrote:
> Something strange happens when I try to encrypt some data using the
> 'openssl enc' tool... [...] always 1 block larger... (or course, if
> I start with a 7 bytes file, I end with an 8 bytes file, that's
> normal). Is the padding
Hello,
Something strange happens when I try to encrypt some data using the
'openssl enc' tool...
If I create a 8-byte file filled with NUL, and I try to encrypt it using
DES or DES-EDE in ECB mode, I get a result file containing 16 bytes... If
I try with a larger input file, say a 32
In article <[EMAIL PROTECTED]> you wrote:
> Can we dump all those old files in crypto/des that had already been
> deleted for 0.9?
I think, yes. At least when we should find out that we need one in the future
we still have it in the CVS Attic.
I mean crypto/des/asm.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
101 - 200 of 204 matches
Mail list logo
