Secure Hash Algorithm oder etwas ähnliches

[gastantwort]

Dravere schrieb:

@gastantwort,
Wenn ich per Suche etwas gefunden hätte, hätte ich hier nicht gefragt. Allerdings scheine ich zu spezifisch gesucht zu haben (z.B. in java-forum.org). Per Google oder Bing hatte ich keine grosse Hoffnungen was zu finden, da sha und java einfach zu allgemeingültige Begriffe sind.

Und auch wenn es noch so einfach wäre, hättest du ja auch einfach "Klasse MessageDigest" hinschreiben können. Das hätte mir bereits gereicht, dann wäre ich alle Java-Klassen aus der Standardbibliothek danach durchsuchen gegangen und hätte es gefunden.

Laber doch keinen Quatsch. Die ersten 3 Ergebnisse bei google für "java sha" sind bei mir:
Arena Red | SHA and MD5 in Java
MessageDigest (link zur API Dokumentation)
sha1 - Java Compute SHA-1 - Stack Overflow

[Dravere]

@gastantwort,

-> Ich hatte keine Hoffnung -> Ich habe es erst gar nicht gemacht ...

Java ... Damit verbindet man wirklich nur negatives

Grüssli

[Gast]

Dravere schrieb:

@gastantwort,

-> Ich hatte keine Hoffnung -> Ich habe es erst gar nicht gemacht ...

Java ... Damit verbindet man wirklich nur negatives

Grüssli

Deine Ablehnung Javas erzeugt eine psychische Blockade, so dass du nicht einmal mehr zur effektiven Internet-Recherche fähig bist. Ich hätte nie geglaubt, dass sowas so weit führen kann.

[Dravere]

Z schrieb:

Deine Ablehnung Javas erzeugt eine psychische Blockade, so dass du nicht einmal mehr zur effektiven Internet-Recherche fähig bist. Ich hätte nie geglaubt, dass sowas so weit führen kann.

Was erwartest du von einer Sprache, wo man sowas schreiben muss:

MessageDigest sha256;

try
{
  sha256 = MessageDigest.getInstance("SHA-256");
}
catch(NoSuchAlgorithmException ex)
{
  throw new RuntimeException("theoretical unreachable", ex);
}

Das macht einem einfach nur fertig.

Grüssli

[Dasd]

Dravere schrieb:

Das macht einem einfach nur fertig.

Mir geht es mit C++ so. Wenn dir eine Sprache nicht gefällt, nimm eine andere. Und wenn du dazu gezwungen bist dann reiß dich zusammen und hoffe, dass es möglichst bald vorbei ist.

[Dravere]

Dasd schrieb:

Dravere schrieb:

Das macht einem einfach nur fertig.

Mir geht es mit C++ so. Wenn dir eine Sprache nicht gefällt, nimm eine andere. Und wenn du dazu gezwungen bist dann reiß dich zusammen und hoffe, dass es möglichst bald vorbei ist.

Man zwingt mich dazu! Und noch zu einigem anderem (Glassfish, JavaEE, JMS, usw.)! Unverschämtheit
Aber es geht zum Glück aktuell ganz gut. Manchmal erfasst es einem halt nur wieder, wenn etwas nicht geht und dann geht man über jedes negative Detail der Sprache her

Das Problem sitzt aber natürlich wie immer vor dem Computer

Grüssli

[Gast]

Dravere schrieb:

Z schrieb:

Deine Ablehnung Javas erzeugt eine psychische Blockade, so dass du nicht einmal mehr zur effektiven Internet-Recherche fähig bist. Ich hätte nie geglaubt, dass sowas so weit führen kann.

Was erwartest du von einer Sprache, wo man sowas schreiben muss:

MessageDigest sha256;

try
{
  sha256 = MessageDigest.getInstance("SHA-256");
}
catch(NoSuchAlgorithmException ex)
{
  throw new RuntimeException("theoretical unreachable", ex);
}

Das macht einem einfach nur fertig.

Grüssli

Was soll damit sein? Wärs dir lieber, getInstance() würde im Fall des Scheiterns eine Nullreferenz zurückgeben? Du programmierst sonst in C o.ä., oder?

[Dravere]

Z schrieb:

Was soll damit sein? Wärs dir lieber, getInstance() würde im Fall des Scheiterns eine Nullreferenz zurückgeben? Du programmierst sonst in C o.ä., oder?

Naja, wenn man in C# oder C++ wären, müsste man dieses unnötige Try-Catch gar nicht hinschreiben. Aber sogar in Java hätte man doch die Standardalgorithmen, welche in allen Implementierungen dabei sind, mit einer entsprechenden Methode versehen können: getSHA256Instance() . Diese wirft dann auch keine Exception. Für nicht standardisierte Algorithmen, könnte man immer noch getInstance anbieten, wo man einen String übergibt.

Nein ich programmiere normalerweise nicht in C.

Grüssli

[Gast]

Dravere schrieb:

Naja, wenn man in C# oder C++ wären, müsste man dieses unnötige Try-Catch gar nicht hinschreiben.

Du kannst stattdessen ein "throws Exception" an den Methodenkopf hängen, dann musst du Exceptions, die innerhalb der Methode auftreten können, nicht mehr berücksichtigen.

Dravere schrieb:

Aber sogar in Java hätte man doch die Standardalgorithmen, welche in allen Implementierungen dabei sind, mit einer entsprechenden Methode versehen können: getSHA256Instance() .

SHA256 ist eben nicht zwingend in allen Implementationen der MessageDigest-Klasse enthalten. Es gibt durchaus auch abgespeckte Varianten.

[Dravere]

Z schrieb:

Du kannst stattdessen ein "throws Exception" an den Methodenkopf hängen, dann musst du Exceptions, die innerhalb der Methode auftreten können, nicht mehr berücksichtigen.

Dann hat man das Problem in der übergeordneten Methode und so weiter bis zur main . Dies ist definitiv keine Lösung sondern ein hässlicher Workaround. Ich schreibe mir lieber kurz eine eigene getSHA256Instance Methode, welche keine Exception wirft.

Dravere schrieb:

SHA256 ist eben nicht zwingend in allen Implementationen der MessageDigest-Klasse enthalten. Es gibt durchaus auch abgespeckte Varianten.

Also wenn ich nach der Java SE Dokumentation gehe, dann werde ich auf Appendix A verwiesen:

Java SE API Dokumentation / Appendix A schrieb:

The JDK Security API requires and uses a set of standard names for algorithms, certificate and keystore types. The specification names previously found here in Appendix A and in the other security specifications (JSSE/CertPath/etc.) have been combined in the Standard Names document. ...

"Standard Names document" ist eine Weiterleitung auf ein Dokument mit den möglichen Namen, worin man die folgenden findet: MD2, MD5, SHA-1, SHA-256, SHA-384 und SHA-512. Wenn man dies so liest, klingt das eher danach, dass diese Algorithmen auf allen Java SE Implementationen vorhanden sein müssen.

Und auch wenn sie dieses Design gewählt haben, wieso haben sie nicht eher eine IllegalArgumentException gewählt? Es wird wohl eher sehr selten passieren, dass diese Exception überhaupt geworfen wird. Wieso hat man also nicht eine Exception gewählt, welche von der RuntimeException erbt, wie dies bei IllegalArgumentException der Fall ist. Und die würde hier auch absolut gut hinpassen, da man ja einen ungültigen String als Argument übergeben hätte.

Es ist immer wieder das Gleiche mit den Exceptions in Java. InterruptedException ist ja auch so eine nervtötende Exception in Java. Was man überall an Code sieht, wo diese Exception einfach leer gefangen wird. Die Leute werfen sie oft nicht mal als RuntimeException weiter.

Aber kritisieren darf man natürlich nicht ...

Grüssli

[Dasd]

Dravere schrieb:

Also wenn ich nach der Java SE Dokumentation gehe, dann werde ich auf Appendix A verwiesen:

Java SE API Dokumentation / Appendix A schrieb:

The JDK Security API requires and uses a set of standard names for algorithms, certificate and keystore types. The specification names previously found here in Appendix A and in the other security specifications (JSSE/CertPath/etc.) have been combined in the Standard Names document. ...

"Standard Names document" ist eine Weiterleitung auf ein Dokument mit den möglichen Namen, worin man die folgenden findet: MD2, MD5, SHA-1, SHA-256, SHA-384 und SHA-512. Wenn man dies so liest, klingt das eher danach, dass diese Algorithmen auf allen Java SE Implementationen vorhanden sein müssen.

Für mich klingt das eher danach, dass diese Namen verwendet werden müssen, falls die Algorithmen angeboten werden. Die Algorithmen selbst müssen nicht vorhanden sein.

Dravere schrieb:

Und auch wenn sie dieses Design gewählt haben, wieso haben sie nicht eher eine IllegalArgumentException gewählt? [...]

Zugegeben, die checked exceptions sind nicht immer optimal in Java (bis hin zu nervtötend), aber in diesem Fall berechtigt, da es sich ja möglicherweise um eine Nutzereingabe handelt. In dem Fall ist auch das weiterwerfen als RuntimeException schlecht, da diese ja ggfs. bis nach ganz oben durchfliegt und dein gesamtes Programm abschießt.

In dem Zusammenhang ist auch dein Code schlecht. Besser wäre, die Exception mittels throws oder ähnlichem durchzureichen, bis die Nutzerschnittstelle (oder die Logdatei, scheint sich ja um eine Webapplikation zu handeln) angemessen darauf reagieren kann. Andererseits fehlt mir natürlich auch der Kontext, um das wirklich bewerten zu können.

[Gast]

Dravere schrieb:

Dann hat man das Problem in der übergeordneten Methode und so weiter bis zur main . Dies ist definitiv keine Lösung sondern ein hässlicher Workaround.

Dieses "Problem" soll dich davor schützen potentielle Fehlerquellen zu ignorieren. Oder möchtest du lieber, dass sich dein Programm mit einem häßlichen Stackdump verabschiedet?

Dravere schrieb:

Ich schreibe mir lieber kurz eine eigene getSHA256Instance Methode, welche keine Exception wirft.

Und was machst du, sollte MessageDigest.getInstance() scheitern?

Dravere schrieb:

Also wenn ich nach der Java SE Dokumentation gehe, dann werde ich auf Appendix A verwiesen:

Java SE API Dokumentation / Appendix A schrieb:

The JDK Security API requires and uses a set of standard names for algorithms, certificate and keystore types. The specification names previously found here in Appendix A and in the other security specifications (JSSE/CertPath/etc.) have been combined in the Standard Names document. ...

"Standard Names document" ist eine Weiterleitung auf ein Dokument mit den möglichen Namen, worin man die folgenden findet: MD2, MD5, SHA-1, SHA-256, SHA-384 und SHA-512. Wenn man dies so liest, klingt das eher danach, dass diese Algorithmen auf allen Java SE Implementationen vorhanden sein müssen.

Nein, nur die Namen sind festgelegt.

[Dravere]

Dasd schrieb:

..., aber in diesem Fall berechtigt, da es sich ja möglicherweise um eine Nutzereingabe handelt.

Wie bitte? Du weisst schon, dass man dies für ALLES hinschreiben kann? Es könnte alles eine Benutzereingabe sein! Was ist das bitteschön für ein Argument?
Zudem habe ich bisher noch sehr selten gesehen, dass jemand !frei! den Hash Algorithmus auswählen konnte, in dem er ihn als String eingab. Das Höchste der Gefühle war bisher aus einer Liste vordefinierter Werte. Und sogar dies war erst einmal.

Normalerweise gehört ein bestimmter Hash Algorithmus zu einem bestimmten Ablauf. Da kannst du nicht beliebig zwischen Algorithmus A und B hin- und herwechseln. Wenn daher Algorithmus X nicht vorhanden ist, dann kannst du gleich einpacken.

Dasd schrieb:

In dem Fall ist auch das weiterwerfen als RuntimeException schlecht, da diese ja ggfs. bis nach ganz oben durchfliegt und dein gesamtes Programm abschießt.

Gut, dann fällt es bei den Tests gleich auf, dass der Algorithmus nicht vorhanden ist. Um genau zu sein sogar bereits bei den Unittests.

Z schrieb:

Dieses "Problem" soll dich davor schützen potentielle Fehlerquellen zu ignorieren. Oder möchtest du lieber, dass sich dein Programm mit einem häßlichen Stackdump verabschiedet?

Ich weiss schon, wieso Checked Exceptions eingeführt wurden. Ich kenne das ganze Marketing Blabla. Tatsache ist, dass es meistens nicht funktioniert. Die Leute sind so genervt von diesen Checked Exceptions, dass sie die Exception eben Leer fangen. Z.B. so:

try { Thread.sleep(100); }
catch(InterruptedException ex) { }

Ja, das bringt dann wirklich viel, falls die Exception doch mal auftritt
Von daher habe ich viel lieber einen Stackdump. Dann weiss ich, dass ich etwas falsch gemacht habe. Oder vielleicht war es auch gewollt.

Schlussendlich kann man auch in der main die Exceptions abfangen und noch einen kontrollierten Shutdown durchführen.

Z schrieb:

Und was machst du, sollte MessageDigest.getInstance() scheitern?

Ich freue mich über einen kontrollierten Absturz. Denn dann habe ich ein riesen Problem. Dieser Algorithmus muss vorhanden sein. Falls dies wirklich mal irgendwo auftauchen würde, würde ich dann wohl meine eigene Implementation anbieten, falls er auf dem System nicht vorhanden ist. Oder suche mir eine Third-Party Implementation. Allerdings ist er auf allen Systemen, welche zum Einsatz kommen, vorhanden.

Der Algorithmus muss vorhanden sein, daran führt kein Weg vorbei. Und diese Überprüfung findet bereits in den Unittests statt, welche automatisch vom CI-Server durchgeführt werden.

Grüssli

[Dasd]

Dravere schrieb:

Dasd schrieb:

..., aber in diesem Fall berechtigt, da es sich ja möglicherweise um eine Nutzereingabe handelt.

Wie bitte? Du weisst schon, dass man dies für ALLES hinschreiben kann? ...

Gebe zu, war ein etwas schwaches Argument. Es sei denn, man betrachtet auch die JVM selbst als "Nutzereingabe".

Dravere schrieb:

Dasd schrieb:

In dem Fall ist auch das weiterwerfen als RuntimeException schlecht, da diese ja ggfs. bis nach ganz oben durchfliegt und dein gesamtes Programm abschießt.

Gut, dann fällt es bei den Tests gleich auf, dass der Algorithmus nicht vorhanden ist. Um genau zu sein sogar bereits bei den Unittests.

Oder auch erst beim Kunden, wenn der doch eine andere JVM verwendet als die Unittests. Und ich kann Java-Programme, die man nur mit Java runterladen kann, nicht leiden.

Und ob das Prinzip der checked exceptions funktioniert obliegt doch der Entscheidung des Programmierers, oder?