<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>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.</p>
<p>I also agree that there are ways to improve the core APIs,
including making them more functional/streaming, using fluent
syntax, etc. <br>
</p>
<br>
<div class="moz-cite-prefix">On 10/27/2018 6:23 AM, John Newman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:HE1PR0801MB1658F49380D0044F0FD22CC897F10@HE1PR0801MB1658.eurprd08.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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 style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
security-dev <a class="moz-txt-link-rfc2396E" href="mailto:security-dev-bounces@openjdk.java.net"><security-dev-bounces@openjdk.java.net></a> on
behalf of Thomas Lußnig <a class="moz-txt-link-rfc2396E" href="mailto:openjdk@suche.org"><openjdk@suche.org></a><br>
<b>Sent:</b> Tuesday, October 23, 2018 8:24:33 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><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>
</blockquote>
<br>
</body>
</html>