Eine Neuerung in .NET 10.0 ist die Methode ExportPkcs12() zum Zertifikatsexport mit AES-Verschlüsselung und Hashing via SHA-2-256:

byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);

Die bisherige Methode Export() verwendet noch veraltete Algorithmen (3DES-Verschlüsselung und SHA1-Hashing). Die alten Verfahren (3DES / SHA1) aus Export() sind allerdings ebenfalls über die neue Methode möglich, wenn man es wirklich will:

byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);

Folgender Code zeigt ein Beispiel zum Erstellen und Exportieren eines Zertifikats:

public void Run()
{
 CUI.Demo(nameof(FCL10_Certificates));
 
 string certPath = @"c:\temp\meinZertifikat.pfx";
 string password = "meinSehrGeheimesPasswort"; // Passwort zum Schutz des Zertifikats
 
 // Selbstsigniertes Zertifikat erstellen
 using (var rsa = RSA.Create(2048))
 {
  var request = new CertificateRequest(
      "CN=TestZertifikat",
      rsa,
      HashAlgorithmName.SHA256,
      RSASignaturePadding.Pkcs1);
 
  // Zertifikat für 1 Jahr gültig machen
  var cert = request.CreateSelfSigned(
      DateTimeOffset.Now,
      DateTimeOffset.Now.AddYears(1));
 
  // ALT: Zertifikat mit 3DES-Verschlüsselung und SHA1-Hashing exportieren
  // byte[] pfxData = cert.Export(X509ContentType.Pkcs12, password);
 
  // NEU: Zertifikat als AES mit SHA-2-256 exportieren
  byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);
 
  // NEUE Methode, aber alte Sicherheitsverfahren: 3DES mit SHA-1
  // byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);
 
  // PFX-Datei speichern
  File.WriteAllBytes(certPath, pfxData);
 
  Console.WriteLine($"Test-Zertifikat erstellt und gespeichert unter: {certPath}");
 }
 
 if (!File.Exists(certPath))
 {
  Console.WriteLine($"Datei nicht gefunden: {certPath}");
 }
 else
 {
  // Zertifikat laden
  X509Certificate2 cert2 = X509CertificateLoader.LoadPkcs12FromFile(certPath, password);
  Console.WriteLine($"Zertifikat geladen von {certPath}:");
  Console.WriteLine($"IssuerName: {cert2.IssuerName.Name}");
  Console.WriteLine($"Signaturalgorithmus (Hashing): {cert2.SignatureAlgorithm.FriendlyName}");
  Console.WriteLine($"Öffentlicher Schlüsselalgorithmus: {cert2.PublicKey.Oid.FriendlyName}");
  Console.WriteLine($"Key-Algorithmus OID: {cert2.GetKeyAlgorithm()}");
  // Ob für ein Zertifikat-Export (z. B. .pfx/PKCS#12) AES verwendet wurde, steht nicht im Zertifikat selbst, sondern betrifft die Verschlüsselung der Containerdatei. Das Zertifikat enthält nur Infos zu Signatur- und Schlüsselalgorithmus (z. B. RSA, SHA256).
 }
}

(rme)

Aufnahmen von Jupiter sind keine Seltenheit. Sowohl Amateur- als auch Profi-Astronomen haben in der Vergangenheit schon unzählige beeindruckende Fotos von dem Planeten gemacht. Trotzdem ist es dem Musiker und Retro-Tech-Fan Chris Graue Ende Juni gelungen, mit seiner Aufnahme für Aufsehen zu sorgen: Er hat den größten Planeten unseres Sonnensystems nämlich nicht etwa mit einer High-Tech-Kamera fotografiert – sondern mit einem Gameboy. In einem Video hat er jetzt detailliert erklärt, wie ihm das gelungen ist.

Kreatives Projekt sorgt für Aufmerksamkeit

Der Gameboy war lange Zeit die meistverkaufte Handheld-Konsole der Welt. In den 1990er-Jahren ging das Gerät von Nintendo millionenfach über die Ladentheke – und gilt bis heute als Kultobjekt. Im Jahr 1998 kam eine Kamera als Zubehör auf den Markt, die das Gerät um Fotografie-Funktionen erweiterte – allerdings mit stark eingeschränkten Möglichkeiten. Mit einer Auflösung von gerade einmal 0,014 Megapixeln war sie lediglich in der Lage, winzige Bilder in vier Graustufen zu erzeugen. Obwohl die Produktion schon 2002 wieder eingestellt wurde, hatte die Kamera laut Popular Science viele Fans.

Im Rahmen seines Astrofotografieprojekts hat Graue der Gameboy-Kamera jetzt ein Comeback verschafft. Da deren Reichweite allein aber bei Weitem nicht ausreicht, um Himmelskörper zu fotografieren, waren einige Anpassungen nötig. Zusammen mit einigen Freunden schloss er die Kamera mithilfe eines 3D-gedruckten Adapters an das Hooker-Teleskops am Mount-Wilson-Observatorium im US-Bundesstaat Kalifornien an. Technisch gesehen fotografierte die Kamera somit durch ein 730.000-Millimeter-Objektiv.

Gameboy-Adapter zum Nachdrucken

Zunächst versuchte Graue, Aufnahmen vom Mond zu machen. Er stellte allerdings fest, dass dieser für das extrem leistungsstarke Teleskop schlicht zu nah war. Mit einer durchschnittlichen Entfernung von rund 444 Millionen Meilen zur Erde erwies sich Jupiter dagegen als deutlich geeigneteres Motiv. Ohne Kontext sind die Aufnahmen kaum zu erkennen, trotzdem gelang es Graue, Jupiters Wolkenstreifen und den Rand des Planeten festzuhalten – für ihn zweifellos ein erfolgreiches Experiment. „Die Antwort lautet ja – wenn man sich nur genug ins Zeug legt, kann man auch mit seiner Gameboy-Kamera ein Foto von Jupiter machen”, erklärte er in einem Video auf Social Media.

Wie Engadget berichtet, hat Graue die Baupläne für den Adapter jetzt kostenlos veröffentlicht, damit sich alle Gameboy-Fans eine eigene Version mit einem 3D-Drucker ausdrucken können. Ergänzend dazu hat er ein kurzes Tutorial-Video veröffentlicht, in dem er die Nutzung erklärt. Er beschreibt den Adapter als „ein Rohr, das sich unter Druck in ein handelsübliches 1,25-Zoll-Okular für Teleskope einpassen lässt”. Es müssen aber nicht direkt Aufnahmen von Planeten sein, denn der Adapter könne auch ohne Teleskop genutzt werden. Laut Graue ist es möglich, andere Objektive mit dem Gameboy zu verbinden, die eine bessere Bildqualität bieten als die originale Nintendo-Kamera.

Dieser Beitrag ist zuerst auf t3n.de erschienen.

(jle)

Dokumentation mit KI zu prüfen, indem man menschliche Verhaltensweisen simuliert: Das ist der Ansatz, den Ingo Eichhorst mitgebracht hat. Mit ihm spricht Richard Seidl darüber, wie sich Personas wie ein Junior-Entwickler oder ein Senior-Entwickler als KI-Agenten in eine CI/CD-Pipeline einbauen lassen, um Dokumentation nicht nur zu bewerten, sondern aktiv damit zu arbeiten. Der Junior-Entwickler verbraucht dabei fast sechsmal so viele Token wie der Senior, weil er an einer missverständlichen URL-Struktur scheitert und sich im Trial-and-Error verliert. Das zeigt direkt, wo man Dokumentation nachbessern muss. Die beiden reden auch darüber, warum das Domänenwissen hinter Code so schwer zu rekonstruieren ist, sobald es einmal verloren ist, und was passiert, wenn eine KI plötzlich zwischen Entwicklern und Management als Übersetzungsschicht wirkt.

„Wir müssen uns von dem Gedanken verabschieden, dass wir immer so einen 100-Prozent-Output bekommen.“ – Ingo Eichhorst

Ingo Eichhorst ist AI Architect, CTO und Tech Trainer mit über zwei Jahrzehnten Erfahrung in Softwareentwicklung und Systemarchitektur. Seit den 1990er-Jahren gestaltet er digitale Systeme und verbindet dabei technologische Exzellenz mit unternehmerischem Denken. Bei Ionos arbeitet er als Engineering Trainer, parallel lehrt er als Visiting Lecturer für Künstliche Intelligenz an der University of Applied Sciences Nordhausen. Nebenberuflich begleitet er mit seinem Unternehmen better be great Start-ups, Scale-ups und NGOs bei der Umsetzung innovativer Technologien in marktfähige Produkte.

Softwarequalität im Gespräch

Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.

Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar.

(mai)