Autor: admin

Veröffentlicht am

PHP 7.0 verfügbar

Seit heute steht auf unseren Webservern die neue Version 7.0 von PHP zur Verfügung. Der Versionssprung von 5.6 auf 7 liegt daran, dass die Entwicklung von PHP 6 aus verschiedenen Gründen eingestellt wurde.

Vorteile von PHP 7

Die Hauptverbesserungen bei PHP 7 wurden an den internen Datenstrukturen vorgenommen, dort konnte der Speicherbedarf stark reduziert werden. Dies führt zu einer deutlichen Erhöhung der Ausführungsgeschwindigkeit von PHP-Scripten, in der Praxis laufen viele Anwendungen wie z.B. WordPress unter PHP 7.0 doppelt so schnell wie unter PHP 5.6, der Umstieg auf PHP 7 lohnt sich also.

Mögliche Probleme beim Wechsel auf PHP 7

Bei PHP 7 wurden einige bisher nur als veraltet markierte Extensions endgültig entfernt, darunter auch die häufig eingesetzte originale MySQL-Extension. Als Alternativen können die MySQL-Improved-Extension (MySQLi) oder PDO genutzt werden.

Weiterhin sind einige Begriffe wie int, float, bool, string, true, false und null nun reserviert und dürfen nicht mehr für Klassennamen oder Ähnliches genutzt werden, dies führt bei einigen PHP-Anwendungen wie beispielsweise Joomla zu Problemen.

Eine vollständige Übersicht der nicht abwärtskompatiblen Änderungen finden Sie hier.

Aufgrund dieser Änderungen sind viele bekannte PHP-Anwendungen nicht kompatibel mit PHP 7. Für die meisten betroffenen Anwendungen sollten jedoch in Kürze Updates erscheinen, die diese Probleme beheben. Die bei uns am häufigsten genutzte PHP-Anwendung WordPress ist in der aktuellen Version vollständig kompatibel mit PHP 7, es kann jedoch unter Umständen Probleme mit älteren WordPress-Plugins geben.

PHP 7 aktivieren

PHP 7 wird nicht automatisch für alle PHP-Scripte auf unseren Webservern genutzt, da bei einer Änderung der Standard-PHP-Version viele Webseiten nicht mehr korrekt funktionieren würden. Sie können jedoch die gewünschte PHP-Version für Ihre Webseiten über eine Konfigurationsdatei vorgeben, eine Anleitung dazu finden Sie hier.

Veröffentlicht am

Let’s Encrypt Zertifikate bei Variomedia

Ab dem 3. Dezember wird die Zertifizierungsstelle Let’s Encrypt kostenlose SSL-Zertifikate für Webserver ausstellen, die von sämtlichen Web-Browsern akzeptiert werden. Wir erhalten derzeit viele Anfragen von Kunden, ob wir diese ebenfalls unterstützen werden. Grundsätzlich planen wir, Let’s Encrypt Zertifikate anzubieten. Es gibt allerdings noch einige bisher ungelöste technische Probleme bei der Domain-Validierung durch Let’s Encrypt, so dass wir derzeit noch nicht genauer sagen können, wann und in welcher Form wir diese Zertifikate anbieten können.

Um ein SSL-Zertifikat zu erhalten, muss zuvor bei der Zertifizierungsstelle der Besitz der Domain nachgewiesen werden. Let’s Ecrypt nutzt hierzu einen Mechanismus, der eine Datei mit einem verschlüsselten Token per HTTP von der gewünschten Domain herunterlädt, die nur vom Inhaber der Domain angelegt werden kann. Alternativ kann auch eine Validierung mittels spezieller DNS-Einträge erfolgen, dieses Verfahren wird jedoch zum Start von Let’s Encrypt am 3. Dezember noch nicht unterstützt, sondern erst später nachgereicht.

Um den gesamten Vorgang zu automatisieren stellt Let’s Encypt eine eigene Software bereit, die jedoch auf unseren Webservern nicht funktioniert. Wir müssen daher das von Let’s Encrypt genutzte ACME-Protokoll selbst implementieren. Weiterhin gelten die Let’s Encrypt-Zertifikate nur 90 Tage, so dass wir auch eine automatische Verlängerung implementieren müssen. Eine automatisierte Validierung ist in unserem Webserver-Verwaltungssystem praktisch nur mittels DNS-Validierung umsetzbar, daher müssen wir noch warten, bis dies von Let’s Encrypt unterstützt wird.

Bitte beachten Sie, dass es bei uns grundsätzlich nicht möglich ist, selbst erstellte oder von regulären Zertifizierungsstellen direkt erworbene SSL-Zertifikate einzubinden, da wir ein automatisiertes System zur Verwaltung von SSL-Zerfikaten nutzen, das nicht mit Zertifikaten anderer Anbieter funktioniert.

Veröffentlicht am

Phusion Passenger für Ruby, Python und Node.js

Wir erhalten regelmäßig Anfragen, ob wir auch Hosting für Ruby on Rails, Python WSGI oder Node.js anbieten können. Daher planen wir, in unseren Pro-Paketen und auf Dedicated-Servern zukünftig auch Ruby Rack (z.B. Ruby on Rails, Sinatra), Python WSGI (z.B. Django, Flask, Pyramid) und Node.js mittels Phusion Passenger (als Apache-Modul) zu unterstützen. Passenger, auch als mod_rails bekannt, ist der Standard-Application-Server für Ruby on Rails, unterstützt jedoch auch andere Sprachen wie Python (WSGI) und Node.js.

Um eine Web-Anwendung mittels Passenger zu nutzen, muss sich diese an die typische Rack-Verzeichnisstuktur halten. Python- und Node.js-Anwendungen lassen sich sehr einfach anpassen:

  • Im Hauptverzeichnis der Web-Anwendung muss ein Unterverzeichnis “public” für statische HTML-Dateien, Bilder und CGI-Scripte angelegt werden.
  • Der Webserver-Pfad für die gewünschten Domains sollte auf dieses Verzeichnis zeigen.
  • Im Hauptverzeichnis der Web-Anwendung muss Passenger per .htaccess-Datei aktiviert und ein Startup-Script angelegt werden, dass die Anwendung lädt (z.B. config.ru, passenger_wsgi.py, app.js).
  • Wenn im Public-Verzeichnis keine Indexdatei (index.html, index.php, usw.) hinterlegt ist, wird die Anfrage vom Webserver an Passenger weitergeleitet.
  • Passenger lädt beim ersten Seitenaufruf das Startup-Script der Anwendung und leitet dann alle Anfragen an diese weiter.

Für interessierte Kunden bieten wir ab sofort eine kostenlose Testphase unserer Pro-Pakete an, bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Veröffentlicht am

Mögliche Probleme mit Apache 2.4.17 und mod_rewrite

Wir haben am 15.10. ein Update der Webserver-Software Apache von Version 2.4.16 auf 2.4.17 vorgenommen, dabei hat sich eine unerwartete Änderung im Modul mod_rewrite ergeben, die zu Problemen mit einigen PHP-Anwendungen (z.B. Concrete5) führen kann: Die Server-Variable “REDIRECT_URL” wurde von einer relativen URL (z.B. “/kapitel/2/”) auf eine vollständige URL (z.B. “http://www.domain.de/kapitel/2/”) umgestellt, daher könnten PHP-Scripte, die auf diese Variable zurückgreifen, unter Umständen nicht mehr korrekt funktionieren.

Falls Sie seit dem 15.10. Probleme mit Ihrer Webseite festgestellt haben, die zuvor nicht aufgetreten sind, wenden Sie sich bitte an unsere Kundenbetreuung.

Veröffentlicht am

Aktuelle Änderungen an unseren Anti-Spam-Regeln

Wir haben in den letzten Tagen einige Änderungen an unseren Mailservern vorgenommen, um die Zahl der nicht erkannten Spammails (False-Negatives) zu reduzieren. Zusätzlich zum bestehenden Spamfilter Expurgate nutzen wir nun DNS-basierte Blackhole-Listen (DNSBL) und werten SPF– (Sender Policy Framework), DKIM– (DomainKeys Identified Mail) sowie DMARC– (Domain-based Message Authentication, Reporting & Conformance) Einträge aus. Um fälschlicherweise als Spam klassifizierte E-Mails (False Positives) zu vermeiden, lehnen wir betroffene Mails nicht ab, sondern nutzen das Greylisting-Verfahren, um die Zustellung zu verzögern.

Was ist eine DNSBL?

Eine DNSBL ist eine laufend aktualisierte Liste verdächtiger IP-Adressen. Verdächtige IP-Adressen sind beispielsweise solche, über die kürzlich massenhaft Spam versendet wurde, oder dynamische IP-Adressen wie etwa von DSL-Anschlüssen von Privatkunden, die E-Mails ausschließlich über SMTP-Relays (z.B. smtp.variomedia.de) versenden sollten.

Was ist SPF?

Mittels SPF können Domaininhaber über spezielle DNS-Einträge festlegen, welche Mailserver E-Mails für diese Domain versenden dürfen.

Was ist DKIM?

Mittels einer DKIM-Signatur kann geprüft werden, ob eine E-Mail von der angegebenen Absenderadresse versendet und beim Transport nicht verändert wurde. Diese Signatur wird automatisch durch den Mail-Server des Absenders erzeugt.

Was ist DMARC?

DMARC nutzt eine Kombination aus SPF und DKIM, um zu prüfen, ob eine E-Mail von der angegebenen Absenderadresse versendet wurde. Weiterhin wird mittels DMARC festgelegt, ob E-Mails, die keine bzw. ungültige DKIM-Signaturen aufweisen oder die SPF-Regeln verletzen, abgelehnt oder angenommen werden sollen. Ähnlich wie bei SPF werden dazu spezielle DNS-Einträge genutzt, die vom Domaininhaber gesetzt werden können. DMARC wird von vielen bekannten Anbietern wie z.B. Google oder Facebook eingesetzt.

Was ist Greylisting?

Greylisting ist ein Verfahren zur Verzögerung der E-Mail-Zustellung. Verdächtige E-Mails werden dabei nicht sofort angenommen, sondern mit einem temporären Fehler abgelehnt, so dass der absendende Server später einen erneuten Zustellversuch unternimmt. Nach Ablauf der Verzögerung (meistens 5 Minuten) wird diese Mail dann angenommen. Erfolgt ein erneuter Zustellversuch, so wird der betroffene Mailserver permanent freigeschaltet, so dass weitere verdächtige E-Mails von diesem Server nicht mehr verzögert werden. Die Strategie dahinter ist, dass viele Spam-Programme keine erneuten Zustellversuche unternehmen und eine verzögerte E-Mail bei einer späteren Zustellung eventuell von unserem Spamfilter korrekt klassifiziert wird.

Wie funktionieren die neuen Anti-Spam-Regeln?

Falls die IP-Adresse des absendenden Servers auf einer DNSBL eingetragen ist, oder die SPF bzw. DMARC-Prüfung fehlschlägt, wird eine E-Mail gegreylistet (auch wenn die betroffene E-Mail nach SPF bzw. DMARC eigentlich abgelehnt werden sollte).
Eine Ausnahme sind E-Mails von PayPal (paypal.com, paypal.de), die bei fehlgeschlagener DMARC-Prüfung gemäß den Vorgaben von PayPal abgelehnt werden, da es sich mit sehr hoher Wahrscheinlichkeit um Phishing handelt.

Mögliche Probleme

Die SPF-Prüfung schlägt bei E-Mail-Weiterleitungen häufig fehl, da die weiterleitenden Server nicht zum Versenden vom E-Mails der Absenderdomain autorisiert sind. Eine Möglichkeit dieses Problem zu umgehen ist SRS (Sender Rewriting Scheme), das von uns und vielen anderen Anbietern für E-Mail-Weiterleitungen genutzt wird. Dabei wird die Absenderadresse anhand bestimmter Regeln umgeschrieben und die Absenderdomain durch die Empfänger-Domain des weiterleitenden Servers ersetzt.

Veröffentlicht am

PHP 7 RC 3 verfügbar

Ab sofort steht auf unseren Webservern der aktuelle Release Candidate 3 von PHP 7 zu Testzwecken zur Verfügung.

Wir haben dabei eine für viele Kunden interessante Neuerung hinzugefügt, und zwar einen Datei-basierten PHP-Beschleuniger.

Hintergründe zu PHP-Beschleunigern

PHP ist eine Script-Sprache, die vor der Ausführung auf unseren Webservern in für Computer verständlichen Mikroprozessor-Code übersetzt werden muss. PHP nutzt dabei (ähnlich wie Java) eine sogenannte Virtuelle Maschine, es wird also nicht direkt Mikroprozessor-Code erzeugt, sondern zunächst sogenannter Bytecode für eine Virtuelle Maschine (Zend Engine), die daraus dann im nächsten Schritt Mikroprozessor-Code erzeugt und diesen ausführt.
Dieser Bytecode wird jedoch nach der Ausführung eines PHP-Scripts verworfen, und muss jedes Mal zeitaufwändig neu generiert werden. Um dies zu vermeiden gibt es diverse PHP-Beschleuniger wie den PHP-eigenen OpCache, die den Bytecode für spätere Script-Aufrufe optimieren und zwischenspeichern. Allerdings wurde dieser Bytecode bisher immer im Arbeitsspeicher abgelegt, was auf unseren Shared-Hosting-Servern aus technischen Gründen nicht funktioniert, und nur in den Pro-Paketen (bzw. auf Dedicated-Servern) mit PHP-FPM möglich ist.

Seit PHP 7 kann der PHP OpCache den Bytecode optional auch in Dateien speichern, damit lässt er sich auf allen Shared-Hosting-Servern nutzen.

Wir haben anhand einer aktuellen WordPress-Installation die möglichen Performance-Verbesserungen durch OpCache getestet (Mittelwert über 100 Aufrufe):

opcache-file-small

Im Vergleich zu PHP 5.6 ohne OpCache verkürzt sich die PHP-Ausführungszeit für die WordPress-Startseite um Faktor 2, der Datei-OpCache lohnt sich also wirklich.

PHP 7 und OpCache aktivieren

Um PHP 7 mit OpCache zu nutzen, erstellen Sie zunächst ein Verzeichnis für die Bytecode-Dateien auf Ihrem Webserver. Dieses Verzeichnis können Sie beliebig benennen (z.B. “opcache”), und an beliebiger Stelle in Ihrem Benutzerverzeichnis anlegen, die Zugriffsrechte sollten jedoch aus Sicherheitsgründen auf Ihren Benutzeraccount beschränkt werden (chmod 700).

Legen Sie dann im gewünschten Webserver-Verzeichnis eine .htaccess-Datei mit folgendem Inhalt an (bzw. fügen Sie folgende Zeile zu einer bestehenden .htaccess-Datei hinzu):

AddHandler application/x-httpd-php70 .php

Anschließend legen Sie in diesem Verzeichnis eine php.ini-Datei mit folgendem Inhalt an (bzw. fügen die folgenden Zeilen zu einer bestehenden php.ini-Datei hinzu):

zend_extension=/vrmd/webserver/php70/lib/opcache.so
opcache.file_cache=/homepages/u12345/opcache
opcache.file_cache_only=1

Ersetzen Sie dabei “/homepages/u12345/opcache” durch den vollständigen Pfad zu Ihrem Bytecode-Verzeichnis. Beachten Sie bitte, dass php.ini-Dateien nur in dem Verzeichnis gelten, wo auch das aufgerufene PHP-Script liegt, eventuell müssen Sie diese Datei daher noch in weitere Unterverzeichnisse kopieren.

Hinweis

Bitte beachten Sie, dass sich PHP 7 noch in der Entwicklungsphase befindet, es können noch diverse kleinere Fehler und Probleme auftreten. Sie sollten PHP 7 daher besser noch nicht für kritische Webseiten einsetzen.

Veröffentlicht am

PHP 7 im Performance-Vergleich

Die PHP-Entwickler haben für Version 7 drastische Performance-Verbesserungen um 100% und mehr im Vergleich zu den Vorgängerversionen angekündigt. Um dies zu überprüfen, haben wir die PHP-Ladezeiten einer aktuellen WordPress-Installation (Version 4.3) mit den unterschiedlichen bei uns verfügbaren PHP-Versionen gemessen (Mittelwert über 100 Zugriffe):

barchart

Tatsächlich ist PHP 7 deutlich schneller als die Vorgängerversionen, die angekündigte Verbesserung um 100% tritt unter PHP-FPM in Kombination mit dem PHP Opcode Cache tatsächlich ein.

Weitere Informationen zur Nutzung von PHP 7 auf unseren Webservern finden Sie hier.

Bitte beachten Sie, dass PHP-FPM  gegenwärtig nur in den Pro-Paketen bzw. für Reseller mit Dedicated-Server genutzt werden kann, zur Aktivierung von PHP-FPM wenden Sie sich bitte an unsere Kundenbetreuung.

Veröffentlicht am

PHP 7 RC 1 verfügbar

Auf unseren Webservern steht ab sofort der Release Candidate 1 von PHP 7 zu Evaluierungszwecken zur Verfügung.

Bitte beachten Sie, dass es sich noch nicht um die endgültige Release-Version handelt, die voraussichtlich gegen Mitte November erscheinen wird, es können also noch diverse kleinere Fehler und Probleme auftreten. Wir empfehlen daher, PHP 7 noch nicht für den Produktivbetrieb kritischer Webseiten zu nutzen, Sie können jedoch schon prüfen, ob Ihre Webseite mit PHP 7 kompatibel ist, und so rechtzeitig den Umstieg auf die neueste PHP-Version vorbereiten. Beim Umstieg auf PHP 7 ist insbesondere zu beachten, dass einige veraltete Funktionen, die unter PHP 5.6 noch funktioniert haben, unter PHP 7 nicht mehr zur Verfügung stehen.

Um PHP 7 für Ihre Webseite zu nutzen, erstellen Sie im gewünschten Webspace-Verzeichnis eine .htaccess-Datei mit folgendem Inhalt (bzw. fügen Sie folgende Zeile zu einer bestehenden .htaccess-Datei hinzu):

AddHandler application/x-httpd-php70 .php

Wir werden auch die nächsten Release Candidates von PHP 7 zeitnah auf unseren Webservern bereitstellen, bis hin zur Veröffentlichung der endültigen Release-Version von PHP 7.

Mit den Apache-Handler application/x-httpd-php70 kann zukünftig die aktuellste Version von PHP 7.0 auf unseren Webservern genutzt werden.

An der bisherigen Standard-PHP-Version des von Ihnen genutzen Webservers ändert sich nichts, für neue Präsenzen wird aktuell standardmäßig PHP 5.5 genutzt, ältere Webserver nutzen PHP 5.3.

Weitere Informationen zur Auswahl der PHP-Version finden Sie hier.

Veröffentlicht am

Probleme bei der Einrichtung von E-Mail-Konten unter Thunderbird

Beim beliebten E-Mail-Client Thunderbird gibt es einen seit mehreren Jahren unbehobenen Bug bei der Erkennung der SMTP-Server-Einstellungen, der für Probleme bei der Einrichtung von E-Mail-Konten sorgt.

Das SMTP-Protokoll wird zum Versenden von E-Mails genutzt. Thunderbird nutzt für SMTP standardmäßig den TCP-Port 587, für den wir auf unseren SMTP-Servern (optional) Verschlüsselung mittels StartTLS anbieten. Bei der automatischen Erkennung der Server-Einstellungen versucht Thunderbird zunächst eine verschlüsselte Verbindung mittels StartTLS aufzubauen. Wenn dies fehlschlägt, wird eine unverschlüsselte Verbindung genutzt.

Leider hält sich Thunderbird bei der Erkennung der SMTP-Server-Einstellungen nicht genau an das SMTP-Protokoll, so dass unser Mail-Server beim Verbindungsaufbau mittels StartTLS eine Fehlermeldung zurückliefert, und Thunderbird dann automatisch eine unverschlüsselte Verbindung wählt:

smtp_500

In aktuellen Thunderbird-Versionen wird dann im nächsten Schritt eine Warnung angezeigt, dass keine Verschlüsselung genutzt wird, obwohl unsere Server sehr wohl Verschlüsselung unterstützen:

tb-fehler-500

Wählen Sie in diesem Fall für den SMTP-Server entweder unter Port 465 und unter SSL SSL/TLS und klicken dann auf “Erneut testen”, dann sollte die automatische Erkennung sofort funktionieren und Sie können “Fertig” auswählen.

Alternativ können Sie unter Port 587 und unter SSL StartTLS wählen und dann “Erneut testen” klicken. Meistens schlägt der Verbindungstest dann jedoch erneut fehl, und Thunderbird meldet einen Fehler. In diesem Fall sollten sie so lange auf “Erneut testen” klicken, bis es irgendwann klappt. Dies erfordert normalerweise mehrere Versuche, doch irgendwann funktioniert es und Sie können “Fertig” auswählen.

Veröffentlicht am

TLS-Sicherheitsproblem “Logjam”

Vor einigen Tagen wurde unter dem Namen Logjam ein mögliches Sicherheitsproblem mit der TLS-Verschlüsselung bekannt, die zur Verschlüsselung von Webseiten (HTTPS) und E-Mails (POP3, IMAP, SMTP) genutzt wird. Ein Angreifer kann unter bestimmten Umständen den Diffie–Hellman-Schlüsselaustausch zwischen Client und Server so manipulieren, dass nur schwache 512 Bit Parameter genutzt werden, die nach aktuellem Stand nicht mehr als sicher gelten. Dieser Angriff ist auf unseren Servern jedoch nicht möglich, da wir keine so kurzen Diffie-Hellman-Paramter unterstützen.

Wir haben uns im Rahmen des Logjam-Sicherheitsproblems dazu entschieden, wenn möglich nur noch als extrem sichere geltende 4096 Bit Diffie-Hellman-Parameter zu nutzen. Die meisten unserer Server nutzten bereits vor Bekanntwerden dieses Sicherheitsproblems 4096 Bit Parameter, auf einigen Servern wurden jedoch noch kürzere 1024 Bit Parameter genutzt, die von machen Sicherheitsexperten als bereits problematisch kurz eingestuft werden. Seit dem 22.05. nutzen alle Server (bis auf eine Ausnahme) 4096 Bit Parameter, dadurch kann es jetzt jedoch bei einigen veralteten Programmen zu Verbindungsproblemen kommen.

Einzige Ausnahme bilden die Mail-Server, wir mussten bei POP3 und IMAP aufgrund von Problemen mit älteren Mail-Clients wieder auf 1024 Bit Diffie-Hellman-Parameter zurückwechseln. Aktuelle Mail-Clients nutzten jedoch im Regelfall ohnehin das modernere Elliptic-Curve-Diffie-Hellman, das mit kürzeren Parametern und weniger Rechenleistung auskommt.

Die technischen Hintergründe

Die TLS-Verschlüsselung nutzt eine Kombination aus asymmetrischer Verschlüsselung zum Schlüsselaustausch und symmetrischer Verschlüsselung zur eigentlichen Verschlüsselung der Daten. Mittels asymmetrischer Verschlüsselung wird ein zufälliger geheimer Schlüssel vom Client an den Server übertragen, der nur vom Server wieder entschlüsselt werden kann. Da die asymmetrische Verschlüsselung sehr aufwändige kryptographische Algorithmen nutzt, kann sie aus Performance-Gründen nicht zur eigentlichen Verschlüsselung der Daten eingesetzt werden, hierfür werden wesentliche effizientere symmetrische Verschlüsselungsalgorithmen genutzt.

Der TLS-Standard sieht mehrere Verfahren zum Schlüsselaustausch und zur Verschlüsselung vor, einige davon sind jedoch mittlerweile veraltet und gelten als unsicher. Unsere Server sind daher so konfiguriert, dass nur nach aktuellem Stand sichere Verfahren genutzt werden können.

Die gegenwärtig sichersten Verfahren zum Schlüsselaustausch sind Diffie-Hellman (DHE) sowie Elliptic-Curve-Diffie–Hellman (ECDHE). Bei beiden Verfahren wird zwischen Client und Server für jede Verbindung ein individueller Schlüssel generiert (Perfect Forward Secrecy). Weiterhin wird für ältere Clients noch das RSA-Verfahren unterstützt, bei dem der Schlüsselaustausch mit dem RSA-Schlüssel aus dem X.509-Zertifikat des Servers gesichert wird. Dieses Verfahren hat jedoch den Nachteil, dass ein Angreifer mit Kenntnis des geheimen Server-Schlüssels alle Verbindungen entschlüsseln kann. ECDHE und DHE werden daher bevorzugt, RSA wird nur genutzt, wenn ein Client kein Diffie-Hellman unterstützt.

Bei DHE und ECDHE sendet der Server bestimmte Parameter an den Client, die in einem komplexen Algorithmus zur Berechnung der Verschlüsselung genutzt werden. Die Länge dieser Parameter entscheidet über die Sicherheit der Verschlüsselung. Bei DHE ist die minimal zulässige Länge 512 Bit, dies gilt jedoch seit längerer Zeit als nicht mehr als ausreichend sicher. Auch 1024 Bit Parameter gelten mittlerweile als problematisch, es werden mindestens 2048 Bit empfohlen.