Hashing in Java and Java Cryptography Architecture (JCA) design

[Adam Petcher]

There are several ways in which JCA is deficient when viewed from the 
standpoint of modern API design. At some point, we will probably want to 
develop a new API that doesn't have these issues. I expect this to 
require significant effort, though, and this sort of work gets lower 
priority compared to implementing new algorithms/standards and TLS 1.3 
work. So it is hard to tell if/when anyone will have time to work on this.

FWIW, I partially agree with the complaint about provider selection 
complexity. I think the provider/algorithm selection mechanism is 
important, but perhaps not everyone needs it, and it shouldn't clutter 
up the core APIs. A more typical pattern for this sort of thing is to 
include a configuration layer on top of the core 
abstractions/implementation, and all of the provider selection 
complexity would go in this layer.

I also agree that there are ways to improve the core APIs, including 
making them more functional/streaming, using fluent syntax, etc.


On 10/27/2018 6:23 AM, John Newman wrote:
> Not to be rude to Thomas but has anyone else have any thoughts on this?
> --Janez
> ------------------------------------------------------------------------
> *From:* security-dev <security-dev-bounces at openjdk.java.net> on behalf 
> of Thomas Lußnig <openjdk at suche.org>
> *Sent:* Tuesday, October 23, 2018 8:24:33 PM
> *To:* security-dev at openjdk.java.net
> *Subject:* Re: Hashing in Java and Java Cryptography Architecture 
> (JCA) design
> Hi,
>
> even if it looks complicated for you the idea is that your code is not
> hard wired to MD5 or SHA1 but in ideal case
> it is configured. Than you do not know in advance if the selected digest
> is available.
> On the other hand no one say that you can create your own helper/tools
> class.
> The idea is that you are not fixed to one algo but what if you say "MD4"
> or "POLY1305" only some algorithm
> where available at coding time thy can be removed later (maybe even via
> policy) or newly been added. For
> this there is the NoSuchAlgorithmException to show the developer there
> can be some error.
> RuntimeException would be ignored and may crash the whole program or task.
>
>
> Gruß Thomas
>
> class DIGEST {
>
> static byte[] SHA1(byte[]... args) {
> ...
> }
>
> }
>
> then you can simply call DIGEST.SHA1(a,b,c)
>
> On 23.10.2018 19:50:44, John Newman wrote:
> > This seems to me overly complicated for a simple task of
> > instantiating a MessageDigest object:
> >
> > MessageDigest md = null;
> > try {
> >      md = MessageDigest.getInstance("SHA-1");
> > } catch (NoSuchAlgorithmException nsae) {}
> >
> > Couldn't MessageDigest simply be an *interface* and
> > the SHA funcionality a special *implementation*, like so:
> >
> > MessageDigest md = new ShaMessageDigest();
> >
> > ?
> >
> > But instead we have these factory methods (accross all of the JCA
> > core classes) which throw exceptions, polluting the code. Is the
> > Provider abstraction really needed? The only real benefit I see is
> > neater class names.
> >
> > In fact - couldn't we get rid of the entire Java Cryptography 
> Architecture (JCA)
> > as it is and redesign it to be more object oriented? For example, 
> couldn't this:
> >
> > byte [][] args = //...
> > MessageDigest md = //..
> > md.update(args[0])
> > md.update(args[1]);
> > md.digest();
> >
> > become this:
> >
> > byte [][] args = //...
> > MessageDigest md = //..
> > md.update(args[0]).update(args[1]).digest();
> >
> > or maybe even this:
> >
> > MessageDigest md = //..
> > byte [][] args = //...
> > new IntermediateDigest(
> >      md,
> >      args[0],
> >      args[1]
> > ).bytes()
> >
> > where IntermediateDigest itself could be an argument to 
> MessageDigest's update()
> > method, making things like H(H(x), y) look much more compact and 
> readable?
> >
> >
> > --Janez

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181029/e042129a/attachment.htm>