Hi Andrew,
I seem to recall that depending of the OpenSSL version, there was issue with
CFB1 mode.
Michel.
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de
?? ? via RT
Envoyé : lundi 7 novembre 2016 11:40
Cc :
Hi,
As I obviously needed to improve my test program,
I am now encrypting and decrypting files trying all ciphers in all their
available modes.
( ChaCha20, AES-128, AES-192, AES-256, Blowfish, Cast5, Camellia-128,
Camellia-192, Camellia-256, IDEA, Seed, 3 Keys Triple-DES, 2 Keys Triple-DES
)
(
Hi David,
After checking you are obviously right.
Contrary to my belief, my internal buffer was always larger than the longest
line I read.
:-(
Sorry for the noise, but thanks David for the explanations.
It helps me to fix my software (even if I will keep some spare bytes for
some time)
;-(
--
> I was able to trigger a crash simply by chaining an encrypt BIO with a
memory BIO containing a large plaintext and then stream 100 bytes out of it
at a time. BIO_read would consistently return 128 and, by the time the
function returned, the stack was thoroughly clobbered.
I am surprised. I
Not speaking for Greg, but for me, it is now working fine again.
Thanks Andy !
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Rich
Salz via RT
Envoyé : dimanche 31 juillet 2016 15:58
À : ghud...@mit.edu
Cc : openssl-dev@openssl.org
Objet :
Cool !
Many thanks Steve.
-Message d'origine-
De : Stephen Henson via RT [mailto:r...@openssl.org]
Envoyé : mardi 10 mai 2016 17:00
À : michel.sa...@free.fr
Cc : openssl-dev@openssl.org
Objet : [openssl.org #4173] help to check whether handshake negociates SRP or
PSK ciphersuite
This
Hi,
I was not able to build today's git repo.
May not be what you would like to do, but the attached patch should fix
that.
Regards,
Michel
Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17336
Copyright (C) Microsoft Corporation. All rights reserved.
link /nologo /debug
Hi Rich,
> OpenSSL doesn't promise to protect against all such errors :)
Really ? I'm a bit surprise that you don't care to allow to divide by zero...
Especially when it's not a big work to prevent such a case.
It's up to you.
> block size of zero is nonsensical
Zero is the block size returned
Hi,
Still doing some testing of OpenSSL 1.1.0, I experienced a crash in
PKCS12_key_gen_uni().
Even if the original mistake was in my test software, I believe it is worth
verifying that 'v' (MD block size) is not nul line 129 of p12_key.c,
because it is used as divisor line 136 :
Slen = v *
And attached a better patch, with updated documentation and some test data.
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Michel
via RT
Envoyé : samedi 26 mars 2016 17:21
Cc : openssl-dev@openssl.org
Objet : Re: [openssl-dev] [openssl.org
Hi,
Here is an updated patch which prevents 'unstreamable' modes (Wrap only for the
moment) to be streamed, while still allowing them to be encrypted or decrypted
if the internal buffer size is greater than the total data size.
Looks to work just fine to me, but I can still try to improve it
-612), and
only work with 'regular' files (disable the use of stdin) ?
Michel.
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Michel
via RT
Envoyé : vendredi 25 mars 2016 17:49
Cc : openssl-dev@openssl.org
Objet : Re: [openssl-dev
Thank's Steve.
So, if I understand you correctly, we can assume that for files whose data size
is lower than the buffer size - which we can adjust - it will always work.
Right ?
If yes, it looks to me still better than not being able to use it at all.
And for big files, we could warn about this
Hi,
While I was at it (allowing wrap/unwrap mode), I finally decided to remedy
some unnecessary restrictions of the 'enc' command.
The general idea is to allow to decrypt a file using the original passphrase
even when it is not internally salted (hence produced by another software),
in which
> I will make this work with our perl-based test framework.
Whao, I will feel like a member of your gang now !
;-)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4472
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
Hi Rich,
Thanks for your interest in this matter.
the 3 'raw128*.dec' should be the same as 'raw128.dat'
the 2 'raw192*.dec' should be the same as 'raw192.dat'
and finally, 'raw256-256.dec' should be the same as 'raw256.dat'.
FYI I will soon report a new/updated patch with other bugs and
Hi,
Here attached is some test data files and a patch against today's git repo
to allow for the use of wrap mode using the OpenSSL 'enc' command.
The 'raw*.dat' files contains the NIST test vectors, and the '*.ok.enc' the
expected encrypted result (base64 encoded with equivalent hexa value).
The
Hello,
When the -s option is used with the 'ciphers' command (version 1.1) , the
SRP suites are not listed.
Here attached is a proposed patch, based on what you did for PSK.
Regards,
Michel.
srp-ciphers.patch
Description: Binary data
___
wants to do. But it is just my opinion.
Thanks again,
Regards,
Michel
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Michel
via RT
Envoyé : jeudi 10 décembre 2015 23:37
Cc : openssl-dev@openssl.org
Objet : [openssl-dev] TR: [openssl.org #4172
Hi,
When configured with the no-nextproto option, compilation fails (OpenSSL
1.1.0, Windows 7 64).
This updated patch just add a #ifdef directive around targeted lines.
Regards,
Michel.
no-nextproto-1.1.patch
Description: Binary data
___
: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking
memory
On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote:
> On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote:
> > Hi,
> >
> > Following my previous mail, here attached is an updated patch
>
@openssl.org
Objet : Re: [openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking
memory
On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote:
> On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote:
> > Hi,
> >
> > Following my previous mail, here attache
:27:38PM +0100, Kurt Roeckx wrote:
> > On Thu, Dec 10, 2015 at 01:16:48PM +0100, Kurt Roeckx wrote:
> > > On Mon, Dec 07, 2015 at 03:47:56PM +0000, Michel via RT wrote:
> > > > Hi,
> > > >
> > > > Following my previous mail, here attached is an upd
Hi,
Following my previous mail, here attached is an updated patch against 1.02e
to fix the SRP VBASE memory leaks.
I understand the VBASE stuff is not a TLS critical component, but it is part
of the SRP command line tool.
NB : it's a pity that the base64 encoding is not the same than the one use
Hi,
I believe it would be nice to have an efficient way to check if handshake
results in a SRP or PSK ciphersuite.
As I do not like to trick with OpenSSL internal structures, I suggest to add
the following to ssl_ciph.c :
int SSL_CIPHER_is_PSK(const SSL_CIPHER *c)
{
if (c != NULL &&
Hi Julius,
I am afraid this is not related to the 'dev' list.
Did you try to modify the order of your header files as mentioned on several
other forums ?
http://comments.gmane.org/gmane.comp.encryption.openssl.devel/14135
(and include WinSock2.h before windows.h)
Regards,
Michel
26 matches
Mail list logo
