Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
De facto scheint's das praktisch nicht zu geben... ALLES, ABER WIRKLICH ALLES, wonach man sucht ist letztendliche nichts anderes als ein Proxy / eine Abstraktion - z.B. com.github.ivangolubev.pbkdf2sha512, Apache Commons Codec, Guava, whatever...
FRAGE: Kenne jemand von euch ne Library, welche das PBKDF2WithHmacSHA512-Verfahren im Griff hat aber in KEINSTER WEISE (!!) von irgendwelchen Klassen java.xxx..., javax.www..., com.sun etc. pp. abhängig ist...?
Es geht um einen älteren Java-Quelltext, der weiterhin mit dem älteren JRE laufen muss nun aber um PBKDF2WithHmacSHA512 erweitert werden soll.
"Soweit ich das sehe, gibt es da Implementierung bis zurück zum JDK 1.2 - das sollte mit einem alten JRE laufen."
Ich denke, "PBKDF2WithHmacSHA512" geht wohl eher (??) weniger bis ins Jahr 1998 zurück; kann aber auch sein, dass ich mich täusche. Hätte gemeint, dieser String als Parameter der Factory-Methode SecretKeyFactory.getInstance(...) wäre erst unterstützt ab Java 1.8?
Wie dem auch sei - da ich u.A. auch vor habe, das Programm nach .NET zu konvertieren (-> nach IKVM.NET googeln...) und es dann unter Debian Linux 11.0 mithilfe der Laufzeitumgebung "mono-complete" [Paket-Name] laufen zu lassen musste ich mit den Versionen etwas zurückfahren... Unter Eclipse habe ich gar Java 1.7 eingestellt, IKVM wandelt .jar [.class]-Dateien nach .NET 2.0 um (aktuelle Versionen / Forks von IKVM.NET ggf. höher?) und das Paket "mono-complete" unterstützt bei Debian auch nicht die aktuellsten .NET-Versionen.
(BTW. hab ich noch das Original .NET FW von M$ versucht auf Debian zu installieren, unterstützt Core 3.1 sowie 6.0 - ich denke, 6.0 sollte abwärtskompatibel sein zu den von IKVM.NET generierten v2.0-Executables... die Ausführung über "./myDotNetExecutable.exe", natürlich vorher mit "chmod +x myDotNetExecutable.exe" als "executable" geflaggt, geht beim Original-M$-Framework für Linux nicht einfach so... ich las was vom Paket "dotnet-host", aber aber auch nix gebracht... ggf. weiss ja jemand weiteres zum Thema (?))
So hab ich's gemacht, mit ein paar externen Libraries, welche noch zu älteren Versionen als 1.7 kompatibel sind... so wird das ganze Zeugs wohl gar Android-kompatibel sein - falls es eines Tages sein muss, wer weiss... ;-)
Java:
import org.apache.commons.codec.binary.Base64;
public class MosquittoUsrAcctGen {
private MosquittoUsrAcctGen(final String[] caArgs) throws Exception {
super();
if (caArgs.length < 2) {
System.out.println("No arguments set - please use as follows: MosquittoUsrAcctGen [username] [password]");
return;
}
/*
System.out.println("User: \r\n" + caArgs[0]);
System.out.println();
System.out.println("Password: \r\n" + caArgs[1]);
System.out.println();
*/
this.start(caArgs[0].trim(), caArgs[1].trim());
}
private void start(final String caUsername, final String caPassword) throws Exception {
final byte[] clRandomSaltByteArr = MyLibrary.generateRandomSalt(12);
final int numberOfIterations = 31000;
final String clSaltedPasswordHashAsBase64EncodedString = MyLibrary.pbkdf2Encode(caPassword, clRandomSaltByteArr,
numberOfIterations);
final String clRandomSaltAsBase64EncodedString = Base64.encodeBase64String(clRandomSaltByteArr);
final String clMosquittoUsernameAndPasswordValuePair = caUsername + ":$7$" + numberOfIterations + "$"
+ clRandomSaltAsBase64EncodedString + "$" + clSaltedPasswordHashAsBase64EncodedString;
System.out.println(clMosquittoUsernameAndPasswordValuePair);
}
public static void main(String[] caArgs) throws Exception {
if (caArgs == null) {
caArgs = new String[0];
}
new MosquittoUsrAcctGen(caArgs);
}
}
Code:
import java.security.SecureRandom;
import java.security.Security;
import org.apache.commons.codec.binary.Base64;
import org.bouncycastle.crypto.PBEParametersGenerator;
import org.bouncycastle.crypto.digests.SHA512Digest;
import org.bouncycastle.crypto.generators.PKCS5S2ParametersGenerator;
import org.bouncycastle.crypto.params.KeyParameter;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
public abstract class MyLibrary {
private MyLibrary() {
super();
}
static {
Security.addProvider(new BouncyCastleProvider());
}
public static byte[] generateRandomSalt(final int caNumberOfBytes) {
final byte[] lNonce = new byte[caNumberOfBytes];
new SecureRandom().nextBytes(lNonce);
final StringBuilder clResult = new StringBuilder();
for (final byte temp : lNonce) {
clResult.append(Integer.toHexString(temp));
}
byte[] lReturn = null;
String str = clResult.toString();
str = str.substring(0, caNumberOfBytes);
lReturn = str.getBytes();
return lReturn;
}
public static String pbkdf2Encode(final String rawPassword, final byte[] salt, final int numberOfIterations) {
try {
String ret = null;
PBEParametersGenerator generator = new PKCS5S2ParametersGenerator(new SHA512Digest());
generator.init(rawPassword.getBytes(), salt, numberOfIterations);
KeyParameter params = (KeyParameter) generator.generateDerivedMacParameters(512);
ret = Base64.encodeBase64String(params.getKey());
return ret;
} catch (final Exception ex) {
throw new RuntimeException(ex);
}
}
}
-> Mit Linux, IKVM.NET und "mono-complete" geht aber auch das hier nicht: static {
Security.addProvider(new BouncyCastleProvider());
}
...
...
...
SecretKeyFactory.getInstance("PBEWITHHMACSHA1", "BC");
Unter https://stackoverflow.com/questions/8674018/pbkdf2-with-bouncycastle-in-java wären die 3 Verfahren beschrieben: 1.) Java Framework (JRE) mit der SecretKeyFactory.getInstance(...)-Factory, dann 2.) die Bountycastle-Variante welche nicht als SecretKeyFactory.getInstance(...)-Factory implementiert ist und 3.) die Bountycastle-Variante welche als SecretKeyFactory.getInstance(...)-Factory implementiert ist.
(Der von mir verwendete Code für HMAC-SHA512 ist aber nicht von dort)
Also "chmod +x dateiname.exe" und dann "./dateiname.exe" (Ausführen wie jede gewöhnliche Linux-Executable) hat nach der Installation vom Original-M$-Framework (installiert gem. offiz. Installationsanleitung, aber ohne ASP.NET) irgendwie nicht mehr (wie bei mono(-complete)) geklappt.
Keine Ahnung, evtl. hab ich auch was übersehen, kann dann morgen noch mal schauen ob's auch damit irgendwie läuft. (?) Auch wenn die Dateien, welche man mit IKVM.NET generieren kann, kleiner sind als .NET v6.0 sind, so sollte v6.0, oder v5.0 (...) ja abwärtskompatibel sein. (Solange es nicht die "Core-Version" ist sollte es gehen würde ich sagen; denn dort ist ja einiges ganz anders. Die würde es in v3.1 geben für Debian...)
"das kannst du auch auf DOS zum laufen bringen oder windows 3.11"
ZU GEIL, made may day... 😁 DOS 5.0 hätte ich noch originalverpackt, 3 Disketten, aber die öffne ich nicht ;-) Win 3.11 könnte man sicher auch irgendwo herunterladen... dann das Zeugs unter VirtualBox zum laufen bringen. (Wenn das bei den heutigen 64Bit-CPUs überhaupt 16 Bit kann, sonst halt QEMU...)
FRAGE: Kenne jemand von euch ne Library, welche das PBKDF2WithHmacSHA512-Verfahren im Griff hat aber in KEINSTER WEISE (!!) von irgendwelchen Klassen java.xxx..., javax.www..., com.sun etc. pp. abhängig ist...?
Eigentlich schon, why not? Eigentlich mag ich ja solche "trockenen", mathematischen Sachen, Algorithmen - eher weniger Netzwerk- und GUI-Themen.
Habe nach dem Algorithmus geschaut, eine theor. Definition (aus der Sicht von Mathematikern oder theor. Informatikern) fand ich auf die Schnelle nicht. Und ganz ehrlich wär ich wohl ein wenig überfordert, diese korrekt zu interpretieren. (Mit all diesen Zeichen...)
Und ein Beispiel in einer anderen Sprache welche ich einigermassen verstehe (PHP, C#, C/C++ ... ) um das nach Java zu übersetzen fand ich ebenfalls nicht sofort.
Aber diese BountyCastle-Library ist ganz nett, die hat auch ne gute Kompatibilität (gibt versch. Jars zum Download) von Java 1.5 bis 1.8 und läuft damit - wie schon erwähnt - wohl gar mit Android problemlos...
Das dürfte gar nicht mal so schwer sein. Der Algorithmus von SHA-512 lässt sich quasi 1:1 aus RFC 6234 übernehmen, HMAC ist poplig (im Endeffekt XORen) und PBKDF2 (RFC 2898) scheint mir jetzt auch keinen riesigen Implementierungsaufwand darzustellen.
Eigentlich schon, why not? Eigentlich mag ich ja solche "trockenen", mathematischen Sachen, Algorithmen - eher weniger Netzwerk- und GUI-Themen.
Habe nach dem Algorithmus geschaut, eine theor. Definition (aus der Sicht von Mathematikern oder theor. Informatikern) fand ich auf die Schnelle nicht. Und ganz ehrlich wär ich wohl ein wenig überfordert, diese korrekt zu interpretieren. (Mit all diesen Zeichen...)
Und ein Beispiel in einer anderen Sprache welche ich einigermassen verstehe (PHP, C#, C/C++ ... ) um das nach Java zu übersetzen fand ich ebenfalls nicht auf die Schnelle.
Aber diese BountyCastle-Library ist ganz nett, die hat auch ne gute Kompatibilität (gibt versch. Jars zum Download) von Java 1.5 bis 1.8 und läuft damit - wie schon erwähnt - wohl gar mit Android problemlos...
