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