Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > sci.crypt > #43718

Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function?

From Robert Klemme <shortcutter@googlemail.com>
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 2018-06-19 23:15 +0200
Message-ID <fota35Foc74U1@mid.individual.net> (permalink)
References <pdf0kv$uom$1@news.albasani.net> <pdfjv8$e8s$1@news.albasani.net> <foq5mlF5sm0U1@mid.individual.net> <pgandc$d8a$1@news.albasani.net>

Cross-posted to 2 groups.

Show all headers | View raw


On 19.06.2018 12:54, Karl.Frank wrote:
> On 18.06.18 18:41, 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.
>>
> Robert, probably that might be the case.

It is, it is.

> In regards of cryptography I always tend to stay on the byte level. This
> way my own implementation of HMAC and PBKDF2 has no need to bother with
> string encoding when reading in from stdin or files. Curiously Java's
> PBKDF2 expect a string or char array rather than a byte array and
> therefore I need the extra conversion. Actually from now on my own
> functions will be used instead.

The point is not your usage of byte array nor your need for a 
conversion.  The point is that your conversion is unsafe because the 
default encoding is used implicitly instead of making your choice of 
encoding explicit.  There are various factors that might influence the 
JVM's choice of default encoding and they might not be the same as 
govern the encoding of the user input (what you send via echo).  This is 
a source of errors and the bad thing is it might actually work in one 
environment - but not in others.  Such bugs can go unnoticed for a long 
time before they hit you.  And then you're left with wrongly encoded 
data which can be very painful.

> It might be a different matter if the user type in password and/or salt
> in some GUI. In this case however I would define the kind of strings
> accepted and later convert them into byte arrays before processing them
> further.

Graphical inputs usually emit String, char[] or CharSequence so you can 
be sure the input is properly encoded (modulo some issues) and you can 
pick whatever encoding you want for the transformation into bytes.

>> Also, you are reading only once, there is the chance that there is still
>> data in the pipe which you will miss. Even worse, depending on how data
>> is written to stdin you might even get different results. This might not
>> be an issue for your test program, but could be if you use this code in
>> production.
>>
> Well, yes I read only once from stdin and store the result in a byte
> array. How do you suppose to read twice?
> 
> The amount of byte to read is exactly defined by
> 
>    int BuffSize = System.in.available();
>    byte[] pwByte = new byte[BuffSize];
>    System.in.read(pwByte, 0, BuffSize);
> 
> How would the program read more byte than necessary?

Please read carefully: I wrote it might read _less_ bytes.  You should 
really read the JavaDocs of InputStream#available().  For example it is 
perfectly legal for an implementation to always return 0 yet still yield 
data via read().  Basically, available() is quite useless most of the 
time if you want to read the complete input anyway.

> As data on stdin is always byte and all my programs read in byte and
> never ever strings in my opinion it doesn't matter how these byte are
> written and piped by any previous instance or program.

Again, the point is a different one: your reading does not ensure you 
get the complete input.  For this you need a loop that reads until EOF. 
Using just a single read() is not sufficient as an implementation is 
free to choose how many bytes to return for a single read().

There is no way you can get away without a loop.

final byte[] buffer = new byte[1024];
final ByteArrayOutputStream out = new ByteArrayOutputStream();

for (int len; (len = in.read(buffer)) != -1;) {
     out.write(buffer, 0, len);
}

byte[] data = out.toByteArray();

There are other more elegant variants depending on which libs you use 
and on which Java version you are.

>>> So my own implementation works correctly - what a relieve!
>>
>> There are cases where wrong code emits correct results - and this
>> surfaces only later, when the input or some other environmental factor
>> changes.
>>
> That's one reason why I tend to run large and extensive tests before my
> program go into a production environment. Until today I've never
> experienced any real problem. Even in this case I'd implement my own
> HMAC and PBKDF2 and therefore found the "buggy" Java lib. Sadly the
> developer of the original program some years ago didn't check that and
> now everyone is baffled that we can't decrypt old files with the
> correctly working PBKDF2 implementation.

I am not convinced you have identified a "'buggy' Java lib".

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Back to sci.crypt | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 18:07 +0200
  Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 18:31 +0200
  Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Bruce Stephens <bruce.r.stephens@gmail.com> - 2018-05-15 19:46 +0100
    Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 20:52 +0200
  Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Rich <rich@example.invalid> - 2018-05-15 18:49 +0000
    Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 21:02 +0200
  Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? wizzofozz <oscxxxxxxxaas@gmail.com> - 2018-05-15 21:09 +0200
    Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? wizzofozz <oscxxxxxxxaas@gmail.com> - 2018-05-15 21:11 +0200
      Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 21:25 +0200
    Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 21:29 +0200
      Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? wizzofozz <oscxxxxxxxaas@gmail.com> - 2018-05-15 22:07 +0200
      Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Rich <rich@example.invalid> - 2018-05-15 20:38 +0000
        Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 22:57 +0200
  Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 21:42 +0200
  Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-15 23:37 +0200
    Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-05-16 15:58 +0200
    Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Robert Klemme <shortcutter@googlemail.com> - 2018-06-18 18:41 +0200
      Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-06-18 13:33 -0700
      Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-06-19 12:54 +0200
        Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Lothar Kimmeringer <news201705@kimmeringer.de> - 2018-06-19 22:18 +0200
          Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Robert Klemme <shortcutter@googlemail.com> - 2018-06-19 23:20 +0200
          Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-06-19 23:23 +0200
        Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? Robert Klemme <shortcutter@googlemail.com> - 2018-06-19 23:15 +0200
          Re: Why is Java 7 converting the Password toCharArray instead of Byte in it's PBKDF2 function? "Karl.Frank" <Karl.Frank@Freecx.co.uk> - 2018-06-20 00:03 +0200

csiph-web