[JSP] SHA-1, hoe te doen?

[Miezie]

Voor een project met JSP wil ik van enkele strings een SHA-1 hash maken. Echter, ik kan na 2 uur zoeken in de apidocs ed. en hier op GoT niks hier over vinden. Het is vast een hele domme vraag, maar hoe krijg ik dit voor elkaar?

Thanks alvast voor jullie antwoord(en).

[momania]

[google=java,SHA-1]

Kom je al gauw uit bij iets als: http://java.sun.com/products/jce/jce122_providers.html

Via dat kom je dan bij http://jce.iaik.tugraz.at/ terecht. Daar kan je een toolkit downloaden die ook SHA-1 aankan

[edit]
oh damn, zie nu dat dat een pakket is dat je moet kopen

Maar volgens mij vind je via google genoeg implementaties van losse classes die SHA-1 voor je kunnen doen

[ Voor 29% gewijzigd door momania op 19-04-2006 22:16 ]

[Verwijderd]

http://www.google.com/search?q=java%2CSHA-1



shit, te laat

offtopic:
Is het vakantie of zo? Iedereen lijkt wel aan het programmeren geslagen...

[ Voor 52% gewijzigd door Verwijderd op 19-04-2006 22:19 ]

[NMe]

Desnoods implementeer je het zaakje zelf. Wikipedia heeft bijvoorbeeld wat pseudocode staan.

[HarmoniousVibe]

Misschien is dit iets? http://evolt.org/node/60122

[RobIII]

Voordat iemand me stenigt: ik weet dat Java geen Javascript is, maar een goed werkende implementatie in javascript vind je hier. Kwestie van omschrijven naar Java et voila.

Ik kom met javascript aanpoepen omdat ik me kon herinneren ooit eens dit scriptje te hebben gezien toen ik een javascript md5 zocht (ook aldaar gevonden overigens). Er zijn overigens in vele talen vele implementaties te vinden. Lijkt me stug dat er geen Java implementatie te vinden is.

[ Voor 50% gewijzigd door RobIII op 19-04-2006 23:41 ]

[Gert]

Java:

java.security.MessageDigest.getInstance("SHA")

Of is dat een verkeerde SHA?

[Verwijderd]

Enige moeilijke aan de standaard SHA digester in Java is dat er zo'n 'vervelende' byte array uitkomt. In een aantal gevallen wil je de SHA code gewoon als string hebben. Hiervoor moet je in Java nog zelf wat extra's doen en dan goed opletten dat je exact dezelfde string bouwt als operationaliteit met andere systemen van belang is.

[Standeman]

Verwijderd schreef op donderdag 20 april 2006 @ 00:55:
Enige moeilijke aan de standaard SHA digester in Java is dat er zo'n 'vervelende' byte array uitkomt. In een aantal gevallen wil je de SHA code gewoon als string hebben. Hiervoor moet je in Java nog zelf wat extra's doen en dan goed opletten dat je exact dezelfde string bouwt als operationaliteit met andere systemen van belang is.

Van een byte Array is vrij gemakkelijk een String te maken... zoiets als

code:

String s = new String(byte[] b);

Connecties met andere systemen kunnen inderdaad wel verassende dingen geven (IBM Z-OS met EBCDIC enzo )

[ Voor 9% gewijzigd door Standeman op 20-04-2006 01:10 ]

[Verwijderd]

Pak gewoon de documenten erbij. Zelfs voor Javascript was het nog geen uurtje werken om er zelf een te bakken. Zal effe de documenten erbij zoeken:

http://www.itl.nist.gov/fipspubs/fip180-1.htm
http://www.ietf.org/rfc/rfc3174.txt

En als je nieuwere SHA wil (die SHA-2 enzo): http://csrc.nist.gov/publ...s/fips180-2/fips180-2.pdf

[ Voor 20% gewijzigd door Verwijderd op 20-04-2006 13:19 ]

[RobIII]

Even om verwarring te voorkomen: SHA-2 "bestaat" niet

SHA-2 contains: SHA-224 · SHA-256 · SHA-384 · SHA-512
SHA-2 is based on: SHA-1

[ Voor 36% gewijzigd door RobIII op 20-04-2006 13:26 ]

[The - DDD]

Verwijderd schreef op donderdag 20 april 2006 @ 00:55:
Enige moeilijke aan de standaard SHA digester in Java is dat er zo'n 'vervelende' byte array uitkomt. In een aantal gevallen wil je de SHA code gewoon als string hebben. Hiervoor moet je in Java nog zelf wat extra's doen en dan goed opletten dat je exact dezelfde string bouwt als operationaliteit met andere systemen van belang is.

Ik weet niet je dit weet, maar een SHA1 hash wordt weergegeven als een hexadecimaal. Dit heeft niets met een Java String te maken en kun je dus zo over de lijn sturen, enkel als je het wil weergeven, dan zul je de bytes moeten renderen naar hexadecimaal.

Java:

BigInteger bi = new BigInteger(shaResultaatByteArray);
String s = bi.toString(16);

Het probleem wat je beschrijft is niet zo groot als je denkt. Je moet die digester namelijk updaten met je gegevens, de update methode wil een byte array hebben. Je hebt prima controle over welke encodeing gebruikt wordt wanneer je een String naar bytes converteert in Java met deze methode.

Een opmerking... BigINtegers gebruik ik niet zo vaak, dus ik kan je niet echt wat zeggen over hoe de performance is van het ding.

[ Voor 15% gewijzigd door The - DDD op 20-04-2006 14:03 ]

[-FoX-]

Och, zo moeilijk kan dat toch niet zijn... even proberen

Java:

String plainText = "plainTextPassword";

MessageDigest mdAlgorithm = MessageDigest.getInstance("SHA");
mdAlgorithm.update(plainText.getBytes());
byte[] digest = mdAlgorithm.digest();

StringBuffer hexString = new StringBuffer();
for (int i = 0; i < digest.length; i++) {
    plainText = Integer.toHexString(0xFF & digest[i]);

    if (plainText.length() < 2) {
        plainText = "0" + plainText;
    }

    hexString.append(plainText);
}

System.out.println("Original string: " + plainText + " hashed into: " + hexString.toString());

Niet getest, maar zou het wel zo ongeveer moeten doen..

[The - DDD]

Wat jij 6 statements voor nodig hebt, doe ik in 2.

UR owned...

(Gaat over die byte array converteren naar een hexadecimale weergave.)

[Verwijderd]

The - DDD schreef op donderdag 20 april 2006 @ 14:00:
Het probleem wat je beschrijft is niet zo groot als je denkt.

Ik zei ook niet dat het een enorm groot probleem is, maar wel dat je er even rekening mee moet houden. Laatst kwam ik dit nog tegen in een applicatie waar ergens diep in de code een hash berekend werd. Deze werd vervolgend door een aantal lagen heen gestuurd. In het verleden bestond deze hash uit een MD5, en elke laag verwachte dan ook een String. Toen dit een SHA1 moest worden, werd deze dus in de bron meteen omgezet naar een String.

Punt was toen dat op een hele andere plek van een input een gelijkwaarde string gemaakt moest worden om te kunnen vergelijken (effin, het hele nut dus van een SHA1). Omdat het daar een andere taal betrof en zelfs een compleet ander platform, kreeg men het toch voor elkaar om verschillen te krijgen in de string representatie.

Zoals hierboven aangetoond, geen -ramp-, maar alleen van mijn kant een hint om dat eventueel even in de gaten te houden