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
