[openssl-users] Is authorized_keys2 read in Openssh version 4/5.x?

[Bhatt, Rakshesh 1. (Nokia - IN/Bangalore)]

Hi OpenSSL team,

How can I find out if authorized_keys2 is read in Openssh version 4.x/5.x? I 
understand that this is deprecated from version 3.0 onwards, but release notes 
of version 3.0 just says that," Future releases are likely not to read these 
files." So I am not able to tell for sure that it is not used in subsequent 
release or not.

Regards,
Rakshesh

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] iOS assembler questions

[Jakob Bohm]

On 04/08/2016 19:19, Jakob Bohm wrote:

I am trying to build the OpenSSL 1.0.2h ARM optimized assembler
routines for Apple iOS (the default build config doesn't do that
yet).

However the Apple version of the LLVM 7.3.0 ARM assembler seems
to reject some of the notation used by the current source code
(.type, .size and address subtraction).

Is there a known workaround/solution, or should I create my own
patch to fix this?


Bump

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr

[Dr. Stephen Henson]

On Thu, Aug 11, 2016, William King wrote:

> 
> 
> Does the BIO_seek() not handle incrementing or decrementing the IV
> counter? is there a callback that needs to be set to calculate what the
> IV counter value should be for a given file position for the cipher?
> 

Calling BIO_seek() on a chain of BIOs can have unpredictable results
especially if any buffer data or have internal state.

I'd suggest you use the cipher directly instead of through a cipher BIO.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr

[Salz, Rich]

> Does the BIO_seek() not handle incrementing or decrementing the IV
> counter? is there a callback that needs to be set to calculate what the IV
> counter value should be for a given file position for the cipher?

It does not.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr

[William King]

Same decryption issue happens if I run something like:

char buffer[1024] = {}, buffer2[1024] = {0};
size_t pos = BIO_tell(enc);
BIO_read(enc, buffer, 1024);
BIO_seek(enc, pos);
BIO_read(enc, buffer2, 1024);
if (memcmp(buffer, buffer2, 1024)) {
printf("Mismatched\n");
} else {
printf("Matched\n");
}


Does the BIO_seek() not handle incrementing or decrementing the IV
counter? is there a callback that needs to be set to calculate what the
IV counter value should be for a given file position for the cipher?

William King
Senior Engineer
Quentus Technologies, INC
1037 NE 65th St Suite 273
Seattle, WA 98115
Main:   (877) 211-9337
Office: (206) 388-4772
Cell:   (253) 686-5518
william.k...@quentustech.com

On 8/11/16 10:29 AM, William King wrote:
> Without any of the error checking code in place, this is what I'm testing:
> 
> /* START CODE BLOCK */
> const EVP_CIPHER *cipher = EVP_aes_256_ctr();
> const EVP_MD *digest = EVP_sha256();
> BIO *enc = BIO_new(BIO_f_cipher());
> BIO *in = BIO_new(BIO_s_file());
> EVP_CIPHER_CTX *ctx = NULL;
> char *path = "/path/to/file.wav", *key = "fake secret key", *iv = "fake iv";
> 
> BIO_get_cipher_ctx(enc, >ctx);
> 
> if (BIO_read_filename(in, path) <= 0 ) {
>   assert(0);
> }
> 
> BIO_push(enc, in);
> 
> BIO_set_cipher(enc, cipher, key, iv, 0);
> 
> BIO_seek(enc, 2056);
> 
> BIO_read(enc, buffer, 128);
> 
> /* END CODE BLOCK */
> 
> What I'm finding is that using fread() of the unencrypted file and
> comparing that to the BIO_seek() then BIO_read(), the data is not
> properly decrypted. Comparing fread() of the unencrypted file, to just
> doing BIO_read()'s does decrypt the file correctly.
> 
> William King
> Senior Engineer
> Quentus Technologies, INC
> 1037 NE 65th St Suite 273
> Seattle, WA 98115
> Main:   (877) 211-9337
> Office: (206) 388-4772
> Cell:   (253) 686-5518
> william.k...@quentustech.com
> 
> On 8/9/16 2:10 PM, William King wrote:
>> What is needed to be able to BIO_seek() on a bio_f_cipher() with a
>> cipher of EVP_aes_256_ctr() without the counter, or IV or another
>> internal state getting corrupted?
>>
>> It seems that doing a seek any direction results in corrupted output.
>>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr

[William King]

Without any of the error checking code in place, this is what I'm testing:

/* START CODE BLOCK */
const EVP_CIPHER *cipher = EVP_aes_256_ctr();
const EVP_MD *digest = EVP_sha256();
BIO *enc = BIO_new(BIO_f_cipher());
BIO *in = BIO_new(BIO_s_file());
EVP_CIPHER_CTX *ctx = NULL;
char *path = "/path/to/file.wav", *key = "fake secret key", *iv = "fake iv";

BIO_get_cipher_ctx(enc, >ctx);

if (BIO_read_filename(in, path) <= 0 ) {
assert(0);
}

BIO_push(enc, in);

BIO_set_cipher(enc, cipher, key, iv, 0);

BIO_seek(enc, 2056);

BIO_read(enc, buffer, 128);

/* END CODE BLOCK */

What I'm finding is that using fread() of the unencrypted file and
comparing that to the BIO_seek() then BIO_read(), the data is not
properly decrypted. Comparing fread() of the unencrypted file, to just
doing BIO_read()'s does decrypt the file correctly.

William King
Senior Engineer
Quentus Technologies, INC
1037 NE 65th St Suite 273
Seattle, WA 98115
Main:   (877) 211-9337
Office: (206) 388-4772
Cell:   (253) 686-5518
william.k...@quentustech.com

On 8/9/16 2:10 PM, William King wrote:
> What is needed to be able to BIO_seek() on a bio_f_cipher() with a
> cipher of EVP_aes_256_ctr() without the counter, or IV or another
> internal state getting corrupted?
> 
> It seems that doing a seek any direction results in corrupted output.
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl and floating point

[Short, Todd]

The -Ddouble=long hack might very well cause problems with standard headers.

I’m assuming you are not talking about x86 or any other platform for which 
there is assembly support.

In such a case, I suggest #ifdef’ing out the code that you don’t care about, 
and making it into a configuration option, the submitting a patch for it.
There may be some use for this configuration, especially on low-power IoT-type 
things.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 10, 2016, at 11:52 AM, Jakob Bohm 
> wrote:

(Top posting for consistency in this part of the thread)

Note, however that emulated floating point tends to add code
size and startup overhead even when not called.

Hence the need to compile with an option to not use floating
point at all, at least on platforms that don't have platform-
specific optimizations via hardware floating point (such as
the SSE optimizations for some operations on x86 or the VFP
optimizations on later ARM hardware types).

Rich suggested a "hackish" preprocessor trick, which depends
on no current or future OpenSSL code using floating point in
a way that is seriously broken by that trick.

On 10/08/2016 16:51, Kyle Hamilton wrote:
This is compiler-dependent, and because you didn't specify what platform you're 
targeting or what compiler you're using, there's no way for us to provide an 
answer. Check your compiler's documentation.  GCC, for example, provides 
software-emulated floating point for platforms without hardware support.  Many 
other open-source and commercial compilers do as well.

On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman 
 
>wrote:

   We have a platform that does not support floating point
   operations.  We discovered that openssl uses floating point in the
   random number generator.

   Is there any build or compile time flag that uses an alternative
   to floating point?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CVE-2016-2180

[Salz, Rich]

There is no test.  That fix can be applied.  1.0.0 is really old and 
unsupported, you should upgrade as soon as possible

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz

From: siva gopi raju kudeti [mailto:sivagopi...@gmail.com]
Sent: Thursday, August 11, 2016 6:18 AM
To: openssl-users@openssl.org
Subject: [openssl-users] CVE-2016-2180

Hi OpenSSL team,

I am using openssl-1.0.0e in my product. Here i want to know that OpenSSL is 
CVE-2016-2180 vulnerable or not.

https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca37365e8c7403a?diff=unified

In this page showing some modifications to the function TS_OBJ_print_bio. Is 
these changes are fix this vulnerability?

Here i don't know how to test this vulnerability.

Can you please provide me with the test process or ant other information about 
this vulnerability to go further.

I will wait for your reply.

best regards,
Gopi.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] CVE-2016-2180

[siva gopi raju kudeti]

Hi OpenSSL team,

I am using openssl-1.0.0e in my product. Here i want to know that OpenSSL
is CVE-2016-2180 vulnerable or not.

https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca373
65e8c7403a?diff=unified

In this page showing some modifications to the function TS_OBJ_print_bio.
Is these changes are fix this vulnerability?

Here i don't know how to test this vulnerability.

Can you please provide me with the test process or ant other information
about this vulnerability to go further.

I will wait for your reply.

best regards,
Gopi.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users