Hashing in Java and Java Cryptography Architecture (JCA) design

[John Newman]

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/20181027/4caf1cfa/attachment.htm>