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-boun...@openjdk.java.net> on behalf
of Thomas Lußnig <open...@suche.org>
*Sent:* Tuesday, October 23, 2018 8:24:33 PM
*To:* security-dev@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
