Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>
Newsgroups: sci.crypt,comp.lang.java.programmer
Subject: Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function?
Date: Mon, 18 Jun 2018 13:33:03 -0700
Organization: n/a
Lines: 80
Message-ID: <pg94u2$o2q$1@dont-email.me>
References: <pdf0kv$uom$1@news.albasani.net> <pdfjv8$e8s$1@news.albasani.net> <foq5mlF5sm0U1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 18 Jun 2018 20:33:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d5de968dba25ff2ab01ff4ca0b8b1b5b"; logging-data="24666"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19TeEZAUZuia6VG2ISKuAqqm8Da38bk7KA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
Cancel-Lock: sha1:KzyLe7lV3bTyFZQ+mSSWT/DBOgg=
In-Reply-To: <foq5mlF5sm0U1@mid.individual.net>
Content-Language: en-US
Xref: csiph.com sci.crypt:43714 comp.lang.java.programmer:38389

On 6/18/2018 9:41 AM, Robert Klemme wrote:
> On 15.05.2018 23:37, Karl.Frank wrote:
>> Holy moley! It's a buggy Java Library I'm currently using!!
> 
> You are converting a byte array to a String without explicit mention of 
> the encoding.  Maybe the way Java picks up the default encoding has 
> changed between versions.  Anyway, this is an unsafe practice.
[...]

Yup. For instance, I had to alter my Python test vector to use 
bytearrays without default encoding in order for it go get in perfect 
sync with a C analog.

https://groups.google.com/forum/#!original/sci.crypt/2K33_4GjkVs/Ws6bWE-aAQAJ
(read all for context...)

The C code:

https://pastebin.com/raw/feUnA3kP

The Python Test vector:

https://pastebin.com/raw/NAnsBJAZ

Notice the following code in the Python version:
___________________________________
if (M == False):
     U = bytearray([P_byte, C_I_P]);
     H.update(U);
else:
     U = bytearray([C_I_P, P_byte]);
     H.update(U);
___________________________________

Here is the equivalent C code in the ct_crypt_round function:
___________________________________
if (M == 0)
{
     unsigned char update[2] = {
         P_byte, C_byte
     };

     hmac_sha256_update(&H, update, 2);
}

else
{
     unsigned char update[2] = {
         C_byte, P_byte
     };

     hmac_sha256_update(&H, update, 2);
}
___________________________________


Now, there is a way to get a different result in the Python test 
vector... Use the default encoding! Afaict, it can change on different 
impls. Example:
___________________________________
if (M == False):
     H.update(P.bytes[I_P].encode());
     H.update(chr(C_I_P).encode());
else:
     H.update(chr(C_I_P).encode());
     H.update(P.bytes[I_P].encode());
___________________________________

NO! This is unsafe. I need to correct my code in my paper:

http://funwithfractals.atspace.cc/ct_cipher/

that uses the .encode() function to the one that uses bytearrays. Damn 
it.. Sorry!

I had a weary feeling about using default encoding, but finally verified 
it when I worked on getting the C version and Python test vector in 
perfect sync. Please keep in mind that one needs to define 
PYTHON_TEST_VECTOR in my C code to sync it up with the Python test vector.