expertenaustausch > comp.* > comp.security.misc

Marc Haber (11.08.2017, 12:07)
Hallo,

wenn ich aufgrund hardwaremäßiger Beschränkungen der verwendeten
Smartcard die Wahl habe zwischen RSA2048 oder ECC P-384, welches
Verfahren nehme ich?

ECC P-384 ist aus der NIST-Suite, für die man vermutete, dass die NSA
enie Hintertür besitzen könnte, während RSA2048 nach der Argumentation
vieler Menschen überholt ist und ersetzt gehört. Andererseits
argumentieren auch manche Entitäten, darunter das BSI und ein
bekannter Smartcard-Hersteller, dass RSA2048 noch einige Jahre als
"sicher" angesehen werden kann, besonders wenn der private Key
unauslesbar auf einer Smartcard gespeichert ist und diese kein
unbegrenzt langes Leben haben dürfte.

Dann müsse man nur noch aufpassen, den public Key zu dem auf der Karte
gespeicherten Key nach Außerbetriebnahme der Smartcard auch konsequent
überall zu entfernen, denn bruteforcen kann man ihn ja auch, wenn er
die Karte nie verlassen hat.

Wie ist denn die fundierte Meinung der hier anwesenden Experten?

Grüße
Marc
Volker Delf (11.08.2017, 17:51)
Hallo,

Marc Haber schrieb:
>wenn ich aufgrund hardwaremäßiger Beschränkungen der verwendeten
>Smartcard die Wahl habe zwischen RSA2048 oder ECC P-384, welches
>Verfahren nehme ich?

Naja, wenn du das asymmetrische Schlüsselpaar RSA2048 V3 mit der PGP
Version 2.6.3i auf einem 486DX2 16-bit Prozessor aus dem Jahre 1996
erzeugst, dürfte dieser von NIST/NSA noch nicht kompromittiert sein.

Siehe alt.security.pgp "Generating GPG keys on ancient laptop"

Ob damit deine Smartcard zurecht kommt, kann ich nicht sagen. Vermutlich
benötigt sie RSA2048 V4.

mfg Volker
Marc Haber (11.08.2017, 21:17)
Volker Delf <nopost> wrote:
>Marc Haber schrieb:
>Naja, wenn du das asymmetrische Schlüsselpaar RSA2048 V3 mit der PGP
>Version 2.6.3i auf einem 486DX2 16-bit Prozessor aus dem Jahre 1996
>erzeugst, dürfte dieser von NIST/NSA noch nicht kompromittiert sein.
>Siehe alt.security.pgp "Generating GPG keys on ancient laptop"
>Ob damit deine Smartcard zurecht kommt, kann ich nicht sagen. Vermutlich
>benötigt sie RSA2048 V4.


Also wenn schon dann wird der Schlüssel auf der Smartcard erzeugt.
Hast Du auch eine ernstgemeinte Antwort?
Sven Hartge (11.08.2017, 21:39)
Marc Haber <mh+usenetspam1118> wrote:

> wenn ich aufgrund hardwaremäßiger Beschränkungen der verwendeten
> Smartcard die Wahl habe zwischen RSA2048 oder ECC P-384, welches
> Verfahren nehme ich?


Ich habe keine Erfahrungen mit Schlüsseln/Verschlüsselung via
Smartcard/Token, aber eine allgemeine Frage bei der Wahl des Verfahren
habe ich:

Wie kompatibel ist die Eliptic Curve Variante in der realen Welt? Kommt
jeder (Gerät wie Mensch) mit den so erzeugten Signaturen klar?

Volker Delf (12.08.2017, 13:43)
Hallo,

Marc Haber schrieb:
>Also wenn schon dann wird der Schlüssel auf der Smartcard erzeugt.
>Hast Du auch eine ernstgemeinte Antwort?


Dann musst du eben den Krypto-Routinen auf der SmartCard dein vollstes
Vertrauen schenken.

mfg Volker
Michael Bäuerle (12.08.2017, 15:33)
Marc Haber wrote:
> [...] während RSA2048 nach der Argumentation
> vieler Menschen überholt ist und ersetzt gehört. Andererseits
> argumentieren auch manche Entitäten, darunter das BSI und ein
> bekannter Smartcard-Hersteller, dass RSA2048 noch einige Jahre als
> "sicher" angesehen werden kann,


Das NIST sieht das wohl auch so: <https://www.keylength.com/en/4/>
(dort ist ein Zeitraum bis 2030 angegeben)
David Seppi (12.08.2017, 16:53)
Sven Hartge schrieb:

> Wie kompatibel ist die Eliptic Curve Variante in der realen Welt?


openssl 1.0.1t kann damit nicht umgehen und iat die Version, die auf
Debian Jessie (oldstable) oben ist.
Marc Haber (12.08.2017, 19:51)
Volker Delf <nopost> wrote:
>Marc Haber schrieb:
>>Also wenn schon dann wird der Schlüssel auf der Smartcard erzeugt.
>>Hast Du auch eine ernstgemeinte Antwort?

>Dann musst du eben den Krypto-Routinen auf der SmartCard dein vollstes
>Vertrauen schenken.


Hast Du auch eine Antwort auf meine Frage?
Ähnliche Themen