Windows Crypto API
Stefan Machwirth
Ich muss entscheiden, ob die Windows Crypto API sicher genug ist, um
sie in einem unsicheren Netzwerk zum Crypten von Nutzdaten
einzusetzen. Ich habe jetzt 3 Wochen zum Angreifen Zeit.
Gab es bereits erfolgreiche Contests damit? Sind irgendwelche Lecks
bekannt, oder gibt es erfolgversprechende Ansaetze von
Brute-Force-Methoden?
Gruss,
Steve
Debeka Koblenz
Abt. DV/D
Felix von Leitner
> Ich muss entscheiden, ob die Windows Crypto API sicher genug ist, um
> sie in einem unsicheren Netzwerk zum Crypten von Nutzdaten
> einzusetzen. Ich habe jetzt 3 Wochen zum Angreifen Zeit.
Das meinst du nicht ernst, oder?
Da steht "Windows" drauf und du sollst die Qualität begutachten, und du
mußt noch jemanden dazu fragen?!
Frage mal Altavista dazu.
Sicherheit bietet das API schon deshalb nicht, weil es ein US-Export
ist.
Felix
Sebastian Rittau
[Sicherheit des Windows-API]
>Sicherheit bietet das API schon deshalb nicht, weil es ein US-Export
>ist.
Zumal man sich fragen muss, inwieweit ein API Sicherheit bieten
kann. Ich meine, eine Implementation kann das (oder auch nicht),
aber ein API?
- Sebastian
Christian Mainka
chrille
www.chrille.de
Stefan Machwirth
<usenet-...@fefe.de> wrote:
>Stefan Machwirth <debek...@t-online.de> wrote:
>> Ich muss entscheiden, ob die Windows Crypto API sicher genug ist, um
>> sie in einem unsicheren Netzwerk zum Crypten von Nutzdaten
>> einzusetzen. Ich habe jetzt 3 Wochen zum Angreifen Zeit.
>
>Das meinst du nicht ernst, oder?
Natuerlich meine ich das ernst, sonst wuerde ich das hier nicht
posten.
>Da steht "Windows" drauf und du sollst die Qualität begutachten, und du
>mußt noch jemanden dazu fragen?!
Dass Windows Muell ist, brauchst du keinem zu erzaehlen. Aber damit
muss ich nun mal leben, da die Entscheidung nicht von mir getroffen
wurde.
>Sicherheit bietet das API schon deshalb nicht, weil es ein US-Export
>ist.
Das spielt keine Rolle. Auch die US-Version bietet in Wirklichkeit nur
40 Bit, da 88 Bit der NSA bekannt sind. Meine Frage ist auch eher,
diejenige, ob es bestimmte Luecken ausser einem Brute-Force-Angriff
gibt, die einen Hack der Daten sehr leicht machen (bzw. fertige Tools,
die es auch einem Laien erlauben). Bestimmte Risiken im leichtfertigen
Umgang M$'s mit den Key-Containern und PKCS#12 haben wir mittlerweile
schon entdeckt und wissen sie zu meiden.
Aber da du so sicher bist, werde ich dir per EMail ein kurzes
Text-File zuschicken - in der Form, in der wir es ueber den Draht
jagen wollen. Pure Hetze ueber ein mangelhaftes Betriebssystem koennen
wir uns sparen, das bringt uns nicht weiter. Jetzt muessen Taten
folgen :-)
Gruss,
Stefan
Debeka Koblenz
Abt. DV/D
Stefan Machwirth
<sri...@jroger.in-berlin.de> wrote:
>Zumal man sich fragen muss, inwieweit ein API Sicherheit bieten
>kann. Ich meine, eine Implementation kann das (oder auch nicht),
>aber ein API?
Ich denke, ihr wisst schon, wie ich das meine. Moechtest du auch ein
kurzes Textfile zum Decodieren bekommen? Ich bin mir mittlerweile
ziemlich sicher, dass wir alle Unzulaenglichkeiten von M$ durch
gewisse Vorkehrungen bezueglich der Schluesselsicherheit (die bei
Windows wirklich mangelhaft ist) beseitigt haben. Uebrig bleibt eine
(zugegebenermassen schwache 40-Bit-Verschluesselung), deren
Brute-Force-Aufwand in Zeit zu berechnen ist. Das koennen wir auch
selbst. Dahinter steckt aber schon ein kleiner Aufwand, der von den
Leuten, die sich fuer unsere Daten interessieren koennten, wohl nicht
zu erwarten ist. Computer-Cracks koennen mit unseren Daten eh nix
anfangen, denn man wird nicht reich dadurch und kann sie nicht
verkaufen. Fatal - und das wollten wir eben herausfinden - waere nur
eine andere Luecke, die es auch 08/15-DAUs durch im Internet besorgte
Tools erlaubt, ohne viel Wissen die Daten zu codieren.
Ach, ich schick dir auch mal einen codierten Text-Einzeiler. Dann
kannst du mir ja sagen, wie lange du gebraucht hast :-)
Stefan Machwirth
<chr...@chrille.de> wrote:
>.... jedes fenster kann man öffnen .....
Das ist eine unglaublich qualifizierte Aussage, die mich wahnsinnig
viel weiterbringt. Polemische Hetze ueber miserable Betriebssysteme
ist mehr als kindisch. Da ich meine Entscheidungen ueber solche Dinge
hier nicht alleine treffe und der Markt ab einer gewissen
Groessenordnung ein Woertchen mitredet, koennen wir dieses Thema nun
mal lassen. Wir alle wissen um die Qualitaeten von Windoof, aber wir
wissen genauso, dass wir uns dieses System dadurch nicht einfach vom
Hals wuenschen koennen.
Wieviele Fenster hast du denn schoen "geoeffnet"? Da du offenbar ein
Mensch mit sehr viel Erfahrung auf diesem Segment bist, schicke ich
dir auch ein codiertes Textfile zu. Mal gucken, wer von euch am
schnellsten ist :-)
Viele Gruesse,
Raphael Becker
> Da ich meine Entscheidungen ueber solche Dinge hier nicht alleine treffe und
> der Markt ab einer gewissen Groessenordnung ein Woertchen mitredet, koennen
Freßt mehr Scheiße, tausend Fliegen tun´s auch!
Gruß
Raphael Becker
Stefan Machwirth
<beck...@rumms.uni-mannheim.de> wrote:
>> Da ich meine Entscheidungen ueber solche Dinge hier nicht alleine treffe und
>> der Markt ab einer gewissen Groessenordnung ein Woertchen mitredet, koennen
>
>Freßt mehr Scheiße, tausend Fliegen tun´s auch!
Das ist genau diese Art von Mail, die ich hasse. Aber irgendwie hab
ich bisher in dieser Newsgroup nur so einen Bloedsinn bekommen.
Verdammt nochmal, was soll das? Ich hab mir meinen Beruf selbst
ausgesucht, und wenn ich Projektauftraege fuer Windows bekomme, kann
ich das System 100x verfluchen, aber der Auftrag wird trotzdem
durchgefuehrt! Platte Antworten kann man hier leicht plazieren, wenn
man in der Uni oder im privaten Kaemmerlein sitzt und sich akademisch
mit Betriebssystemen und Software auseinandersetzt. Willkommen im
Leben, ich verdiene mir nun mal damit mein Geld *und* bin Freak
nebenbei. Deinen oben genannten Spruch haettest du sicher auch keinem
Arbeit- oder Auftraggeber erwiedert, oder?
Irgendwie hab ich gedacht, dass ich hier in dieser Newsgroup ernsthaft
darueber diskutieren koennte, aber es scheinen sich wirklich nur
Kinder und Labertaschen hier rumzutreiben in der Hoffnung, ab und zu
mal einen billigen Shareware-Crack abzusahnen :-(((
Tschoe.
Debeka Koblenz
Abt. DV/D
Michael Sohmen
...
: Aber da du so sicher bist, werde ich dir per EMail ein kurzes
: Text-File zuschicken - in der Form, in der wir es ueber den Draht
: jagen wollen. Pure Hetze ueber ein mangelhaftes Betriebssystem koennen
: wir uns sparen, das bringt uns nicht weiter. Jetzt muessen Taten
: folgen :-)
Ich dachte, du wolltest die Sicherheit des Protokolls ueberpruefen ?
Wird eine Anwendung Groupware mit sicherer Datenuebertragung entwickelt ?
Sonst sollte man IMHO besser auf IP-Ebene gehen und darauf alles
verschluesseln statt auf Anwendungsebene.
Ich habe mal nach Analyse zu MS-Krypto API gesucht, scheint aber
so neu zu sein, dass dies noch keiner analysiert hat.
Zur Methode gibt's nur die Beschreibung bei RSA.
Michael
Lutz Donnerhacke
>On Thu, 24 Jun 1999 09:55:13 +0200, Raphael Becker
><beck...@rumms.uni-mannheim.de> wrote:
>
>>> Da ich meine Entscheidungen ueber solche Dinge hier nicht alleine treffe und
>>> der Markt ab einer gewissen Groessenordnung ein Woertchen mitredet, koennen
>>
>>Freßt mehr Scheiße, tausend Fliegen tun´s auch!
>
>Das ist genau diese Art von Mail, die ich hasse. Aber irgendwie hab
>ich bisher in dieser Newsgroup nur so einen Bloedsinn bekommen.
Geh. Geh weit.
>Verdammt nochmal, was soll das?
Willkommen im Usenet.
>Ich hab mir meinen Beruf selbst
>ausgesucht, und wenn ich Projektauftraege fuer Windows bekomme, kann
>ich das System 100x verfluchen, aber der Auftrag wird trotzdem
>durchgefuehrt!
Ja, wenn man keine Argumente hat, den Kunden zu eine Lösung zu führen, muß
man die Vorgaben des Kunden umsetzen, auch wenn man nicht merkt, daß man
Mist baut.
>Platte Antworten kann man hier leicht plazieren, wenn
>man in der Uni oder im privaten Kaemmerlein sitzt und sich akademisch
>mit Betriebssystemen und Software auseinandersetzt.
Ich sage am Telefon im kommerziellen Support durchaus des öfteren, daß der
Kunde die eingesetzte Software wegwerfen soll. Ich kann es ihm aber auch
begründen. Ich muß nicht jammern wie Du, wenn der Kunde spreiselt.
>Willkommen im
>Leben, ich verdiene mir nun mal damit mein Geld *und* bin Freak
>nebenbei.
d.o.c ist für die Leute die den Freak zum Beruf machen. Nicht umgekehrt.
>Deinen oben genannten Spruch haettest du sicher auch keinem
>Arbeit- oder Auftraggeber erwiedert, oder?
Doch. Öfter. Allerdings kann ich es auch begründen. Du jammerst nur.
>Irgendwie hab ich gedacht, dass ich hier in dieser Newsgroup ernsthaft
>darueber diskutieren koennte, aber es scheinen sich wirklich nur
>Kinder und Labertaschen hier rumzutreiben in der Hoffnung, ab und zu
>mal einen billigen Shareware-Crack abzusahnen :-(((
Hätte ich nicht Hoffnung, daß Du nur übertreibst, würdest Du einfach einen
*plonk* kassieren. Du bist armselig.
Raphael Becker
> >> Da ich meine Entscheidungen ueber solche Dinge hier nicht alleine treffe und
> >> der Markt ab einer gewissen Groessenordnung ein Woertchen mitredet, koennen
> >
> >Freßt mehr Scheiße, tausend Fliegen tun´s auch!
>
> Das ist genau diese Art von Mail, die ich hasse. Aber irgendwie hab
> ich bisher in dieser Newsgroup nur so einen Bloedsinn bekommen.
Dann hast Du zwei Möglichkeiten: lerne "Blösinn" (wie Du es nennst)
lieben oder unsubscribe.
> Leben, ich verdiene mir nun mal damit mein Geld *und* bin Freak
Mit Linux kann man auch professionell arbeiten ... (es bietet nur
nicht ganz so viel für ein multimedial angefixtes L**er-Hirn)
*hach ist das heute wieder so schön bunt hier* *spring* *freu*
> nebenbei. Deinen oben genannten Spruch haettest du sicher auch keinem
> Arbeit- oder Auftraggeber erwiedert, oder?
Nun, nicht direkt gesagt, aber doch so laut gedacht, daß ich mir den
Mund hätte zuhalten müssen, damit man´s nicht hört.
Gruß
Raphael Becker
Stefan Machwirth
On 24 Jun 1999 10:19:37 GMT, somi...@rz03.FH-Karlsruhe.DE (Michael
Sohmen) wrote:
>Ich dachte, du wolltest die Sicherheit des Protokolls ueberpruefen ?
Welches Protokoll? Nein, ich beziehe mich (mittlerweile) nur noch auf
die RSA-Implementierung von Microsoft. Anfangs ging es noch um die
gesamte Crypto-API, allerdings sind bei der Implementierung der
Private-Key-Verwaltung erhebliche Maengel aufgetaucht, so dass wir da
schon eine Loesung gefunden haben. Uebrig auf dem unsicheren Weg
bleibt nur noch eine gecryptete Datei. Nur noch hierum geht es
momentan. Ich dachte eigentlich, dass ich mich klar ausgedrueckt
haette - sorry, wenn nicht ;-)
>Wird eine Anwendung Groupware mit sicherer Datenuebertragung entwickelt ?
Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
Session-Keys werden zentral erzeugt und nicht ueber den Draht
geschickt). Unsicher sind nur noch die Files, die in einer
Intranet-Loesung bereit zur Abholung sind.
>Sonst sollte man IMHO besser auf IP-Ebene gehen und darauf alles
>verschluesseln statt auf Anwendungsebene.
Gefaellt mir nicht, da hier wieder die Schwaechen der M$-Keycontainer
ins Gewicht fallen wuerden. Ausserdem wollen wir aufgrund der zu
erwartenden Last offline Verschluesseln.
Gruss,
Lutz Donnerhacke
>On 24 Jun 1999 10:19:37 GMT, somi...@rz03.FH-Karlsruhe.DE (Michael
>Sohmen) wrote:
>
>>Ich dachte, du wolltest die Sicherheit des Protokolls ueberpruefen ?
>
>Welches Protokoll? Nein, ich beziehe mich (mittlerweile) nur noch auf
>die RSA-Implementierung von Microsoft. Anfangs ging es noch um die
>gesamte Crypto-API, allerdings sind bei der Implementierung der
>Private-Key-Verwaltung erhebliche Maengel aufgetaucht, so dass wir da
Es ist buggy. Es ist typisch Microsoft. Warum dem RSA Teil trauen, wenn er
so schnell selbst programmiert ist? S.u.
>schon eine Loesung gefunden haben. Uebrig auf dem unsicheren Weg
>bleibt nur noch eine gecryptete Datei. Nur noch hierum geht es
>momentan. Ich dachte eigentlich, dass ich mich klar ausgedrueckt
>haette - sorry, wenn nicht ;-)
Es ist unklar, was Du willst. Du weißt, daß Du untaugliche Mittel
verwendest, fragst nach Schwachstellen und erntest Gelächter.
Das wundert Dich?
>Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
>Session-Keys werden zentral erzeugt und nicht ueber den Draht
Bäh! *würg* *spuck*
Das Problem ist wirklich die Entwicklertruppe bei euch.
>geschickt). Unsicher sind nur noch die Files, die in einer
>Intranet-Loesung bereit zur Abholung sind.
Ich gestatte mir zu lachen.
>>Sonst sollte man IMHO besser auf IP-Ebene gehen und darauf alles
>>verschluesseln statt auf Anwendungsebene.
>
>Gefaellt mir nicht, da hier wieder die Schwaechen der M$-Keycontainer
>ins Gewicht fallen wuerden. Ausserdem wollen wir aufgrund der zu
>erwartenden Last offline Verschluesseln.
Da Du weißt, daß die Microsoft Lösung scheiße ist, wirf sie weg.
Lutz Donnerhacke
>Es ist buggy. Es ist typisch Microsoft. Warum dem RSA Teil trauen, wenn er
>so schnell selbst programmiert ist? S.u.
Ich mach mal die Ingrid:
; \usepackage{array,amstex}
; \newcommand{\bea}{\begin{eqnarray*}}
; \newcommand{\eea}{\end{eqnarray*}}
; \newcommand{\N}{\mathbb{N}}
; \newcommand{\idiv}[2]{\left\lfloor\frac{#1}{#2}\right\rfloor}
; \newcommand{\imod}[2]{\left\llcorner\!\!\frac{#1}{#2}\!\!\right\lrcorner}
; \frenchspacing
; \author{\underline{Lutz Donnerhacke}\\
; \texttt{lutz@@iks-jena.de}\\
; PGP \texttt{1127/DB089309}\\
; \texttt{1C1C 6311 EF09 D819}\\
; \texttt{E029 65BE BFB6 C9CB}}
; \title{Scheme Kryptopaket}
; \begin{document}
; \maketitle
; \section{Grundlegende Schemekonstrukte}
; Einige Rechenoperationen sind trival verkürzbar:
(define (succ n) (+ n 1))
(define (pred n) (- n 1))
(define (halb n) (quotient n 2))
(define (square n) (* n n))
(define (2^ n) (expt 2 n))
; R$^5$RS definiert leider nicht unendliche Ströme, wie sie für diverse
; Stromgeneratoren sinnvoll und nützlich sind. Deshalb wird dies hier
; nachgeholt.
(define (make-stream init next)
(cons init (delay (make-stream (next init) next))))
(define head car)
(define (tail stream) (force (cdr stream)))
; Ein typisches Beispiel sind die natürlichen Zahlen
; \texttt{(define N (make-stream 0 (lambda (n) (succ n))))}.
;
; Etwas Einblick in einen Strom gibt der Konverter in eine \emph{endliche}
; Liste.
(define (stream->list stream n)
(if (zero? n) '()
(cons (head stream)
(stream->list (tail stream) (pred n)))))
; Diese Ströme sollen durch Filter eingeschränkt werden können.
; Dies gestattet es komplexe Filterkriterien aufeinander aufzubauen und
; so verständlich zu halten.
(define (filter filter? s)
(if (filter? (head s))
(cons (head s) (delay (filter filter? (tail s))))
(filter filter? (tail s))))
; Es muß auch möglich sein, auf Ströme eine Funktion anzuwenden.
(define (stream-apply op s)
(cons (op (head s)) (delay (stream-apply op (tail s)))))
; Die Verknüpfung von zwei Strömen zu einem neuen ist auch eine nützliche
; Funktion. Sie ähnelt dem einfachen \texttt{stream-apply}, ist jedoch
; universeller.
(define (stream-merge op s1 s2)
(cons (op (head s1) (head s2))
(delay (stream-merge op (tail s1) (tail s2)))))
; In vielen Fällen ist es sinnvoll, einen Strom mehrfach sequentiell auslesen
; zu können, ohne jedesmal den Strom mitführen zu müssen. Dazu muß der Strom
; an eine globale Variable gebunden und diese umgesetzt werden. Je nach
; Implementation\footnote{\textsc{scm} stellt \texttt{defmacro} bereit.} muß
; das verschieden aussehen. R$^5$RS definiert zwar \texttt{let-syntax} und
; anverwande Konstrukte, jedoch sind diese noch selten implementiert.
(defmacro get (stream)
`(begin
(define next (head ,stream))
(set! ,stream (tail ,stream))
next))
; Der Gebrauch von \texttt{get} sollte sehr vorsichtig erfolgen, insbesondere
; wenn Ströme aufeinander aufbauen. Generelle Empfehlung ist, \texttt{get}
; ausschließlich auf letztendlichen und nicht weiter verschachtelten
; Strömen anzuwenden. \emph{Es verstößt gegen die Prinzipen der funktionalen
; Programmierung.}
; \section{Basismathematik}
; \subsection{Idealalgebra}
; Alle Grundrechenarten werden gewöhnlich über dem Restklassenideal getätigt.
; Zwei Zahlen sind bezüglich einer Restklassen gleich, wenn sie bei der
; Division durch eine für die Restklassen typische Zahl $b$ den gleichen Rest
; lassen. Verwendung findet die folgende Notation:
; \[ \imod x b = a \quad \Leftrightarrow \quad
; \begin{array}{rcl}
; x &=& kb + r\\
; x,k,r &\in& \N\\
; b &\in& \N^*\\
; r,k &<& b\\
; \end{array} \quad
; k = \idiv x b
; \]
; \subsubsection{Potenzen über einem Modulus}
; Eine häufig benötigte Funktion ist das Quadrat gegen einen Modulus.
; Dank der vordefinierten Funktionen liegt hier eine Laufzeit von $O(\log xb)
; = O(\log b)$ vor, da i.d.R $x \leq b$.
(define (squaremod x b)
(modulo (square x) b))
; Die eigentliche Potenzfunktion baut auf \emph{teile und herrsche} auf,
; was ihr eine Laufzeit von $O(\log^2 n)$ verschafft.
; \[
; \imod{x^n}b = \imod{x^{2k+i}}b =
; \begin{cases}
; 1 &: n=0\\
; \imod{\imod{x^2}b^k}b &: i=0\\
; \imod{x\imod{x^{2k}}b}b &: i=1\\
; \end{cases} \qquad n>0
; \]
; Für eine Funktion $f(x, n, b) = \imod{x^n}b$ gilt also:
; \[
; f(x, n, b) = \begin{cases}
; 1 &: n=0\\
; f(\imod{x^2} b, \frac n 2, b) &: i=0\\
; \imod{xf(x, n-1, b)} b &: i=1\\
; \end{cases} \qquad n\geq 0
; \]
; Zusätzlich wird benutzt, daß $\imod{x^n}b = \imod{\imod x b^n}b$ stets gilt,
; und die Berechnungen mit einem kleinen $x$ schneller sind.
(define (expmod x n b)
(define (em x n b)
(cond
((zero? n) 1)
((odd? n) (modulo (* x (em x (pred n) b)) b))
(else (em (squaremod x b) (halb n) b))))
(cond
((< n 0) (error "expmod: Negative exponent!"))
((< x b) (em x n b))
(else (em (modulo x b) n b))))
; \subsubsection{Modulare Inverse}
; Das modulare Inverse ist das $y$, daß der Gleichung $\imod{xy} b = 1$ zu
; vorgegebenen $x$ und $b$ genügt. Zur Berechnung von $y$ kommt der erweiterte
; Euklidische Algorithmus zur Anwendung.
; Dieser basiert auf der folgenden einsichtigen Rechnung:
; \[
; d = gcd(n_1, n_2) = n_1 x + n_2 y = n_1 x + (n_1k + r) y
; = r\underbrace{y}_{x'} + n_1\underbrace{(x + y k)}_{y'}
; \]
; Um also aus einem Ergebnis zu $r$ und $n_1$ zu einem Ergebnis für $n_1$ und
; $n_2$ zu gelangen, ist eine Umrechnung notwendig:
; \[
; y = x' \quad x = y' - x'k \quad k = \idiv{n_2}{n_1}
; \]
; \[
; (ggt(n_1, n_2), x, y) = \begin{cases}
; (ggt(\imod{n_2}{n_1}, n_1), y - x \idiv{n_2}{n_1}, x) &: n_1\leq n_2\\
; (ggt(n_2, n_1), y, x) &: n_1>n_2\\
; (n_2, 0, 1) &: n_1=0\\
; \end{cases}
; \]
(define (erweiterter-euklid n1 n2)
(cond
((= n1 0)
(list n2 0 1))
((<= n1 n2)
(let ((res (erweiterter-euklid (modulo n2 n1) n1)))
(list
(car res)
(- (caddr res) (* (cadr res) (quotient n2 n1)))
(cadr res))))
((> n1 n2)
(let ((res (erweiterter-euklid n2 n1)))
(list (car res) (caddr res) (cadr res))))))
; Da $\imod{xy}b = 1$ gleichbedeutend mit $xy + kb = 1$ ist, läßt sich das
; modulare Inverse tivial angeben.
(define (mod-invers x b)
(let ((ee (erweiterter-euklid x b)))
(cond
((not (= (car ee) 1)) #f)
((positive? (cadr ee)) (cadr ee))
(else (+ (cadr ee) b)))))
; \subsection{Pseudozufall}
; Zufallszahlen sind nicht berechenbar. Man kann es nur nachahmen.
; \subsubsection{\texttt{expmod}-Pseudoprimzahlen}
; Die folgende Nachahmung beruht auf der Hoffnung, daß die Potenzbildung
; gegen einem Primmodulus eine große Gruppe bildet.
(define (random-rsa seed)
(expmod seed 48760334 100000007))
; Damit läßt sich ein Strom von Zufallszahlen generieren. Eigentlich darf
; bei der Verwendung des RSA-Generators nur das letzte Bit verwendet werden
; \ldots
(define random-rsa-base 16)
(define random-rsa-stream
(stream-apply
(lambda (n) (modulo n random-rsa-base))
(make-stream 2 random-rsa)))
; \subsubsection{Lineare Kongruenzen}
; Schnell, beliebt und kryptographisch unsicher ist der lineare
; Kongruenzgenerator.
; \[ x_{i+1} = \imod{ax_i + b}m \]
(define (random-lineare-kongruenz seed)
(modulo (+ (* 2416 seed) 374441) 1771875))
(define random-lineare-kongruenz-base (2^ 20))
(define random-lineare-kongruenz-stream
(filter
(lambda (n) (< n random-lineare-kongruenz-base))
(make-stream 1 random-lineare-kongruenz)))
; \subsubsection{Pike}
; Ross Anderson brach einen Pseudozufallszahlengenerator namens Fish und
; entwarf aus diesen Erkenntnissen einen verbesserten Generator, der zudem
; noch einfacher ist.
; \bea
; A_i &=& \imod{A_{i-55} + A_{i-24}}{2^{32}} \\
; B_i &=& \imod{B_{i-57} + B_{i-7} }{2^{32}} \\
; C_i &=& \imod{C_{i-58} + C_{i-19}}{2^{32}} \\
; X_i &=& \text{$A_i$ xor $B_i$ xor $C_i$}
; \eea
; Die einzelen Generatoren werden immer dann weitergetaktet, wenn
; sie gleichzeigtig überlaufen oder es nicht tun. Damit werden mindestens
; zwei Generatoren getaktet, höchstens alle drei.
; \subsubsection{Erzeugung großer Zufallszahlen}
; Eine beliebig große Zufallszahl läßt sich einfach bestimmen, indem man
; die kleineren Werte aneinanderhängt. Es ist jedoch wichtig, zu große Zahlen
; zu ignorieren und nicht per Modulus umzuskalieren, weil damit die Verteilung
; verfälscht wird. Eine Halbierung des Zufallsbereiches ist dagegen zulässig.
; \[ r(n, b) = \begin{cases}
; r\left(\idiv n b, b\right)b + r(b, b) &: n > b\\
; r\left(n, \frac b 2\right) &: n \leq \frac b 2\\
; r(n, b) &: r(n, b) < n \leq b\\
; \end{cases} \qquad b = 2^k \quad k \in \N
; \]
(define random-stream random-lineare-kongruenz-stream)
(define random-base random-lineare-kongruenz-base)
(define (random n)
(define (rand n b)
(cond
((> n b)
(+ (rand b b) (* b (rand (quotient n b) b))))
((<= n (halb b)) (rand n (halb b)))
(else
(let ((r (modulo (get random-stream) b)))
(if (< r n) r
(rand n b))))))
(rand n random-base))
; Oft gibt es Randbedingungen, die die Zufallszahlen erfüllen müssen.
; Diese Randbedingungen können entweder durch einen Filter, oder durch
;
; Einige Anwendungen bestehen auf einer positiven Zufallszahl.
(define (positiv-random n)
(let ((r (random n)))
(if (zero? r) (positiv-random n) r)))
; \subsubsection{RC4}
(define rc4-size (2^ 8))
(define rc4-box
(list->vector
(stream->list
(make-stream 0 succ) rc4-size)))
(define (rc4-swap i j)
(begin
(define tmp (vector-ref rc4-box i))
(vector-set! rc4-box i (vector-ref rc4-box j))
(vector-set! rc4-box j tmp)))
(define (rc4-keysetup key)
(define (ks k count)
(cond
((= rc4-size count) '())
((null? k) (ks key count))
(else
(begin
(rc4-swap count
(modulo
(+ count (car k)
(vector-ref rc4-box count))
rc4-size))
(ks (cdr k) (succ count))))))
(ks key 0))
(define rc4-i 0)
(define rc4-j 0)
(define (rc4-step)
(begin
(set! rc4-i (modulo (succ rc4-i) rc4-size))
(set! rc4-j (modulo (+ rc4-j
(vector-ref rc4-box rc4-i))
rc4-size))
(rc4-swap rc4-i rc4-j)
(vector-ref rc4-box
(modulo (+ (vector-ref rc4-box rc4-i)
(vector-ref rc4-box rc4-j))
rc4-size))))
; \subsection{Primzahlen}
; Obwohl die Berechnung von Primzahlen mit bekannten Algorithmen möglich
; ist, sind diese für sehr große Primzahlen ungeeignet. Hier greifen
; probabilistische Tests, die nur mit einer gewissen Wahrscheinlichkeit
; die Nichtprimalität herausbekommen. Man kann jedoch die Wahrscheinlichkeit
; für die Nichtprimalität einer gegebenen Zahl beliebig klein wählen, so klein,
; daß sie die Wahrscheinlichkeit für einen Hardwarefehler während der Rechnung
; unterschreitet.
; \subsubsection{Kleinstteiler}
; Es ist sinnvoll, die ersten Primzahlen herzunehmen und die größten
; gemeinsamen Teiler zwischen deren Produkt und der zu testenden Zahl zu
; ermitteln. Dieser muß für eine Primzahl zwangsweise 1 sein.
; Da die Berechnung des Primzahlenproduktes nur einmal erfolgen soll, wurde
; eine nicht optimierte\footnote{Die Berechnung bis 10000 benötigt hier
; ca. zwei Sekunden.} Anfangsrekursion gewählt und die
; Ausführung bis zur ersten Benutzung verzögert. Dies hat den angenehmen
; Nebeneffekt, daß die Initialisierung nicht automatisch beim Programmstart
; erfolgt.
(define (berechne-primzahlenprodukt n)
(if (zero? n) 1
(let ((prod (berechne-primzahlenprodukt (pred n))))
(if (= 1 (gcd n prod)) (* n prod) prod))))
(define max-mini-primzahl 1000)
(define produkt-der-ersten-primzahlen
(delay (berechne-primzahlenprodukt max-mini-primzahl)))
(define (isqrt n) (inexact->exact (floor (sqrt n))))
(define (mini-prim? n)
(if (< n max-mini-primzahl)
(= 1 (gcd n (berechne-primzahlenprodukt (isqrt n))))
(= 1 (gcd n (force produkt-der-ersten-primzahlen)))))
; \subsubsection{Kleiner Fermat}
; Der kleine Satz von Fermat besagt:
; \[ p \text{ prim } \Rightarrow \imod{x^p}p = x \]
; Man wählt nun zufällige $x<p$ solange, bis der Test entweder scheitert,
; oder die Wahrscheinlichkeit unter den gewünschten Wert gefallen ist. Dieser
; Test arbeitet jedoch nicht zuverlässig: Die Carmichel-Zahlen erfüllen
; die Bedingung des kleinen Fermat ebenso. Jedoch haben die ohnehin seltenen
; Carmichel-Zahlen i.d.R. kleine Faktoren.
(define (fermat-prim? n count)
(let ((r (positiv-random n)))
(cond
((zero? count) #t)
((= r (expmod r n n))
(fermat-prim? n (pred count)))
(else #f))))
; \subsubsection{Lehman}
; Ein einfacherer und effektiverer Test stammt von Lehmann. Er geht davon
; aus, daß die modularen Wurzeln von 1 nur 1 und $-1$ sein können, wenn der
; Modulus bzgl. einer Primzahl berechnet wird. Die einfache Umkehrung gilt
; trivialerweise nicht $1 \equiv 4^2 \mod{15}$. Die zu überprüfende
; Gleichung lautet somit:
; \[ \imod{x^{\frac{p-1}2}}p = \begin{cases}1\\p-1\end{cases}\]
(define (lehman-prim? n count)
(if (zero? count) #t
(let ((z (expmod (positiv-random n) (halb n) n)))
(if (or (= z 1) (= z (pred n)))
(lehman-prim? n (pred count))
#f))))
; \subsubsection{Rabin-Miller}
; Für beide Tests ist ein zufälliger Wert 50\% Wahrscheinlichkeit Zeuge
; der Primalität. Der Rabin-Miller Test ist hier deutlich besser. Die
; Fehlerwahrscheinlichkeit dieses Tests liegt bei 1 zu $4\ln(n)2^{\sqrt{k/2}}$
; Schon für ein 256~bit Zahl ist die Fehlerwahrscheinlichkeit von sechs
; Runden Rabin-Miller unter $2^{-51}$.
;
; Rabin-Miller benötigt die Zahl n in der Form $1+2^bm$ mit ungeradem $m$.
(define (rabin-miller-prim? n count)
(define (gen-b-m n)
(if (odd? n) (cons 0 n)
(let ((b-m (gen-b-m (halb n))))
(cons (succ (car b-m)) (cdr b-m)))))
(define n-1 (pred n))
(define b-m (gen-b-m n-1))
(define b (car b-m))
(define m (cdr b-m))
(define (rmc? count)
(letrec
( (z (expmod (positiv-random n) m n))
(rm?
(lambda (j z)
(cond
((and (= z 1) (> j 0)) #f)
((= z n-1) #t)
((= j b) #f)
(else (rm? (succ j)
(squaremod z n)))))))
(if (or (= z 1) (= z n-1)) #t
(rm? 0 z))))
(define (rmc1? count)
(if (zero? count) #t
(and (rmc? count) (rmc1? (pred count)))))
(rmc1? count))
; \subsubsection{Primzahlsuche}
; Um ab einer bestimmten Zahl die nächste Primzahl zu finden, sucht man
; einfach schrittweise weiter. Die Implementierung greift einfach aus dem
; Datenstrom der möglichen Primzahlen die erste heraus. Die Programmlogik ist
; so deutlicher zu erkennen.
(define (prim? n)
(and (mini-prim? n) (rabin-miller-prim? n 10)))
(define (such-prim n)
(head (filter prim?
(make-stream
(if (odd? n) n (succ n))
(lambda (n) (+ 2 n))))))
; \section{RSA}
; \subsection{Schlüssel}
; Ein RSA Kryptosystem besteht aus einem öffentlichen und einem privaten
; Exponenten und einem gemeinsamen (zusammengesetzen) Modulus.
; Die Schlüsselgenerierung ist ein langwieriger Prozeß. Ein 1024~bit Schlüssel
; wird hier in ca. 45~Sekunden erzeugt, ein 2048~bit Schlüssel braucht schon
; 12~Minuten.
(define (make-rsa-keypair n e)
(define (mkp n e)
(let*
( (n2 (halb n))
(n-n2 (- n n2))
(nq (min n2 n-n2))
(np (max n2 n-n2))
(2^np-2 (2^ (- np 2)))
(2^nq-1 (2^ (- nq 1)))
(p (such-prim (+ (2^ np) (random 2^np-2))))
(q (such-prim (+ (2^ nq) (random 2^nq-1))))
(u (mod-invers p q))
(d (mod-invers e (* (pred p) (pred q))))
(b (* p q)))
(if d
(list (cons b e) d p q u)
(mkp n e))))
(if (< n 16)
(error "make-rsa-keypair: Modulus to small.")
(mkp n e)))
; Dieses Schlüsselpaar besteht aus dem öffentlichen und dem privaten Schlüssel.
(define (rsa-pubkey keypair) (car keypair))
(define (rsa-seckey keypair) keypair)
(define (rsa-modulus key)
(if (pair? (car key)) (caar key) (car key)))
(define (rsa-pubexp key)
(if (pair? (car key)) (cdar key) (cdr key)))
(define (rsa-secexp key) (cadr key))
(define (rsa-secprim-p key) (caddr key))
(define (rsa-secprim-q key) (cadddr key))
(define (rsa-secinv key) (car (cddddr key)))
; Es gestattet zwei grundlegende Operationen.
; \emph{Verschlüsseln} einer Nachricht $0<M<b$ in ein Chiffrat $C$
; \[ C = \imod{M^e}b \]
(define (rsa-encrypt m key)
(expmod m (rsa-pubexp key) (rsa-modulus key)))
; \emph{Entschlüsseln} eines Chiffrats $C$ zur Nachricht $M$
; \[ \imod{C^d}b = \imod{\imod{M^e}b^d}b = \imod{M^{ed}}b =
; \imod{M^{\varphi(b)}}b \overset{Euler}{\underset{Fermat}{=\!=\!=\!=}} M
; \]
(define (rsa-decrypt-exp c key)
(expmod c (rsa-secexp key) (rsa-modulus key)))
; Beim Entschlüsseln können jedoch auch die Zusatzinformationen über die
; Faktorisierung des Modulus $b=pq$ benutzt werden, da diese vorsorglich
; im privaten Schlüssel mitgespeichert wurden, weil sie sich aus dem $e,d$
; und $b$ sowieso leicht berechnen lassen.
; \[
; M = \imod{C^d}b = \imod{C^d}{pq}
; \]
; Der Chinesische Restsatz besagt nun, daß
; \[
; \begin{array}{r@{\:=\:}l}
; x_p & \imod{x}p\\
; x_q & \imod{x}q\\
; \end{array} \quad \Rightarrow \quad
; \begin{array}{r@{\:=\:}l}
; x & c_ppu_p + c_qqu_q\\
; 1 & \imod{pu_p}q = \imod{qu_q}p\\
; \end{array}
; \]
; Man rechnet leicht nach, daß
; \[
; x_p = \imod{x}p = \imod{c_ppu_p + c_qqu_q}p = 0 + \imod{c_q}p\imod{qu_q}p
; = c_q
; \]
; \[
; x_q = \imod{x}q = \imod{c_ppu_p + c_qqu_q}q = \imod{c_p}q\imod{pu_p}q + 0
; = c_p
; \]
; Somit kann man $x$ eindeutig zu $x = x_qpu_p + x_pqu_q$ angeben.
; Schaut man genauer hin, so sind der Chinesische Restsatz und der
; erweiterte Euklidische Algorithmus der gleiche Gedankengang.
;
; Ist es möglich, daß das so berechnete $x$ größer als $pq$ wird?
; \[
; x' = \imod{x}{pq} \quad \Rightarrow \quad
; x' + kpq = x \quad \begin{array}c k\in\N\\ 0\leq x'<pq\end{array}
; \]
; \[ x' + kpq = x_qpu_p + x_pqu_q \quad pu_p + qu_q = 1 \]
; \[ x' = x_qpu_p + x_p(1-pu_p) - kpq = x_p + ((x_q-x_p)u_p - kq)p \]
; \[ x' = x_p + \imod{x_q-x_p)u_p}{q}p \leq (p-1) + (q-1)p = pq - 1 < pq\]
;
; Eine weitere Vereinfachung ergibt sich aus dem kleinen Fermat
; für die Berechnungen gegen die Primfaktoren:
; \[ \imod{x^k}p = \imod{x^{\imod k {p-1}}}p \]
(define (rsa-decrypt-crt c key)
(let* ( (p (rsa-secprim-p key))
(q (rsa-secprim-q key))
(d (rsa-secexp key))
(u (rsa-secinv key))
(xq (expmod c (modulo d (pred q)) q))
(xp (expmod c (modulo d (pred p)) p)))
(+ xp (* p (modulo (* (- xq xp) u) q)))))
; Da die Berechnung über den chinesischen Restsatz mit kleineren Zahlen
; deutlich schneller\footnote{Ein 1024~bit Schlüssel benötigt hier 4,1~s auf
; die klassische Weise und 1,2~s über den Restsatz. Für einen 2048~bit
; Schlüssel lauten die Zeiten 31~s vs. 8,5~s.} ist, sollte diese Rechnung
; immer vorgezogen werden.
(define (rsa-decrypt c key)
(if (null? (cddr key))
(rsa-decrypt-exp c key)
(rsa-decrypt-crt c key)))
; \section{Tests}
; Obwohl eigentlich nicht notwendig, hier einige Tests.
; Es werden doch so manche Tippfehler entdeckt.
(define (test-it)
(define testkey (make-rsa-keypair 100 17))
(if (and
(= (squaremod 111 100) 21)
(= (expmod 7 9 1000) 607)
(equal? (erweiterter-euklid 49 77) '(7 -3 2))
(= (mod-invers 77 100) 13)
(mini-prim? 31)
(not (mini-prim? 33))
(mini-prim? 5882353)
(not (mini-prim? 100000001))
(fermat-prim? 5882353 20)
(not (fermat-prim? 100000001 20))
(lehman-prim? 5882353 20)
(not (lehman-prim? 100000001 20))
(rabin-miller-prim? 5882353 6)
(not (rabin-miller-prim? 100000001 6))
(= (such-prim 1000) 1009)
(random 33)
(= (rsa-decrypt
(rsa-encrypt
12345678901234567890
(rsa-pubkey testkey))
testkey)
12345678901234567890)
)
"Ok" "Fehler"))
Pascal Gienger
>Das spielt keine Rolle. Auch die US-Version bietet in Wirklichkeit nur
>40 Bit, da 88 Bit der NSA bekannt sind. Meine Frage ist auch eher,
>diejenige, ob es bestimmte Luecken ausser einem Brute-Force-Angriff
Das _ist_ aber die Lücke. Die NSA kann das mehr oder weniger in
Echtzeit decodieren und tut das. So etwas fällt unter "Verschlüsselung,
die die kleine Schwester davon abhält, Liebesbriefe zu lesen"(*). Wer das
im kommerziellen Umfeld als "sichere Informationsübertragung" verkauft,
gehört m.E. in den Knast. Von dort wird er wahrscheinlich dann von den USA
entführt und dort als "Held der amerikanischen Interessen" gefeiert...
In der Zeit, in der Du hier im Usenet (ein bißchen) rumstänkerst,
hättest Du auch OpenSSL nehmen können, das auf Windows portieren und
u.U. crypto-API-kompatible Funktionsköpfe definieren können.
Pascal
(*) m.W. aus der deutschen Übersetzung von Bruce Schneier, Angewandte
Kryptographie.
--
Unix, Pascal Gienger, Moosstr. 7 /\ 7 .rtssooM ,regneiG lacsaP xinU
Networx 78467 Konstanz / \ znatsnoK 76487 xrowteN
& WWW fin...@bluewin.de / \ ed.niweulb@essenif WWW &
T: +49 7531 52709, F: 52739 / \ 93725 :F ,90725 1357 94+ :T
Stefan Machwirth
On 24 Jun 1999 14:17:15 GMT, lu...@iks-jena.de (Lutz Donnerhacke)
wrote:
>>die RSA-Implementierung von Microsoft. Anfangs ging es noch um die
>>gesamte Crypto-API, allerdings sind bei der Implementierung der
>>Private-Key-Verwaltung erhebliche Maengel aufgetaucht, so dass wir da
>
>Es ist buggy. Es ist typisch Microsoft. Warum dem RSA Teil trauen, wenn er
>so schnell selbst programmiert ist? S.u.
Konkret? Welche Bugs der RC4-Implementierung sind bekannt?
Die Selberentwicklung ist natuerlich ein Argument (die Entscheidung
fuer die Crypto-API ist schliesslich noch nicht gefallen - darum
geht's ja hier). Der Vorteil, den ich erst mal in der Crypto-API sehe,
ist die Skalierbarkeit auf andere CryptoProvider. Wenn das ganze
System mal augebaut werden soll, oder die Verschluesselung auf einem
Hardware-basierenden Provider beruhen soll, kann eine flotte
RSA-Eigenentwicklung (betriebswirtschaftlich gesehen!) zum Eigentor
werden. OK, wir koennten jetzt unseren eigenen RSA-CSP programmieren,
aber bevor man das Rad neu erfindet, guckt man erst mal, ob einem das
bisherige Rad ausreichen wuerde (genau in diesem Stadium befinde ich
mich).
Man muss natuerlich auch immer die Sensibilitaet der Daten im Auge
behalten: die Knackbarkeit eines 40-Bit-Schluessels ist mir voellig
bewusst, aber die Qualitaet der Daten steht (noch - daher meine
Bemerkung der Skalierbarkeit) in keinem Verhaeltnis zu einem hoeheren
Sicherheitsaufwand. Um da ranzukommen wuerde niemand seinen Rechner
eine Woche laufen lassen. *Wenn* (um auf mein Anliegen
zurueckzukommen) die RC4-Implementation von M$ natuerlich hier ein
billiges Schlupfloch bietet (oder fertige Tools im Netz liegen), dann
ist eben die Gefahr zu gross, dass hier irgendwelche Spielkinder
anfangen, Unfug zu treiben.
>Es ist unklar, was Du willst. Du weißt, daß Du untaugliche Mittel
>verwendest, fragst nach Schwachstellen und erntest Gelächter.
>Das wundert Dich?
Ich weiss, dass die Schluesselsicherheit untauglich ist. Darauf kann
man reagieren. Bisher habe ich aber nichts gefunden, was die
Implementierung des RC4-Algos fuer untauglich erklaert. Auch hier habe
ich noch keine konkrete Antwort dazu. Jeder spricht von Bugs und
Maengeln, aber niemand kann offenbar sagen, wie sich diese aeussern.
>>Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
>>Session-Keys werden zentral erzeugt und nicht ueber den Draht
>
>Bäh! *würg* *spuck*
Bitte genauer.
Alle (individuellen) Keys liegen isoliert zur Offline-Bearbeitung fern
vom unsicheren Draht. Es ist nicht elegant, aber ich sehe auch nichts
Verwerfliches darin (ausser dem Verstoss gegen die reine Lehre). Es
erspart eine Menge organisatorischen Aufwand, was zu erlaeutern jetzt
den Rahmen sprengen wuerde. Daraus resultierende Probleme in der
Praxis habe ich hierbei noch keine gesehen, lasse mich aber gerne
belehren.
Gruss,
Stefan
* COMPLEX RANGE: another kind of metal!
Stefan Machwirth [comple...@t-online.de]
Stefan Machwirth [2:2454/90.20@fidonet]
Stefan Machwirth
On Fri, 25 Jun 1999 08:41:31 +0200, fin...@gmx.de (Pascal Gienger)
wrote:
>Das _ist_ aber die Lücke. Die NSA kann das mehr oder weniger in
>Echtzeit decodieren und tut das. So etwas fällt unter "Verschlüsselung,
Klar :-)
Wie ich schon mal im Thread sagte: wir uebertragen weder die
Tresorkombination vom Fort Knox, noch planen wir Attentate auf den
Praesidenten. Gerade wenn man sich theoretisch lange und intensiv mit
Cryptoverfahren auseinandersetzt, stoesst man sofort auf die Tatsache,
dass sich ein Schluessel in 'n' Zeiteinheiten knacken laesst. Dazu
kommt die Empoerung ueber die Naivitaet diverser Regierungen und
Exportbestimmungen, und schon wird aus der Cryptologie ein Heiligtum
und Absolutum geschaffen. Was dabei immer aus den Augen verloren wird,
ist das ausgewogene Verhaeltnis zu dem Wert der Daten, die man
verschluesselt. Daher nochmal der Hintergrund: wenn die
RC4-Implementierung von Microsoft fehlerfrei ist, reicht mir das
voellig. Wenn man die Daten aufgrund einer Luecke in einem Bruchteil
der Zeit bekommt, reicht es mir nicht mehr.
>die die kleine Schwester davon abhält, Liebesbriefe zu lesen"(*). Wer das
:-))
Genau darum geht's ungefaehr, wenn ich mal den gleichen
Uebertreibungsmassstab ansetze, wie dieser Satz. Oder genauso bildlich
gesprochen: ich moechte eine verschliessbare, einfache Box fuer die
Liebesbriefe finden und frage, ob bei der Microsoft-Box auch keine
Schrauben auf der Rueckseite sind, mit denen man die Box schnell
oeffnen kann. OK?
>im kommerziellen Umfeld als "sichere Informationsübertragung" verkauft,
>gehört m.E. in den Knast. Von dort wird er wahrscheinlich dann von den USA
>entführt und dort als "Held der amerikanischen Interessen" gefeiert...
Oder nach Frankreich, die sind IMHO noch bekloppter.
>In der Zeit, in der Du hier im Usenet (ein bißchen) rumstänkerst,
Es liegt mir absolut fern, irgendwo rumzustaenkern. Ein solcher Ton
ist fuer mich absolut fremd. Wenn meine Frage aber voellig ignoriert
wird und ich nur noch dumme Bemerkungen wegen dem Einsatz von Windows
ernte (ohne ueberhaupt die Hintergruende zu kennen), finde ich das
absolut kindisch und das kann solche Reaktionen schon mal provozieren.
>hättest Du auch OpenSSL nehmen können, das auf Windows portieren und
>u.U. crypto-API-kompatible Funktionsköpfe definieren können.
Wie ich im Thread auch schrieb, geht es hier auch um Skalierbarkeit.
Solange ich kein echtes KO-Kriterium fuer die Crypto-API finde, halte
ich sie immer noch fuer sinnvoll in diesem Kontext.
Stefan Machwirth
On Thu, 24 Jun 1999 15:21:03 +0200, Raphael Becker
<beck...@rumms.uni-mannheim.de> wrote:
>> >Freßt mehr Scheiße, tausend Fliegen tun´s auch!
>>
>> Das ist genau diese Art von Mail, die ich hasse. Aber irgendwie hab
>> ich bisher in dieser Newsgroup nur so einen Bloedsinn bekommen.
>
>Dann hast Du zwei Möglichkeiten: lerne "Blösinn" (wie Du es nennst)
>lieben oder unsubscribe.
Ich bin eigentlich ein ausgeglichener Mensch, der erst mal mit jedem
gut auskommt. Auch paar Jokes stecke ich normalerweise gut weg (sofern
sie als solche erkenntlich sind, was hier nicht der Fall war). Wenn
ich aber paar Fragen stelle, die euch 100x dumm erscheinen koennen
(was meiner Meinung nach aber nicht zutrifft), koennt ihr mich
berichtigen, mich aufklaeren, ignorieren, oder eine konkrete Antwort
bringen. Mails wie die obige braucht die Welt nicht, oder? In mir
erweckt das nur den Eindruck, dass hier einfach nur Pauschalplaetze
wiedergegeben werden.
>Mit Linux kann man auch professionell arbeiten ... (es bietet nur
>nicht ganz so viel für ein multimedial angefixtes L**er-Hirn)
Das ist mir auch nicht neu. Aber warum wird nur ueber die Beweggruende
diskutiert, als ueber meine eigentliche Frage? Glaubt mir doch
einfach, dass ich diese Info ueber Windows gerne haette. Das ist so
klar, wie der Papst katholisch ist, und benoetigt keiner weiteren
Ueberlegung.
Thiemo Seufer
[snip]
>Man muss natuerlich auch immer die Sensibilitaet der Daten im Auge
>behalten: die Knackbarkeit eines 40-Bit-Schluessels ist mir voellig
>bewusst, aber die Qualitaet der Daten steht (noch - daher meine
>Bemerkung der Skalierbarkeit) in keinem Verhaeltnis zu einem hoeheren
>Sicherheitsaufwand. Um da ranzukommen wuerde niemand seinen Rechner
>eine Woche laufen lassen.
Dann brauchst du ueberhaupt keine Verschluesselung.
>*Wenn* (um auf mein Anliegen
>zurueckzukommen) die RC4-Implementation von M$ natuerlich hier ein
>billiges Schlupfloch bietet (oder fertige Tools im Netz liegen), dann
>ist eben die Gefahr zu gross, dass hier irgendwelche Spielkinder
>anfangen, Unfug zu treiben.
Es gibt Spielkinder, die rechnen monatelang an distributed.net
Keys. Deine Daten sind schon bei reiner Neugier interessanter.
Thiemo Seufer
Michael Sohmen
: Oder nach Frankreich, die sind IMHO noch bekloppter.
Jospin ist aber kompetenter:
http://www.heise.de/tp/deutsch/inhalt/te/1772/1.html
Michael
--
Where do your trojan horses want to go today ?
Microbsoft
Pascal Gienger
>Wie ich im Thread auch schrieb, geht es hier auch um Skalierbarkeit.
>Solange ich kein echtes KO-Kriterium fuer die Crypto-API finde, halte
>ich sie immer noch fuer sinnvoll in diesem Kontext.
Was ist an der Crypto-API von M$ skalierbar? Was ist an Windows
skalierbar?
Übrigens ist eine Sicherheit, die nur die kleine Schwester aufhält, genauso
wirksam wie gar keine Verschlüsselung, meistens sogar noch schlimmer.
Aus falschem Sicherheitsgefühl geben Benutzer dann Daten über die
Leitung, die sie sonst anders weitergegeben hätten.
Pascal
Florian Weimer
> >Das _ist_ aber die Lücke. Die NSA kann das mehr oder weniger in
> >Echtzeit decodieren und tut das. So etwas fällt unter "Verschlüsselung,
>
> Klar :-)
>
> Wie ich schon mal im Thread sagte: wir uebertragen weder die
> Tresorkombination vom Fort Knox, noch planen wir Attentate auf den
> Praesidenten.
Die NSA dient dazu, die nationalen Interessen der USA zu schützen. Dazu
gehört ein wenig mehr als die Goldreseven und das Leben des
Präsidenten. ;)
Ralph Angenendt
>>Echtzeit decodieren und tut das. So etwas fällt unter "Verschlüsselung,
>Wenn man die Daten aufgrund einer Luecke in einem Bruchteil der Zeit
>bekommt, reicht es mir nicht mehr.
Was ist ein "Bruchteil der Zeit" von Echtzeit? Wenn ich etwas
verschlüsseln will, dann sorge ich dafür, daß es verschlüsselt ist.
Wenn ich weiß, daß das Verfahren "nahezu" in Echtzeit zu knacken
ist, dann brauche ich auch nicht zu Verschlüsseln.
Das ist so ähnlich, als ob ich einen transparenten Briefumschlag um
eine Postkarte drum mache, um das Postgeheimnis zu wahren.
>Genau darum geht's ungefaehr, wenn ich mal den gleichen
>Uebertreibungsmassstab ansetze, wie dieser Satz. Oder genauso bildlich
>gesprochen: ich moechte eine verschliessbare, einfache Box fuer die
>Liebesbriefe finden und frage, ob bei der Microsoft-Box auch keine
>Schrauben auf der Rueckseite sind, mit denen man die Box schnell
>oeffnen kann. OK?
Das ist Dir ja schon gesagt worden: 40 Bit sind bei entsprechender
Computerpower fast so schnell zu entschlüsseln, als wären sie nicht
da. Ersetze "Schrauben" durch "Schnappverschlüsse" und Du bist nah
dran.
>Wie ich im Thread auch schrieb, geht es hier auch um Skalierbarkeit.
>Solange ich kein echtes KO-Kriterium fuer die Crypto-API finde, halte
>ich sie immer noch fuer sinnvoll in diesem Kontext.
Knackbarkeit in Echtzeit ist für Dich kein KO-Kriterium? Du
versuchst dem Kunden eine Verschlüsselung zu verkaufen, die in
Wirklichkeit keine ist? Ich hoffe, daß Du Deinem Kunden eine
wirksame Verschlüsselung vertraglich zusicherst - dann steigen die
Chancen des Kunden bei einer Klage.
Ralph
--
From the moment I picked your book up until I put it down I was
convulsed with laughter. Some day I intend reading it.
-- Groucho Marx, from "The Book of Insults"
Stefan Machwirth
On 26 Jun 1999 01:06:47 GMT, ange...@gmx.de (Ralph Angenendt) wrote:
>>Wenn man die Daten aufgrund einer Luecke in einem Bruchteil der Zeit
>>bekommt, reicht es mir nicht mehr.
>
>Was ist ein "Bruchteil der Zeit" von Echtzeit? Wenn ich etwas
>verschlüsseln will, dann sorge ich dafür, daß es verschlüsselt ist.
>Wenn ich weiß, daß das Verfahren "nahezu" in Echtzeit zu knacken
>ist, dann brauche ich auch nicht zu Verschlüsseln.
Die NSA wird sich fuer die Daten nicht interessieren, sondern nur
nervige Mitarbeiter aus den eigenen Reihen, die ihren Spieltrieb
ausleben oder z.B. vor einer Kuendigung noch paar Daten mitnehmen
wollen. Das sind Leute mit normalen PCs, darum geht's.
Wenn ich weiss, dass ich nur auf Asphalt Auto fahren will, brauche ich
keinen Gelaendewagen. Ist zwar schick, aber unsinniges
Privatvergnuegen. Genauso sieht's hier mit der Verschluesselung aus.
>>Solange ich kein echtes KO-Kriterium fuer die Crypto-API finde, halte
>>ich sie immer noch fuer sinnvoll in diesem Kontext.
>
>Knackbarkeit in Echtzeit ist für Dich kein KO-Kriterium? Du
Ich glaube, dass ich in vielen Mails die Umstaende deutlich genug
gemacht habe, aber wir kommen gottseidank meiner Frage wieder naeher
;-)
Gibt es fuer die M$-Implementierung des RC4 nur den Brute Force
Angriff, oder auch eine Hintertuer? Diese Frage kann man doch nur mit
"Ja", "Nein" und "Weiss ich nicht" beantworten. Mehr wollte ich seit
meiner allerersten Mail hier in der Group eigentlich gar nicht wissen
:-)
Aber wo wir von Zeiten reden: wie lange, schaetzt ihr, dauert so ein
Angriff mit handelsueblichen PCs? Ich vermute mal, dass man schon auf
800000-900000 Keys pro Sekunde kommt, d.h. man waere im Schnitt 7,
maximal 13 Tage am rechnen. Stimmt's, oder hab ich hier was
uebersehen?
>versuchst dem Kunden eine Verschlüsselung zu verkaufen, die in
>Wirklichkeit keine ist? Ich hoffe, daß Du Deinem Kunden eine
>wirksame Verschlüsselung vertraglich zusicherst - dann steigen die
>Chancen des Kunden bei einer Klage.
Ihr macht euch viel zu viel Sorgen um mich. Ist eigentlich unnoetig
;-)
Stefan Machwirth
On Fri, 25 Jun 1999 12:38:58 +0200, "Thiemo Seufer"
<seu...@csv.ica.uni-stuttgart.de> wrote:
>>bewusst, aber die Qualitaet der Daten steht (noch - daher meine
>>Bemerkung der Skalierbarkeit) in keinem Verhaeltnis zu einem hoeheren
>>Sicherheitsaufwand. Um da ranzukommen wuerde niemand seinen Rechner
>>eine Woche laufen lassen.
>
>Dann brauchst du ueberhaupt keine Verschluesselung.
Doch, warum dieser Absolutismus? Es gibt keine Verschluesselung,
unsichere Verschluesselung und sichere Verschluesselung und alle
Phasen dazwischen.
Du kaufst dir ja auch keinen Ferrari, weil du nur noch zwischen gar
kein Auto und Rennwagen differenzierst, oder? Auch ein
Mittelklassewagen wie meiner tut gute Dienste, auch wenn ein
Porsche-Fahrer ueber meine 88 PS lachen wuerde. Ich finde, es wird bei
diesem Thema viel zu emotional diskutiert.
>>billiges Schlupfloch bietet (oder fertige Tools im Netz liegen), dann
>>ist eben die Gefahr zu gross, dass hier irgendwelche Spielkinder
>>anfangen, Unfug zu treiben.
>
>Es gibt Spielkinder, die rechnen monatelang an distributed.net
>Keys. Deine Daten sind schon bei reiner Neugier interessanter.
Nein, ich kenne unsere "Spielkinder" seit 10 Jahren. Es betrifft einen
geschlossenen Personenkreis, dessen "Cracks" mit so manchem
rumspielen, was sie im Internet aufschnappen. Wenn sie nach 2 Tagen
nicht dahintergekommen sind, hoeren sie wieder auf. Deswegen reicht
uns halt ein ordentlicher "Mittelklassewagen" als Verschluesselung,
den sie nicht einholen werden. Es darf nur nicht passieren, dass die
eine Abkuerzung kennen, von der ich nicht weiss.
Bildlich genug?
Bye,
Steffen Weider
Stefan Machwirth schrieb:
> Gibt es fuer die M$-Implementierung des RC4 nur den Brute Force
> Angriff oder auch eine Hintertuer?
Ja!
SCNR
Florian Laws
>
>Die NSA wird sich fuer die Daten nicht interessieren, sondern nur
>nervige Mitarbeiter aus den eigenen Reihen, die ihren Spieltrieb
>ausleben oder z.B. vor einer Kuendigung noch paar Daten mitnehmen
Dafür würde ich meinen PC auch einmal ein paar Tage durchrechnen lassen.
>Aber wo wir von Zeiten reden: wie lange, schaetzt ihr, dauert so ein
>Angriff mit handelsueblichen PCs? Ich vermute mal, dass man schon auf
>800000-900000 Keys pro Sekunde kommt, d.h. man waere im Schnitt 7,
>maximal 13 Tage am rechnen. Stimmt's, oder hab ich hier was
>uebersehen?
Ich weiss nicht, ob Deine Schätzungen stimmen, aber wenn ich
Daten vor meinen Mitarbeitern geheimhalten wollte, wären mit
7-13 Tage eindeutig zu wenig.
Florian
Pascal Gienger
>Die NSA wird sich fuer die Daten nicht interessieren, sondern nur
Doch wird sie. Ihr seid ein Unternehmen und Industriespionage ist mittler-
weile Auftrag Nr.1 bei allen Geheimdiensten, auch der NSA.
Eine UltraSparc mit 12 CPUs macht 12*900000 Keys oder sowas pro Sekunde.
Und schon werden aus 13 Tagen bereits etwas mehr als einer.
Eine Ultrasparc Enterprise kostet nicht _sehr_ viel. Deine Daten sind
unter Umständen mehr wert.
Merke: Es gibt bei Veschlüsselung nur "sicher" und "unsicher", nichts
dazwischen. Es sei denn, der Wert Deiner zu übertragenden Information
ist geringer als der Preis der nötige Rechenleistung für den
Brute Force. Wie schauts bei Dir aus? Wie wertvoll ist die Information?
Welcher Schaden kann entstehen, wenn sie in falsche Hände gerät?
1000 Mark? 10000 Mark? 100000 Mark? Für 1000 Mark kann man bereits einen
großen Rechner mit mehreren CPUs einen ganzen Tag rechnen lassen.
Pascal
Stefan Machwirth
Konkret welche?
Debeka Koblenz
Abt. DV/D
Stefan Machwirth
Laws) wrote:
>In article <37764f1...@news.btx.dtag.de>, Stefan Machwirth wrote:
>>
>>Die NSA wird sich fuer die Daten nicht interessieren, sondern nur
>>nervige Mitarbeiter aus den eigenen Reihen, die ihren Spieltrieb
>>ausleben oder z.B. vor einer Kuendigung noch paar Daten mitnehmen
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>wollen. Das sind Leute mit normalen PCs, darum geht's.
>
>Dafür würde ich meinen PC auch einmal ein paar Tage durchrechnen lassen.
Diese Leute aber nicht. Glaub's mir einfach. Ich programmiere jetzt
seit 7 Jahren ausschliesslich fuer diese Personengruppe und glaube
wirklich, die Leute einschaetzen zu koennen. Es ist auch nicht der
finanzielle Anreiz, der sie zum Hacken animieren wuerde, sondern eher
Frust und Neugier, wenn manche Leute eben nicht alle Daten zu Gesicht
bekommen. Und das ist es nicht wert, eine Woche die Kiste laufen zu
lassen. Am Haertesten hat sich einer mal an einem Zugangsschutz zu
schaffen gemacht: 3 Tage. Dann hat er's aufgegeben. Seine Kiste war
ein Supportfall und er bekam eine Abmahnung, so einfach geht das.
>Ich weiss nicht, ob Deine Schätzungen stimmen, aber wenn ich
>Daten vor meinen Mitarbeitern geheimhalten wollte, wären mit
>7-13 Tage eindeutig zu wenig.
S.o.. Ausserdem ist das eine Entscheidung des Managements, und
aufgrund meiner Erfahrung mit dem betroffenen Personenkreis und
Kenntnis der zu schuetzenden Daten wuerde ich diese Entscheidung sogar
mittragen. Anders waere es bei sensibleren Datenbestaenden oder einem
faehigeren Zielkreis, aber das ist nun mal nicht der Fall.
Stefan Machwirth
wrote:
>Eine UltraSparc mit 12 CPUs macht 12*900000 Keys oder sowas pro Sekunde.
>Und schon werden aus 13 Tagen bereits etwas mehr als einer.
>Eine Ultrasparc Enterprise kostet nicht _sehr_ viel. Deine Daten sind
>unter Umständen mehr wert.
Nein, viel weniger. Es geht hier um den Neugierde- und Frusttrieb der
Zielpersonen, die je nach Qualifikation nicht mit alle Datenbestaenden
und Kenngroessen arbeiten duerfen. Etwas "nicht zu sehen", was jemand
anderes aber sehen darf, verleitet die Leute zu billigen
Hackversuchen. Das hatten wir in der Vergangenheit immer wieder. Das
sind keine Profis, sondern Anwender, die privat mehr oder weniger
freaky sind (meistens weniger). Selbst vergleichweise billige
Zugangsmechanismen wurden bisher nicht gehackt.
>Merke: Es gibt bei Veschlüsselung nur "sicher" und "unsicher", nichts
>dazwischen. Es sei denn, der Wert Deiner zu übertragenden Information
>ist geringer als der Preis der nötige Rechenleistung für den
>Brute Force. Wie schauts bei Dir aus? Wie wertvoll ist die Information?
Geringer als der Aufwand eines Brute Force. Niemand verdient durch
diese Information mehr Geld.
>Welcher Schaden kann entstehen, wenn sie in falsche Hände gerät?
>1000 Mark? 10000 Mark? 100000 Mark? Für 1000 Mark kann man bereits einen
>großen Rechner mit mehreren CPUs einen ganzen Tag rechnen lassen.
Wird aber niemand machen. Man haette im Unternehmen sicher einen
betriebswirtschaftlichen Schaden (z.B. eventueller manueller Aufwand
durch verpfuschte Daten), der sich aber schwer in Euro messen laesst.
Tatsache ist aber, dass der Hacker selbst gar nichts von den Daten hat
und von daher seine Energie nur bis zu einem gewissen Punkt
verschwenden wird. Und dieser Punkt war in der Vergangenheit immer
sehr frueh erreicht.
Bye,
Steffen Weider
Sorry, Du hast mich missverstanden: Auf Oder-Fragen mit "Ja" zu
antworten
macht generell wenig Sinn, so auch hier. Ich wollte nur Deine Aussage
bestaetigen, dass es "nur den Brute Force Angriff oder auch eine
Hintertuer "
gibt.
Man beachte das "SCNR"
Pascal Gienger
>On Mon, 28 Jun 1999 02:19:24 +0200, fin...@gmx.de (Pascal Gienger)
>wrote:
>
>>Eine UltraSparc mit 12 CPUs macht 12*900000 Keys oder sowas pro Sekunde.
>>Und schon werden aus 13 Tagen bereits etwas mehr als einer.
>>Eine Ultrasparc Enterprise kostet nicht _sehr_ viel. Deine Daten sind
>>unter Umständen mehr wert.
>
>Nein, viel weniger. Es geht hier um den Neugierde- und Frusttrieb der
>Zielpersonen, die je nach Qualifikation nicht mit alle Datenbestaenden
>und Kenngroessen arbeiten duerfen. Etwas "nicht zu sehen", was jemand
>anderes aber sehen darf, verleitet die Leute zu billigen
Nur warum beißt Du Dich auf dieses Microsoftgedöns fest? Warum
nicht, wenn man etwas macht, es gleich richtig machen? So viel mehr Zeit
kostet es (wenn überhaupt) sicher nicht, wenn man sich das aus OpenSSL
o.ä. zusammenbaut. Ja, das geht auch auf NT.
Lutz Donnerhacke
>und Absolutum geschaffen. Was dabei immer aus den Augen verloren wird,
>ist das ausgewogene Verhaeltnis zu dem Wert der Daten, die man
>verschluesselt. Daher nochmal der Hintergrund: wenn die
>RC4-Implementierung von Microsoft fehlerfrei ist, reicht mir das
>der Zeit bekommt, reicht es mir nicht mehr.
Sicherheit ist definiert als: Kosten für das Brechen sind größer oder gleich
dem nach dem Brechen erzielten Wert.
Dabei geht es um praktische Angriffe. Wenn ich merke, daß ich auf unsicherem
Grund lebe, weil es einfach trivial ist den Endkunden anzugreifen, dann muß
ich nicht mehr als 40bit nehmen. Wenn ich aber weiß, daß 40bit auf einer
normalen Workstation in den Bereich der Echtzeitbrechung fällt, ist das
einfach zu billig. Die Daten müssen dann schon vorab wertlos sein.
>gesprochen: ich moechte eine verschliessbare, einfache Box fuer die
>Liebesbriefe finden und frage, ob bei der Microsoft-Box auch keine
>Schrauben auf der Rueckseite sind, mit denen man die Box schnell
>oeffnen kann. OK?
Es sind keine Schrauben an der Rückwand. Die Rückwand fehlt einfach.
Es ist sicher spaßig, mal 'nur für unwichtiges Zeug' zu entwickeln, aber die
Erfahrung zeigt, daß diese Implementationen vom Anwender oder gar der
eigenene Firma auch für extrem wertvolle Dinge verwendet werden, weil es ja
'verschlüsselt'. Also liber gleich richtig machen. Kostet kaum 20 Sekunden
mehr.
>Oder nach Frankreich, die sind IMHO noch bekloppter.
Deine Informationen sind veraltet.
>>hättest Du auch OpenSSL nehmen können, das auf Windows portieren und
>>u.U. crypto-API-kompatible Funktionsköpfe definieren können.
>
>Wie ich im Thread auch schrieb, geht es hier auch um Skalierbarkeit.
>Solange ich kein echtes KO-Kriterium fuer die Crypto-API finde, halte
>ich sie immer noch fuer sinnvoll in diesem Kontext.
Ich halte Fahrradfahren auch für sinnvoll, aber das heißt nicht, daß ich
deswegen alles per Fahrrad machen muß. Deine Prioritäten sind durcheinander.
Lutz Donnerhacke
>>Dafür würde ich meinen PC auch einmal ein paar Tage durchrechnen lassen.
>
>Diese Leute aber nicht. Glaub's mir einfach. Ich programmiere jetzt
>seit 7 Jahren ausschliesslich fuer diese Personengruppe und glaube
>wirklich, die Leute einschaetzen zu koennen. Es ist auch nicht der
>finanzielle Anreiz, der sie zum Hacken animieren wuerde, sondern eher
>Frust und Neugier, wenn manche Leute eben nicht alle Daten zu Gesicht
>bekommen. Und das ist es nicht wert, eine Woche die Kiste laufen zu
>lassen. Am Haertesten hat sich einer mal an einem Zugangsschutz zu
>schaffen gemacht: 3 Tage. Dann hat er's aufgegeben. Seine Kiste war
>ein Supportfall und er bekam eine Abmahnung, so einfach geht das.
Deine nicht vorhandenen Erfahrungen mit Industriespionage bedeuten nicht,
daß es diese bei Euch nicht gibt.
Lutz Donnerhacke
>Gibt es fuer die M$-Implementierung des RC4 nur den Brute Force
>"Ja", "Nein" und "Weiss ich nicht" beantworten. Mehr wollte ich seit
>meiner allerersten Mail hier in der Group eigentlich gar nicht wissen
>:-)
Nein. Aber niemand wäre so dumm, diesen Weg zu beschreiten.
Lutz Donnerhacke
>behalten: die Knackbarkeit eines 40-Bit-Schluessels ist mir voellig
>Bemerkung der Skalierbarkeit) in keinem Verhaeltnis zu einem hoeheren
>Sicherheitsaufwand. Um da ranzukommen wuerde niemand seinen Rechner
Laß jede Verschlüsselung weg. Die Daten sind es nicht wert.
>Ich weiss, dass die Schluesselsicherheit untauglich ist. Darauf kann
>man reagieren. Bisher habe ich aber nichts gefunden, was die
>Implementierung des RC4-Algos fuer untauglich erklaert. Auch hier habe
RC4 sind incl. Keysetup ca. 10 Zeilen Sourcecode. Der Aufruf der
MS-CryptoAPI sind incl. Keysetup ca. 10 Zeilen Sourcecode.
Der Unterschied ist, daß der erste Teil leicht verständlich ist.
Eine Programmentwicklung muß man nicht absichtlich verschlimmern.
Es sei denn, Du schreibst Programme als arbeitsplatzsichernde Maßnahme.
Das würde hier zur Kündigung führen.
>>>Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
>>>Session-Keys werden zentral erzeugt und nicht ueber den Draht
>>
>>Bäh! *würg* *spuck*
>
>Bitte genauer.
Schlüssel werden genau dort erzeugt, wo sie benutzt werden. Du beschreibst
ein Trustcenter, daß Dir nur das Risiko einbringt, im Zweifel die Schuld am
Mißlingen zu bekommen. Wie teuer ist es, dort jemanden zu bestechen? 50TDM?
Sind euch Eure kompletten Firmendaten nicht mehr wert? Ich sollte mal einen
mir persönlich bekannten Börseninformationsdienst mit Insider-Wissen
versorgen und den Kurs der Aktie droppen...
>Alle (individuellen) Keys liegen isoliert zur Offline-Bearbeitung fern
>vom unsicheren Draht. Es ist nicht elegant, aber ich sehe auch nichts
>Verwerfliches darin (ausser dem Verstoss gegen die reine Lehre). Es
>erspart eine Menge organisatorischen Aufwand, was zu erlaeutern jetzt
>den Rahmen sprengen wuerde. Daraus resultierende Probleme in der
>Praxis habe ich hierbei noch keine gesehen, lasse mich aber gerne
>belehren.
Sicherheit heißt nicht, daß der zuständige Mensch nichts bemerkt hat.
Wau Holland
...
>Was ist ein "Bruchteil der Zeit" von Echtzeit? Wenn ich etwas
>>gesprochen: ich moechte eine verschliessbare, einfache Box fuer die
>>Liebesbriefe finden und frage, ob bei der Microsoft-Box auch keine
>>Schrauben auf der Rueckseite sind, mit denen man die Box schnell
>>oeffnen kann. OK?
Man kann aber durchaus beide Angriffe parallel durchfuehren.
Bei der SYSTEMS letztes Jahr lief das am Heise-Stand so: Muenchner
CCCler versuchten dort - unter den Augen der Standleiterin - mit
Lockpicking-Werkzeugen das Schloss an einem ihrer Plexiglaskaesten
zu oeffnen. Ich schraubte zeitgleich - ohne dass die Frau das
bemerkte - die Schrauben an den Scharnieren der gleichen Tuer ab.
Ich schraubte aber nur dann, wenn die Frau das nicht mitbekam
(mein Angriff war einfach "brutaler" und offensichtlich machbar).
Da die Lockpicker etwas schneller fertig waren als ich, meinte
ich, dann koenne ich die Scharniere ja wieder anschrauben.
Worauf die Frau sehr erstaunt guckte und alles lachte...
Winzweich - so sicher wie ihr Schraubendreher
wau
Thiemo Seufer
[snip]
>>>Um da ranzukommen wuerde niemand seinen Rechner
>>>eine Woche laufen lassen.
>>
>>Dann brauchst du ueberhaupt keine Verschluesselung.
>
>Doch, warum dieser Absolutismus? Es gibt keine Verschluesselung,
>unsichere Verschluesselung und sichere Verschluesselung und alle
>Phasen dazwischen.
Du hast deine Daten als wertlos deklariert. Wertlose Daten
brauchen keine Verschluesselung.
>Du kaufst dir ja auch keinen Ferrari, weil du nur noch zwischen gar
>kein Auto und Rennwagen differenzierst, oder? Auch ein
>Mittelklassewagen wie meiner tut gute Dienste, auch wenn ein
>Porsche-Fahrer ueber meine 88 PS lachen wuerde. Ich finde, es wird bei
>diesem Thema viel zu emotional diskutiert.
Fuer eine bekannt untaugliche Verschluesselung ist _jeder_ Aufwand
zuviel. Du moechtest mit einem Tretroller auf der Autobahn fahren.
[snip]
>Nein, ich kenne unsere "Spielkinder" seit 10 Jahren. Es betrifft einen
>geschlossenen Personenkreis, dessen "Cracks" mit so manchem
>rumspielen, was sie im Internet aufschnappen. Wenn sie nach 2 Tagen
>nicht dahintergekommen sind, hoeren sie wieder auf.
Wenn du Verschluesselung auf diesem Niveau definierst, reicht schon
ein selbsterfundener Primitivalgorithmus.
Thiemo Seufer
Christian Leber
(Stefan Machwirth)
>>Dafür würde ich meinen PC auch einmal ein paar Tage durchrechnen lassen.
>Diese Leute aber nicht.
Es gibt Leute die lassen Rechner tagelang an einem einzigen
wunderschönen Landschaftsbild rendern...
Es gibt Leute die schon einige "Rechnerjahre" an einem RC5-64 nagen
lassen...
>Glaub's mir einfach.
Dann versteh ich deinen "Aufstand" nicht, dann benutz doch einfach
diese ach so tolle API.
Du vergißt auch nochwas... ich nehm mal an, das brechen deiner
Verschlüsslung dauert auf einem 300Mhz Rechner 8 Tage (nur als Bsp..),
dann kannst du dir recht sicher sein, daß der Normalmensch in 6 Jahren
Rechner hat, die das ganze in < einem halben Tag schaffen...
>Ich programmiere jetzt
>seit 7 Jahren ausschliesslich fuer diese Personengruppe und glaube
>wirklich, die Leute einschaetzen zu koennen.
avzz EBG13
--
ICQ 13004455 - http://leber.de/cl.pgp
Wau Holland
...
>>Dann brauchst du ueberhaupt keine Verschluesselung.
>
>Doch, warum dieser Absolutismus? Es gibt keine Verschluesselung,
>unsichere Verschluesselung und sichere Verschluesselung und alle
>Phasen dazwischen.
Das ist so richtig wie die Unterscheidung zwischen herzen, streicheln,
kuessen, Petting, bumsen und allen Phasenueberlagerungen dazwischen.
Trotzdem gibt es einen absolutistischen Unterschied zwischen
"kein bisschen schwanger" und "ein bisschen schwanger".
Doch sogar die Sicherheit zyklischer Verhuetungsmethoden ist hoeher
als die Verschluesselungsmethode ROT13; die unfehlbare Propagierung
der Verfahren von Bill Knaus-Ogatino sind so sicher wie der Papst.
>Du kaufst dir ja auch keinen Ferrari, weil du nur noch zwischen gar
>kein Auto und Rennwagen differenzierst, oder? Auch ein
>Mittelklassewagen wie meiner tut gute Dienste, auch wenn ein
>Porsche-Fahrer ueber meine 88 PS lachen wuerde. Ich finde, es wird bei
>diesem Thema viel zu emotional diskutiert.
Voll der Emotion des <vbg> weise ich auf das Gehinke Deines Vergleichs
hin. Denn wenn Du zum etwa gleichen Preis an vorhandener Rechenleistung
entweder eine Holzpantine oder einen Ferrari nutzen kannst zur
Fortbewegung (zugegeben: Taschenkalender sind bei einer tAktrate von
mehr als einmal pro Monat eher billiger als Pariser - aber manchmal
moechte man ebensowenig auf Sex verzichten wie auf Verschluesselung),
dann kannst Du zum etwa gleichen Bitschiebungs-Preis entweder ROT13
oder etwas "robusteres" benutzen als die Papiersiegel der Polizei,
mit denen Wohnungen versiegelt werden.
Das Problem besteht darin, dass sich im Verschluesselungsalltag
die Dummheit durchsetzt. Ich bin voellig sicher (TM), dass das
Produkt "ROT128 - die schnellste 128-Bit-Schiebeverriegelung und
sogar noch schneller als ROT13" als CD etwa bei PEARL fuer DM 9,80
massenhaft verkaufbar waere (ein ideales Produkt fuer Dataprolect).
Nicht nur Winzweich beweist das Tag fuer Tag.
Btw: Ein kleines Foto aus dem Kupferhuettchen in Jena findet sich
in der ROLLING STONE 7/99, deutsche Ausgabe - da trifft sich u.U.
Thueringen Netz manchmal.
w "ist dieses Posting jugendfrei" au
--
Der deutsche Aussenmessdiener Joseph Fischer beschriftet
Streubomben, Panzer und Bundesgewehre inbruenstig mit dem Text:
"Dieses Geraet kann nicht zur Durchfuehrung
straffreier Toetung benutzt werden".
Ralf Muschall
> Tatsache ist aber, dass der Hacker selbst gar nichts von den Daten hat
Der Nutzen für den H^HCracker ergibt sich aus dem Schaden für Euch.
man Nullummenspiel
Ralf
Kai Fett
> Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
> Session-Keys werden zentral erzeugt und nicht ueber den Draht
> Intranet-Loesung bereit zur Abholung sind.
Solange Deine Endpunkte wirklich sicher sind, funktioniert
security by obscurity ganz hervorragend.
Wenn man das Verfahren einer Verschlüsselung nicht kennt,
ist ein Chiffrat nicht zu knacken, wenn der Algoritmus auch
nur die Basic-Features (Homogene Verteilung über den
Ausgangsraum, jede Änderung eines Eingangsbit hat gleiche
Warscheinlichkeit der Änderung eines jeden Ausgangsbits zur
Folge etc) mitbringt.
Beweis: Liefere mir den Klartext zu eHrnhFkrfTsoxLvkfghmjmLlgFeD.
Es geht definitiv nicht, solange Verteilungsanalysen und
Known Plaintext scheitern und das Verfahren unbekannt ist.
CU
Kai
Kai Fett
> Du kaufst dir ja auch keinen Ferrari, weil du nur noch zwischen gar
> kein Auto und Rennwagen differenzierst, oder? Auch ein
> Mittelklassewagen wie meiner tut gute Dienste, auch wenn ein
> Porsche-Fahrer ueber meine 88 PS lachen wuerde. Ich finde, es wird bei
> diesem Thema viel zu emotional diskutiert.
Wenn ich einen gebrauchten Golf und einen neuen Ferrari zum
gleichen Preis bekommen könnte, und ich vom Nachbar des
Vorbesitzers des Golfs das Gerücht gehört hätte, der Golf
hätte Probleme, das Öl bei sich zu behalten - dann nenne mir
einen Grund, warum ich auf die Win-API, äh, den Golf
zurückgreifen sollte.
Kai
Stefan Machwirth
On 28 Jun 1999 00:00:00 +0000, k...@schnism.net (Kai Fett) wrote:
>*comple...@t-online.de* wrote:
>> Du kaufst dir ja auch keinen Ferrari, weil du nur noch zwischen gar
>> kein Auto und Rennwagen differenzierst, oder? Auch ein
>Wenn ich einen gebrauchten Golf und einen neuen Ferrari zum
>gleichen Preis bekommen k=F6nnte, und ich vom Nachbar des
>Vorbesitzers des Golfs das Ger=FCcht geh=F6rt h=E4tte, der Golf
>h=E4tte Probleme, das =D6l bei sich zu behalten - dann nenne mir
>einen Grund, warum ich auf die Win-API, =E4h, den Golf
>zur=FCckgreifen sollte.
Also ich wuerde erst einmal den Geruechten auf den Grund gehen ;-)
Nichts anderes mache ich hier. Es koennte ja auch sein, dass sich mein
Nachbar irrt.
Bisher kenne ich eben auch nur Geruechte, dass mit der
RC4-Implementation von M$ was nicht stimmen koennte. Offenbar weiss es
aber niemand genau (oder haelt sich damit zurueck, weil er das Wissen
fuer etwas Wertvolles ansieht?).
Gruss,
Stefan Machwirth
On Mon, 28 Jun 1999 18:50:31 +0200, "Thiemo Seufer"
<seu...@csv.ica.uni-stuttgart.de> wrote:
>Du hast deine Daten als wertlos deklariert. Wertlose Daten
>brauchen keine Verschluesselung.
Die Daten sind fuer den Hacker wertlos. Es besteht aber die Gefahr von
verursachten Kosten und Aufwand durch nicht sachgemaessen Umgang mit
den Daten.
>Wenn du Verschluesselung auf diesem Niveau definierst, reicht schon
>ein selbsterfundener Primitivalgorithmus.
Wuerde sicherlich reichen. Die Benutzung der Crypto-API zielte aber
auf zukuenftige Entwicklungen und die Moeglichkeit, bei einer
Erweiterung auf sensiblere Daten einen besseren CSP dahinterzuhaengen.
Diese Moeglichkeit erschien mir eigentlich als recht praktisch, wobei
ich mich mittlerweile frage, ob die High-Level-Schnittstelle mir
ueberhaupt noch was bringt, wenn ich anschliessend einen CSP sowieso
dazuprogrammieren muss (die auf dem freien Markt sind AFAIK rar, und
bei Blackboxen ginge natuerlich die ganze Diskussion ueber die
Sicherheit von vorne los). Ihr seht, sogar *ich* bin lernfaehig ;-)
Stefan Machwirth
On 28 Jun 1999 10:04:25 GMT, lu...@iks-jena.de (Lutz Donnerhacke)
wrote:
>RC4 sind incl. Keysetup ca. 10 Zeilen Sourcecode. Der Aufruf der
>MS-CryptoAPI sind incl. Keysetup ca. 10 Zeilen Sourcecode.
Ist natuerlich ein Argument. Wobei der asynchrone
Public-Key-Mechanismus noch dazukaeme (muss ich mir noch mal ansehen).
>>>>Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
>>>>Session-Keys werden zentral erzeugt und nicht ueber den Draht
>>>
>>>Bäh! *würg* *spuck*
>>
>>Bitte genauer.
>
>Schlüssel werden genau dort erzeugt, wo sie benutzt werden. Du beschreibst
>ein Trustcenter, daß Dir nur das Risiko einbringt, im Zweifel die Schuld am
Teilweisen Unsinn dieser Vorstellung hab ich mittlerweile auch
erkannt, als ich das logische Prozedere nochmal aufschluesselte. Es
waere kein Problem, die Keypairs sicher auf die Zielgeraete zu
bringen. Allerdings sind zentral erzeugte Session-Keys
zugegebenermassen Unsinn, da wir dann auch in der Zentrale die Private
Keys vorhalten muessten, um den Datenruecktransport zu entschluesseln.
Auf der anderen Seite kann es mal passieren, dass eine dezentrale
Maschine crasht und neu installiert werden muss. Spaetestens da
muesste das Keypair sowieso entweder restored oder ein neues generiert
werden. In beiden Faellen haetten wir wieder unsicheren Transport.
Also ist nix mehr mit zentral. Nur noch die Publics gehen ueber die
Leitung, das war's.
Bye,
Stefan Machwirth
On Mon, 28 Jun 1999 17:56:23 GMT, c...@bigfoot.com (Christian Leber)
wrote:
>Dann versteh ich deinen "Aufstand" nicht, dann benutz doch einfach
>diese ach so tolle API.
Die Vorlage ist laengst erstellt und geht uebermorgen zur
Entscheidung. Ich treibe mich nur noch hier rum, weil's mir hier so
gut gefaellt ;-)
Spass beiseite, ich habe wirklich noch mehr Interesse an den
Hintergruenden. Zumal ich noch etwas mehr hinter einige pauschale
Aussagen mancher Schreiber blicken moechte. Zumal ja auch der Ton
mittlerweile wieder auf ein normales Mass runtergefahren wurde und man
sich wieder normal unterhalten kann.
Debeka Koblenz
Abt. DV/D
Stefan Machwirth
wrote:
>Nur warum beißt Du Dich auf dieses Microsoftgedöns fest? Warum
>nicht, wenn man etwas macht, es gleich richtig machen? So viel mehr Zeit
>kostet es (wenn überhaupt) sicher nicht, wenn man sich das aus OpenSSL
>o.ä. zusammenbaut. Ja, das geht auch auf NT.
Ich beisse mich gar nicht fest. Aber unabhaengig von einer
Entscheidung zur Verschluesselung und weiterer Arbeit interessiert
mich das Thema auch weiterhin. Und da, wo mir manche Aussagen noch
nicht klar sind, frage ich einfach nach.
Die Crypto-API war eine Idee, die mir teilweise recht brauchbar
erschien. Also fing ich hier an zu diskutieren, wuenschte Fakten statt
Pauschalaussagen (was anfangs zu einigen Querelen fuehrte), und liess
mich auch in manchen Punkten belehren oder verbessern.
Im Moment kann mir immer noch niemand Probleme mit der
RC4-Implementatin von M$ nennen, aber die Argumente gegen die
Crypto-API liegen eher im Bereich "Eigenentwicklung ist eventuell
sicherer, aber *vor allem* macht sie nicht viel mehr Arbeit".
Gruss,
Stefan Machwirth
On 28 Jun 1999 00:00:00 +0000, k...@schnism.net (Kai Fett) wrote:
>> Nein, wir haben eine sichere Schluesselverteilung (Exchange-Keys und
>> Session-Keys werden zentral erzeugt und nicht ueber den Draht
>> geschickt). Unsicher sind nur noch die Files, die in einer
>> Intranet-Loesung bereit zur Abholung sind.
>
>Solange Deine Endpunkte wirklich sicher sind, funktioniert
>security by obscurity ganz hervorragend.
Wirklich sicher ist nichts, aber an den Endpunkten herrscht schon ein
sehr hoher Standard.
Dennoch ist die zentrale Schluesselerzeugung schon wieder Schnee von
gestern.
>Wenn man das Verfahren einer Verschl=FCsselung nicht kennt,
>ist ein Chiffrat nicht zu knacken, wenn der Algoritmus auch
Bei der Uebertragung der Session-Keys koennte man z.B. dafuer sorgen,
dass der konstante Blobheader eines exportierten Schluessels gestrippt
wird und lokal vor dem Import wieder davorgestellt wird. Dies stoesst
einen wenigstens nicht direkt mit der Nase auf die verwendete Software
und laesst auch den Session-Key in der Uebertragung nicht als solchen
erkennen. Jedenfalls nicht auf Anhieb.
>Beweis: Liefere mir den Klartext zu eHrnhFkrfTsoxLvkfghmjmLlgFeD.
Machwirth ist doof ;-)
Lutz Donnerhacke
>Bisher kenne ich eben auch nur Geruechte, dass mit der
>RC4-Implementation von M$ was nicht stimmen koennte. Offenbar weiss es
Falsch.
>aber niemand genau (oder haelt sich damit zurueck, weil er das Wissen
>fuer etwas Wertvolles ansieht?).
Nein.
Lutz Donnerhacke
><seu...@csv.ica.uni-stuttgart.de> wrote:
>>Du hast deine Daten als wertlos deklariert. Wertlose Daten
>>brauchen keine Verschluesselung.
>
>Die Daten sind fuer den Hacker wertlos. Es besteht aber die Gefahr von
>verursachten Kosten und Aufwand durch nicht sachgemaessen Umgang mit
>den Daten.
Dann nimm ordentliche Verfahren.
>>Wenn du Verschluesselung auf diesem Niveau definierst, reicht schon
>>ein selbsterfundener Primitivalgorithmus.
>
>Wuerde sicherlich reichen. Die Benutzung der Crypto-API zielte aber
>auf zukuenftige Entwicklungen und die Moeglichkeit, bei einer
>Erweiterung auf sensiblere Daten einen besseren CSP dahinterzuhaengen.
*lach*
>Diese Moeglichkeit erschien mir eigentlich als recht praktisch, wobei
>ich mich mittlerweile frage, ob die High-Level-Schnittstelle mir
>ueberhaupt noch was bringt, wenn ich anschliessend einen CSP sowieso
>dazuprogrammieren muss (die auf dem freien Markt sind AFAIK rar, und
>bei Blackboxen ginge natuerlich die ganze Diskussion ueber die
>Sicherheit von vorne los). Ihr seht, sogar *ich* bin lernfaehig ;-)
Gut. Jetzt noch logisch schlußfolgern.
Lutz Donnerhacke
>>Schlüssel werden genau dort erzeugt, wo sie benutzt werden. Du beschreibst
>>ein Trustcenter, daß Dir nur das Risiko einbringt, im Zweifel die Schuld am
>
>Teilweisen Unsinn dieser Vorstellung hab ich mittlerweile auch
>erkannt, als ich das logische Prozedere nochmal aufschluesselte. Es
>waere kein Problem, die Keypairs sicher auf die Zielgeraete zu
>bringen. Allerdings sind zentral erzeugte Session-Keys
>zugegebenermassen Unsinn, da wir dann auch in der Zentrale die Private
>Keys vorhalten muessten, um den Datenruecktransport zu entschluesseln.
Ihr wollte WAS? Behebe den Protokollfehler.
>Auf der anderen Seite kann es mal passieren, dass eine dezentrale
>Maschine crasht und neu installiert werden muss. Spaetestens da
Logo.
>muesste das Keypair sowieso entweder restored oder ein neues generiert
>werden. In beiden Faellen haetten wir wieder unsicheren Transport.
Neu generieren. Zertifikat für den alten Key rückrufen. Zertifikat für neuen
Key erzeugen.
>Also ist nix mehr mit zentral. Nur noch die Publics gehen ueber die
>Leitung, das war's.
man certificate.
Lutz Donnerhacke
>Im Moment kann mir immer noch niemand Probleme mit der
>RC4-Implementatin von M$ nennen, aber die Argumente gegen die
>Crypto-API liegen eher im Bereich "Eigenentwicklung ist eventuell
>sicherer, aber *vor allem* macht sie nicht viel mehr Arbeit".
Die Frage 'Kann mir jemand Probleme beim Verspeisen einer Haselnuß aus einem
Haufen Scheiße nennen?' mit 'Nimm lieber die Nüsse auf dem Tisch' zu
beantworten ist sinnvoll.
Stefan Machwirth
On 29 Jun 1999 08:01:38 GMT, lu...@iks-jena.de (Lutz Donnerhacke)
wrote:
>>bringen. Allerdings sind zentral erzeugte Session-Keys
>>zugegebenermassen Unsinn, da wir dann auch in der Zentrale die Private
>>Keys vorhalten muessten, um den Datenruecktransport zu entschluesseln.
>
>Ihr wollte WAS? Behebe den Protokollfehler.
Au, jetzt enttaeuschst du mich aber: seit Tagen machst du mich hier
fertig, und meinen groebsten Klops hast du uebersehen? ;-)
>>Auf der anderen Seite kann es mal passieren, dass eine dezentrale
>>Maschine crasht und neu installiert werden muss. Spaetestens da
>
>Logo.
>
>>muesste das Keypair sowieso entweder restored oder ein neues generiert
>>werden. In beiden Faellen haetten wir wieder unsicheren Transport.
>
>Neu generieren. Zertifikat für den alten Key rückrufen. Zertifikat für neuen
>Key erzeugen.
Genauso soll's laufen. Als ich an zentral erzeugte Keys dachte, hatte
ich augenscheinlich ein Blackout =8-O
Bye,
Stefan Machwirth
On 29 Jun 1999 08:09:50 GMT, lu...@iks-jena.de (Lutz Donnerhacke)
wrote:
>>Im Moment kann mir immer noch niemand Probleme mit der
Genau das ist das Problem. In der Beziehung bin ich wie ein kleines
Kind und stelle die Frage nach dem "Warum?", bis ich alles weiss. Ich
hatte eigentlich erhofft, dass man mir konkrete Bugs und
Schlupfloecher im BaseProvider von MS nennen koennte. Bereits im
Vorfeld habe ich ja durch Gutmanns Artikel und eigene Tests (BTW
wusstet ihr, dass bei Vorhandensein eines Default-Keycontainers der
Public-Key ausreicht, um einen Session-Key zu importieren?!? Das war
der Oberknueller) einige Maengel festgestellt, aber nie im
eigentlichen RC4-Algo. Die festgestellten Maengel liessen sich
umgehen, wobei ich mir dann natuerlich aufgrund des Aufwands die Frage
gefallen lassen musste, warum ich dann nicht alles komplett selbst
entwickle. Dennoch haette mich mal interessiert, ob man mit dem RC4
haette leben koennen.
Lutz Donnerhacke
>>>RC4-Implementatin von M$ nennen, aber die Argumente gegen die
>>>Crypto-API liegen eher im Bereich "Eigenentwicklung ist eventuell
>>>sicherer, aber *vor allem* macht sie nicht viel mehr Arbeit".
>>
>>Die Frage 'Kann mir jemand Probleme beim Verspeisen einer Haselnuß aus einem
>>Haufen Scheiße nennen?' mit 'Nimm lieber die Nüsse auf dem Tisch' zu
>>beantworten ist sinnvoll.
>
>Genau das ist das Problem. In der Beziehung bin ich wie ein kleines
>Kind und stelle die Frage nach dem "Warum?", bis ich alles weiss. Ich
Du darfst natürlich auch die Nuß aus dem Haufen am Boden nehmen und sauber
lutschen. Sie ist dann genauso unbedenklich, wie die auf dem Tisch.
>Vorfeld habe ich ja durch Gutmanns Artikel und eigene Tests (BTW
Davon hat man nichts gemerkt. Ich hätte mir die Suche nach der URL sparen
können.
>der Oberknueller) einige Maengel festgestellt, aber nie im
>eigentlichen RC4-Algo. Die festgestellten Maengel liessen sich
Ich traue es Microsoft nicht zu, 4 Zeilen falsch abzutippen.