🚀 go-pugleaf

In article <68d5yyf7s3B@pbw.tbx.berlinet.de>,
BADMAN@TBX.berlinet.de (Boris Wylutzki) wrote:
>Huhu!
Hihoo!

>Ich m�chte f�r ein Sharewareprogramm ein Registrier-key-System entwickeln.  
>Dabei mu� ich irgendwie mit dem Namen des Benutzers und einem geheimen  
>Passwort, was in der EXE-Datei steht, eine Registrier-Nummer erzeugen.
Muss es denn so kompliziert sein? Ich habe mal in einem Shareware-Proggi
etwas sehr einfaches gemacht:
>Diese Nummer sollte
>  a) immer die gleiche L�nge haben,
Das ist am Einfachsten: Halt die pass-nummer einfach in einem Rahmen
(z.B. nicht >65535) und addiere das naechst hoehere Bit (hier also
65536). Dann wird die Nummer vom Rechner immer mit derselben Laenge
gespeichert.
>  b) nicht decodierbar sein (Fall-Algorythmus),
Einfacher Algorithmus, den ich zwar nicht in einem 10.000DM Proggi
einsetzen wuerde, aber er ist komplex genug, um DAUs abzuhalte, mit
DEBUG was zu finden:

passnum = 0
SCHLEIFE jedes Zeichen im Namen abgehen
  passnum=xor(passnum*ascii(aktuelles zeichen), ascii(aktuelles zeichen))
ENDE SCHLEIFE
passnum = passnum-(DIV(passnum, 65000)*65000)+65535

Das habe ich mir gerade aus den Fingern gesogen, vielleicht kann ja mal
jemand sagen, wie unsicher sowas ist!?
>  c) sich bei kleinster Ver�nderung des Namens total ver�ndern,
>     damit man nicht so leicht auf Algorythmus & Passwort geschlossen
>     werden kann.
Kann ich nicht sagen, ich bin kein echter Kryptologe! ;)

>Kann mir da vielleicht jemand ein System sagen, wie ich das programmieren  
>kann? (m�gl. pascal)
Das sollte jetzt nicht mehr sooo schwer umzusetzen sein, oder?

Ciao, Philipp!

-----BEGIN PGP SIGNED MESSAGE-----

Ciao Boris,

>Ich m�chte f�r ein Sharewareprogramm ein Registrier-key-System entwickeln.  
>Dabei mu� ich irgendwie mit dem Namen des Benutzers und einem geheimen  
>Passwort, was in der EXE-Datei steht, eine Registrier-Nummer erzeugen.

>Diese Nummer sollte

>  a) immer die gleiche L�nge haben,
>  b) nicht decodierbar sein (Fall-Algorythmus),
>  c) sich bei kleinster Ver�nderung des Namens total ver�ndern,
>     damit man nicht so leicht auf Algorythmus & Passwort geschlossen
>     werden kann.

>Kann mir da vielleicht jemand ein System sagen, wie ich das programmieren  
>kann? (m�gl. pascal)

Was Du suchst, ist eine kryptographische One-Way-Hash-Function. Daf"ur gibt 
es einige etablierte Algorithmen. Diese akzeptieren einen Input beliebiger
L"ange und liefern einen Output fester L"ange, in der Regel 128 Bit.
Am sichersten scheint mir MD5. Beschreibungen dieses Algorithmus gibt es
zahlreiche, u.a. in Bruce Schneier: Applied Cryptography. 
Die Implementierung sollte auch in Pascal m"oglich sein, obwohl sie
in C vermutlich effizienter m"oglich ist.

Ciao,
Sebastian.


# Sebastian Staamann                           fon : +49 - 30 - 314 24890 #
# Technische Universitaet Berlin               fax : +49 - 30 - 314 24891 #
# Institut fuer Kommunikations- und Softwaretechnik                       #
# http://ini.cs.tu-berlin.de/~staa/            pgp public key available   #

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQBVAwUBMZhT/rYjKRzvIqsNAQGwYgH+IczHCv5GNraiN78yQF7AlaLV/xFeKK2q
4QvWKvfCGwEYAZ97s+Lrmh2SmpJA3XZC8dvsdumpej4c3FHFh1l6Zw==
=t0nd
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 13 May 1996 12:05:02 +0000, Philipp Adelt <padelt@warper.teuto.de> wrote:
> Einfacher Algorithmus, den ich zwar nicht in einem 10.000DM Proggi
> einsetzen wuerde, aber er ist komplex genug, um DAUs abzuhalte, mit
> DEBUG was zu finden:

DAUs arbeiten nicht mit debug.  Und du hast debug wahrscheinlich auch
noch nicht von nahem gesehen.

> passnum = 0
> SCHLEIFE jedes Zeichen im Namen abgehen
>   passnum=xor(passnum*ascii(aktuelles zeichen), ascii(aktuelles zeichen))
> ENDE SCHLEIFE
> passnum = passnum-(DIV(passnum, 65000)*65000)+65535

> Das habe ich mir gerade aus den Fingern gesogen,

...so sieht's auch aus.

> vielleicht kann ja mal
> jemand sagen, wie unsicher sowas ist!?

L�cherlich.  Auf der anderen Seite ist das auch nicht der Punkt, wo
angegriffen wird.  Ganz egal, wie kompliziert deine Abfrage ist, sie
besteht am Ende immer aus einem conditional jump, d.h. einer
Assembler-Anweisung.  Diese wird der Cracker finden und �ndern, so da�
deine Abfrage immer "ja, registriert" ergibt.

Es gibt keinen sicheren Schutz.  Auch wenn deine Funktion
kryptographisch akzeptiert w�re, sagen wir MD5 oder SHA, dann w�re dein
Programm dadurch nicht sicherer.

> >  c) sich bei kleinster Ver�nderung des Namens total ver�ndern,
> >     damit man nicht so leicht auf Algorythmus & Passwort geschlossen
					   ^

Leuten, die Algorithmus nicht richtig schreiben k�nnen, sollte man
eigentlich nicht dabei helfen, ihre wertvollen Programme vor Hackern zu
sch�tzen.  Das ist in meinen Augen ein klarer Fall von DLP - dem
Deutschen Loser-Programmierer.  Er "organisiert" sich einen Compiler von
hier und ein paar Class Libraries von da zusammen, nimmt ein
Demo-Programm der Class Library und tr�gt als Copyright-Halter sich
selber ein, und verbringt am Ende als einziges mit dem Kopierschutz /
der Registrierung Zeit.  Solche Software ist den Download nicht wert,
sie ist nichtmal die Zeit wert, die es mich in meinem Newsreader kostet,
das Announcement zu skippen.

> Kann ich nicht sagen, ich bin kein echter Kryptologe! ;)

Du bist auch kein unechter Kryptologe.  Du bist *gar kein* Kryptologe.

Felix

- -- 
Kirk: "I would like to speak to someone in authority."
Aelborne: "We, we don't have anybody in authority.  But I am the chairman of
  the Council of Elders, perhaps I will do.
	---"Errand Of Mercy", Stardate 3198.4

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAwUBMZiUgh/Da1Yoy+f1AQFyGQQAhhId1Wv8yU+gcUJvDqT4nmueR/bSi0FS
TM7u5DGo8TL3np2WZlkqwtHd20tlPnvLzMZwtZJ2QPMW6Bronx6ZpQJfqqoT2aQT
bHGN8d2Nuj7ylkqjCkjNOTmMwAhevnGSJsrdrwHfVz8i9lmsdyQ/0hcrm8Ksowrm
vPTyJGQ/XyY=
=NGKT
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

On 14 May 1996 09:36:07 GMT, Sebastian Staamann <staa@cs.tu-berlin.de> wrote:
> Was Du suchst, ist eine kryptographische One-Way-Hash-Function. Daf"ur gibt 
> es einige etablierte Algorithmen. Diese akzeptieren einen Input beliebiger
> L"ange und liefern einen Output fester L"ange, in der Regel 128 Bit.
> Am sichersten scheint mir MD5.

... nachdem du dich ausf�hrlich mit *welchen* Verfahren
auseinandergesetzt hast, hast du nach *welchen* Kriterien die Sicherheit
evaluiert und bist *weshalb* zum Schlu� gekommen, da� MD5 sicher ist?

Tats�chlich ist auch den weltbesten Kryptologen nicht klar, wie man
beurteilen soll, ob ein One-Way-Hash sicher ist.  Es gibt nur ein paar
Heuristiken, anhand derer man ein paar Verfahren als unsicher
deklarieren kann.  Tats�chlich kann niemand beweisen, da� MD5 sicher
ist, weil "sicher" einfach nicht mathematisch definiert ist.

Deshalb stellt man einfach aus blauem Himmel ein paar Forderungen auf,
wie da� die Hashfunktion kleine Eingabe-�nderungen weit propagieren
soll, d.h. da� der Hash sich radikal �ndern soll.  Das *scheint*
sinnvoll.  Aber ist es das auch?  Wer wei�...?

> Beschreibungen dieses Algorithmus gibt es zahlreiche, u.a. in Bruce
> Schneier: Applied Cryptography. 

Dieses Buch kann man in der Tat allen an Kryptographie interessierten
w�rmstens an's Herz legen.

> Die Implementierung sollte auch in Pascal m"oglich sein, obwohl sie in
> C vermutlich effizienter m"oglich ist.

Die Effizienz einer Implementierung ist von der Sprache grunds�tzlich
unabh�ngig.  *plonk*

Felix

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAwUBMZiV0R/Da1Yoy+f1AQEWRQQAydkIO5JEARzx+zgXK8xl6wsSp9sjWhEy
DYhFxDXo6WmZIwFeAphJdInPdn5/eFhFHqgeQaFigmmhrm7l7WxqjV6x8hHS63RO
huJGFs901VtMrDER/1re1PGS0idb7DAydZSi5s38DRD8i9QviWXZn+qK4JvRjsoo
C3sccyp4QA0=
=wDej
-----END PGP SIGNATURE-----

In article <slrn4ph543.2i5.leitner@xorn.prz.tu-berlin.de>,
leitner@xorn.prz.tu-berlin.de (Felix von Leitner) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>On Mon, 13 May 1996 12:05:02 +0000, Philipp Adelt <padelt@warper.teuto.de> wrote:
>> Einfacher Algorithmus, den ich zwar nicht in einem 10.000DM Proggi
>> einsetzen wuerde, aber er ist komplex genug, um DAUs abzuhalte, mit
>> DEBUG was zu finden:
>DAUs arbeiten nicht mit debug.  Und du hast debug wahrscheinlich auch
>noch nicht von nahem gesehen.
Doch, doch, aber ich schreibe mir eher selber tools, um aus Excel den
Reg-Namen ohne Aufrufen rauszufinden (natuerlich nur, um ohne Windows
herauszufinden, ob die Lizenz echt ist;).

>> passnum = 0
>> SCHLEIFE jedes Zeichen im Namen abgehen
>>   passnum=xor(passnum*ascii(aktuelles zeichen), ascii(aktuelles zeichen))
>> ENDE SCHLEIFE
>> passnum = passnum-(DIV(passnum, 65000)*65000)+65535
>
>> Das habe ich mir gerade aus den Fingern gesogen,
>...so sieht's auch aus.
Jau.
>> vielleicht kann ja mal
>> jemand sagen, wie unsicher sowas ist!?
>L�cherlich.  Auf der anderen Seite ist das auch nicht der Punkt, wo
>angegriffen wird.  Ganz egal, wie kompliziert deine Abfrage ist, sie
>besteht am Ende immer aus einem conditional jump, d.h. einer
>Assembler-Anweisung.  Diese wird der Cracker finden und �ndern, so da�
>deine Abfrage immer "ja, registriert" ergibt.
Jau, da hast Du allerdings voellig recht. Ich habe ja geschrieben, dieser
_Algorithmus_ ist nicht sicher. Und was dann der Compiler daraus macht,
ist natuerlich nochwas anderes. In dem Falle, den Du ansprichst (der
absolut nicht einfach ist und den auch Cracker nur mit viel Zeit be-
herrschen), hilft nur a) das Abfragen an vielen Stellen oder b) Ver-
schluesselung und Validierung (per CRC oder aehnlichem). Beides war
nicht gefragt. Es geht eben um ein kleines Teil, mit dem man so eine
Abfrage zusammenbasteln kann.

>Es gibt keinen sicheren Schutz.  Auch wenn deine Funktion
>kryptographisch akzeptiert w�re, sagen wir MD5 oder SHA, dann w�re dein
>Programm dadurch nicht sicherer.
Doch, sicher_er_ schon, in dem Sinne, dass es _weniger_ Leuten moeglich
ist, a) Deinen Key innendrin zu lesen und b) die Abfrage zu umgehen.
Aber absolute Sicherheit gibt's wirklich nicht.

>> >  c) sich bei kleinster Ver�nderung des Namens total ver�ndern,
>> >     damit man nicht so leicht auf Algorythmus & Passwort geschlossen
>					   ^
>Leuten, die Algorithmus nicht richtig schreiben k�nnen, sollte man
>eigentlich nicht dabei helfen, ihre wertvollen Programme vor Hackern zu
>sch�tzen.  Das ist in meinen Augen ein klarer Fall von DLP - dem
>Deutschen Loser-Programmierer.  Er "organisiert" sich einen Compiler von
>hier und ein paar Class Libraries von da zusammen, nimmt ein
>Demo-Programm der Class Library und tr�gt als Copyright-Halter sich
>selber ein, und verbringt am Ende als einziges mit dem Kopierschutz /
>der Registrierung Zeit.  Solche Software ist den Download nicht wert,
>sie ist nichtmal die Zeit wert, die es mich in meinem Newsreader kostet,
>das Announcement zu skippen.
Spinner. Er hat nicht einmal gesagt, was das fuer ein Programm ist und
Du ziehst gleich drueber her. Hast Du nix anderes zu tun?
Was sagt Dir denn, dass er nicht gerade die genialste Software 
erfunden hat? Es muss jawohl nicht jeder Kryptologie- (und auch nicht
die Ansaetze davon) experte sein, um gute Programme schreiben zu koenne.
Ach nochwas: Wenn Du so wenig hilfsbereit bist, was machst Du dann hier?
Dich an anderer Leute Ideen ergoetzen?

>> Kann ich nicht sagen, ich bin kein echter Kryptologe! ;)
>Du bist auch kein unechter Kryptologe.  Du bist *gar kein* Kryptologe.
Auch richtig. Und das habe ich nie behauptet. Werde ich auch gar nicht,
weil ich mich mit anderen Problemen beschaeftige als solchen.

Ciao, Philipp!

-----BEGIN PGP SIGNED MESSAGE-----

On 15 May 1996 17:35:52 GMT, Sebastian Staamann <staa@cs.tu-berlin.de> wrote:
> Sch"on zu lesen, dass sich an dieser Uni anscheinend auch andere f"ur
> Kryptologie interessieren.

Es gibt sogar Vorlesungen zum Thema Datensicherheit und Kryptographie,
also der eine oder andere scheint sich in der Tat daf�r zu
interessieren...

> H1  Input M der Hashfunktion H kann beliebiger L"ange sein
> H2  Output h=H(M) hat feste L"ange m

Das ist an sich eher die Definition von "Hash", da� du eine Menge von
Nachrichten eindeutig auf eine kleinere Menge von Nachrichten abbildest,
als eine Anforderung f�r die Handhabbarkeit...

> Hinsichtlich Sicherheit gelten mindestens folgende Forderungen:
> S1  Es ist ein hart*, aus einem gegebenen h die urspr"ungliche Nachricht M zu 
>     berechnen

Es ist nicht nur hart, es ist unm�glich, denn es gibt nicht "die
urspr�ngliche Nachricht M", es gibt (hoffentlich!) unendlich viele
m�gliche Nachrichten, die auf h gehasht werden!

> S2  Es ist hart, zu einer gegebenen Nachricht M eine andere Nachricht M' 
>     zu finden, so dass H(M) = H(M')

Das folgt aus der n�chsten Forderung.

> S3  Es ist hart, zwei Nachrichten M und M' zu finden, so dass H(M) = H(M')

Die Kernforderung an eine sichere Hashfunktion ist, da� du zu einem Hash
x keine Nachricht N findest, so da� H(N)=x.  Besonders, wenn du die
Hashfunktion zur Authentisierung benutzen willst, ist dir eigentlich
egal, welche anderen Passw�rter den gleichen Hash haben, solange niemand
aus einem Hash ein Passwort errechnen kann.

> Falls ein potentieller Angreifer in der Lage ist, die Rechenzeit t von H(M) 
> zu erfahren, muss ausserdem gelten:
> S4   Es ist hart, aus h und der Rechenzeit t von H(M), M zu berechnen

Die Rechenzeitproblematik ist eine sehr neue, und ist meines Erachtens
auf Multitasking- und Multiusersystemen von geringerer Bedeutung.  Die
Forderung ist trotzdem eine sinnvolle, zweifelsohne.

> *hart bedeutet hier, dass der zeitliche Aufwand des besten Algorithmus'
>  zur L"osung des Problems "uberpolymial ist. Als "uberpolynomial werden
>  beispielsweise folgende Probleme angenommen, die alle als Grundlagen
>  von Kryptosystemen Verwendung finden:
>  - die NP-vollst"andigen Probleme, inkl. Knappsack
>  - die Faktorisierung in der modularen Arithmetik
>  - die Berechnung des diskreten Logarithmus in der modularen Arithmetik
>  Mathematische Beweise dieser Annahmen existieren nicht. Weil diese
>  Probleme jedoch schon lange in der Mathematik erforscht werden und 
>  trotzdem keine Algorithmen mit polynomialem Aufwand gefunden wurden,
>  unterstellen die Kryptographen "uberpolynomialen Aufwand bis zum
		    ^^^^^^^^^^^^^

Alle Kryptologen tun das, nicht nur die Kryptographen.  In diesem
Zusammenhang sieht es so aus, als sei man sich auch bei NP-vollst�ndigen
Problemen nicht sicher, ob es keinen polynomiellen Algorithmus geben
k�nnte, k�nne es aber nicht beweisen.  Ich w�rde mal sagen,
"NP-vollst�ndig" ist so definiert, da� es keinen Algorithmus in
polynomieller Zeit geben kann!

> Zur H"arte von One-Way-Hash-Functions gegen Kryptanalyse, anders formuliert:
> wie weit sind die Forderungen hinsichtlich Sicherheit erf"ullt ?
> Die Obergrenze an Komplexit"at zum Brechen von S2 wird gebildet durch
> eine Brute Force Attack, bei der Kandidaten f"ur M' generiert werden.
> Im statistischen Mittel hat man nach 2^(m-1) Versuchen ein M' gefunden, so dass
> H(M') = h. Das heisst, je gr"osser m, desto sicherer der Algorithmus gegen
> Brute Force Attacks. Als maximal sicher kann eine One-Way-Hash-Function
> gelten, wenn es keinen effizienteren Algorithmus als Brute Force gibt.
> Das ist das Ziel der Designer von One-Way-Hash-Algs. Die Nichtexistenz
> von  Algorithmen, effizienter als Brute Force, l"asst sich nicht beweisen.
> Die Auswahl eines One-Way-Hash-Alg kann man durch Ausschluss
> treffen, wobei man als Anfangsmenge diejenigen nimmt, die "uberhaupt
> ver"offentlicht und in gr"osserem Masse untersucht worden sind. Dann
> bleiben nach meiner Meinung {MD2, MD4, MD5, SHA} als sichere Algs.
> MD2 und SHA sind relativ langsam und scheiden deshalb aus. MD5 ist ein 
> aufgrund von erfolgreicher Kryptanalyse gegen einzelne Runden von MD4
> weiterentwickelter MD4 und deswegen nach Meinung der meisten
> "weltbesten Kryptologen" sicherer.

Ja Moment, "sicherer" hei�t aber "sicherer als MD4", es ist nicht
bewiesen, da� es beispielsweise sicherer als SHA ist.  �berhaupt basiert
bei der Kryptographie eine ganze Menge auf "Guesswork".

> >> Die Implementierung sollte auch in Pascal m"oglich sein, obwohl sie in
> >> C vermutlich effizienter m"oglich ist.
> >Die Effizienz einer Implementierung ist von der Sprache grunds�tzlich
> >unabh�ngig.  *plonk*

> Das glaube ich kaum, selbst bei einem stark optimierenden Pascal-Compiler.
> Gemeint ist ja wohl Laufzeit mit realen Compilern auf realen Rechnern, 
> nicht irgendwelche theoretischen Betrachtungen des Algorithmus. 
> Von dem Fehlen von Bitoperationen in Standard-Pascal und von Sprachen, 
> die nur interpretiert werden k"onnen, gar nicht zu reden.

Pascal kann selbstverst�ndlich auch compiliert werden, und
selbstverst�ndlich kann es auch einen Pascal-Compiler geben, der
Bit-Operationen, die man "von Hand" irgendwie zusammengebastelt hat, in
effizienten Maschinencode �bersetzt.

Felix

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAwUBMZpZ+h/Da1Yoy+f1AQGIkQQAskP+PQxcJQrFaI9byHltvweZPu2mvuj8
Cu3uo5spKVgBVFzZ+HA1tu2l7m02ty43zN409WuiEFSzOGai5EX68JgBy3bPE6zn
vKDGBV6LpCTSAIqmndCNC/5NllJ6fs+T6WQL7MntUuEsqwVtVu0W0qpIQPfB1sau
CPpP5dwcaPk=
=FR7b
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

leitner@xorn.prz.tu-berlin.de (Felix von Leitner) writes:
>On 14 May 1996 09:36:07 GMT, Sebastian Staamann <staa@cs.tu-berlin.de> wrote:
>> Was Du suchst, ist eine kryptographische One-Way-Hash-Function. Daf"ur gibt 
>> es einige etablierte Algorithmen. Diese akzeptieren einen Input beliebiger
>> L"ange und liefern einen Output fester L"ange, in der Regel 128 Bit.
>> Am sichersten scheint mir MD5.

>... nachdem du dich ausf�hrlich mit *welchen* Verfahren
>auseinandergesetzt hast, hast du nach *welchen* Kriterien die Sicherheit
>evaluiert und bist *weshalb* zum Schlu� gekommen, da� MD5 sicher ist?

Sch"on zu lesen, dass sich an dieser Uni anscheinend auch andere f"ur
Kryptologie interessieren. Auch auf die Gefahr hin, dass sich dieser 
thread doch etwas von der urspr"unglichen Frage entfernt, einige 
allgemeine Bemerkungen zu One-Way-Hash-Funktionen. F"ur die praktische 
Handhabbarkeit gelten folgende Forderungen:
H1  Input M der Hashfunktion H kann beliebiger L"ange sein
H2  Output h=H(M) hat feste L"ange m
H3  Der Rechenaufwand, um den Hashwert h aus der Nachricht M zu berechnen,
    ist m"oglichst gering

Hinsichtlich Sicherheit gelten mindestens folgende Forderungen:
S1  Es ist ein hart*, aus einem gegebenen h die urspr"ungliche Nachricht M zu 
    berechnen
S2  Es ist hart, zu einer gegebenen Nachricht M eine andere Nachricht M' 
    zu finden, so dass H(M) = H(M')
S3  Es ist hart, zwei Nachrichten M und M' zu finden, so dass H(M) = H(M')

Falls ein potentieller Angreifer in der Lage ist, die Rechenzeit t von H(M) 
zu erfahren, muss ausserdem gelten:
S4   Es ist hart, aus h und der Rechenzeit t von H(M), M zu berechnen

*hart bedeutet hier, dass der zeitliche Aufwand des besten Algorithmus'
 zur L"osung des Problems "uberpolymial ist. Als "uberpolynomial werden
 beispielsweise folgende Probleme angenommen, die alle als Grundlagen
 von Kryptosystemen Verwendung finden:
 - die NP-vollst"andigen Probleme, inkl. Knappsack
 - die Faktorisierung in der modularen Arithmetik
 - die Berechnung des diskreten Logarithmus in der modularen Arithmetik
 Mathematische Beweise dieser Annahmen existieren nicht. Weil diese
 Probleme jedoch schon lange in der Mathematik erforscht werden und 
 trotzdem keine Algorithmen mit polynomialem Aufwand gefunden wurden,
 unterstellen die Kryptographen "uberpolynomialen Aufwand bis zum
 Gegenbeweis.

Zur H"arte von One-Way-Hash-Functions gegen Kryptanalyse, anders formuliert:
wie weit sind die Forderungen hinsichtlich Sicherheit erf"ullt ?
Die Obergrenze an Komplexit"at zum Brechen von S2 wird gebildet durch
eine Brute Force Attack, bei der Kandidaten f"ur M' generiert werden.
Im statistischen Mittel hat man nach 2^(m-1) Versuchen ein M' gefunden, so dass
H(M') = h. Das heisst, je gr"osser m, desto sicherer der Algorithmus gegen
Brute Force Attacks. Als maximal sicher kann eine One-Way-Hash-Function
gelten, wenn es keinen effizienteren Algorithmus als Brute Force gibt.
Das ist das Ziel der Designer von One-Way-Hash-Algs. Die Nichtexistenz
von  Algorithmen, effizienter als Brute Force, l"asst sich nicht beweisen.
Die Auswahl eines One-Way-Hash-Alg kann man durch Ausschluss
treffen, wobei man als Anfangsmenge diejenigen nimmt, die "uberhaupt
ver"offentlicht und in gr"osserem Masse untersucht worden sind. Dann
bleiben nach meiner Meinung {MD2, MD4, MD5, SHA} als sichere Algs.
MD2 und SHA sind relativ langsam und scheiden deshalb aus. MD5 ist ein 
aufgrund von erfolgreicher Kryptanalyse gegen einzelne Runden von MD4
weiterentwickelter MD4 und deswegen nach Meinung der meisten
"weltbesten Kryptologen" sicherer.

>Tats�chlich ist auch den weltbesten Kryptologen nicht klar, wie man
>beurteilen soll, ob ein One-Way-Hash sicher ist.  Es gibt nur ein paar
>Heuristiken, anhand derer man ein paar Verfahren als unsicher
>deklarieren kann.  Tats�chlich kann niemand beweisen, da� MD5 sicher
>ist, weil "sicher" einfach nicht mathematisch definiert ist.
F"ur One-Way-Hash-Algs.

>Deshalb stellt man einfach aus blauem Himmel ein paar Forderungen auf,
>wie da� die Hashfunktion kleine Eingabe-�nderungen weit propagieren
>soll, d.h. da� der Hash sich radikal �ndern soll.  Das *scheint*
>sinnvoll.  Aber ist es das auch?  Wer wei�...?

Die Forderung nach maximaler Diffusion ist nicht aus dem blauen Himmel heraus
erhoben. Vielmehr ist sie eine Forderung, um besonders S2 zu garantieren,
da man sich sonst beim Raten von M' sukzessive ann"ahern k"onnte.
So versucht man durch Forderungen an Eigenschaften des Algorithmus zu
erreichen, dass die Forderungen S1 bis S4 erf"ullt werden, ohne dies
mathematisch beweisen zu k"onnen. Die Vorgehensweise ist eher, dass
man eine Forderung aufstellt und dann zeigt, wie bei Nichterf"ullung eine
Kryptanalyse aussehen kann. 


>> Die Implementierung sollte auch in Pascal m"oglich sein, obwohl sie in
>> C vermutlich effizienter m"oglich ist.
>Die Effizienz einer Implementierung ist von der Sprache grunds�tzlich
>unabh�ngig.  *plonk*

Das glaube ich kaum, selbst bei einem stark optimierenden Pascal-Compiler.
Gemeint ist ja wohl Laufzeit mit realen Compilern auf realen Rechnern, 
nicht irgendwelche theoretischen Betrachtungen des Algorithmus. 
Von dem Fehlen von Bitoperationen in Standard-Pascal und von Sprachen, 
die nur interpretiert werden k"onnen, gar nicht zu reden.

Die obenstehenden "Uberlegungen zu Kryptanalyse bedeuten hinsichtlich der in 
der urspr"unglichen Frage vorgesehenen Anwendung nat"urlich, mit Kanonen 
auf Spatzen zu schiessen, da ein Cracker nicht den schwersten Weg
gehen w"urde und eher das "geheime" Passwort aus der Programmdatei
'raussuchen w"urde. Relevant sind hier eigentlich vor allem Geschwindigkeit 
und Lizensierung.

Sebastian.

P.S Die M"uhe diese Antwort zu schreiben, habe ich mir gemacht, weil ich
    glaube und hoffe, dass sich doch einige Leser dieser Group f"ur
    Kryptologie interessieren. Deinen arroganten Tonfall, Felix, halte ich
    f"ur inakzeptabel. 

# Sebastian Staamann                           fon : +49 - 30 - 314 24890 #
# Technische Universitaet Berlin               fax : +49 - 30 - 314 24891 #
# Institut fuer Kommunikations- und Softwaretechnik                       #
# http://ini.cs.tu-berlin.de/~staa/            pgp public key available   #

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQBVAwUBMZoV67YjKRzvIqsNAQHY5AH+OjdvpmgS8bS6CNXFQvJ+i3Om8SYp/vfF
kQA1OV2AJHUi6pKr7K4ziuLfEPdK7sxSX0cqaSB2XQMKK7d5lLFBCg==
=uOM5
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 15 May 1996 12:09:24 +0000, Philipp Adelt <padelt@warper.teuto.de> wrote:
> >L�cherlich.  Auf der anderen Seite ist das auch nicht der Punkt, wo
> >angegriffen wird.  Ganz egal, wie kompliziert deine Abfrage ist, sie
> >besteht am Ende immer aus einem conditional jump, d.h. einer
> >Assembler-Anweisung.  Diese wird der Cracker finden und �ndern, so da�
> >deine Abfrage immer "ja, registriert" ergibt.
> Jau, da hast Du allerdings voellig recht. Ich habe ja geschrieben, dieser
> _Algorithmus_ ist nicht sicher. Und was dann der Compiler daraus macht,
> ist natuerlich nochwas anderes. In dem Falle, den Du ansprichst (der
> absolut nicht einfach ist und den auch Cracker nur mit viel Zeit be-
> herrschen), hilft nur a) das Abfragen an vielen Stellen oder b) Ver-
> schluesselung und Validierung (per CRC oder aehnlichem). Beides war
> nicht gefragt.

Und beides hilft auch nicht gegen den Hacker, der Zeit hat.
Erstaunlicherweise haben viele Jugendliche offenbar eine monstr�se Zeit
in diesen Dingen.

> >Es gibt keinen sicheren Schutz.  Auch wenn deine Funktion
> >kryptographisch akzeptiert w�re, sagen wir MD5 oder SHA, dann w�re dein
> >Programm dadurch nicht sicherer.
> Doch, sicher_er_ schon, in dem Sinne, dass es _weniger_ Leuten moeglich
> ist, a) Deinen Key innendrin zu lesen und b) die Abfrage zu umgehen.
> Aber absolute Sicherheit gibt's wirklich nicht.

Wer hat was davon, deinen Key zu lesen?
Die Umgehung der Abfrage ist unabh�ngig von dem Hash-Verfahren, was du
benutzt.

> >Leuten, die Algorithmus nicht richtig schreiben k�nnen, sollte man
> >eigentlich nicht dabei helfen, ihre wertvollen Programme vor Hackern zu
> >sch�tzen.  Das ist in meinen Augen ein klarer Fall von DLP - dem
> >Deutschen Loser-Programmierer.  Er "organisiert" sich einen Compiler von
> >hier und ein paar Class Libraries von da zusammen, nimmt ein
> >Demo-Programm der Class Library und tr�gt als Copyright-Halter sich
> >selber ein, und verbringt am Ende als einziges mit dem Kopierschutz /
> >der Registrierung Zeit.  Solche Software ist den Download nicht wert,
> >sie ist nichtmal die Zeit wert, die es mich in meinem Newsreader kostet,
> >das Announcement zu skippen.
> Spinner. Er hat nicht einmal gesagt, was das fuer ein Programm ist und
> Du ziehst gleich drueber her. Hast Du nix anderes zu tun?

Doch.  Aber ich habe in meinem Leben schon viele solcher Programme
gesehen, und ich habe manchmal den Eindruck, da� dem "Programmierer" gar
nicht bewu�t ist, was f�r einen Schrott er da fabriziert.  Deshalb an
dieser Stelle dieser Rant.

> Was sagt Dir denn, dass er nicht gerade die genialste Software 
> erfunden hat?

Geniale Software braucht keinen Kopierschutz.  Geniale Software wird
gekauft, weil sie genial ist.

> Es muss jawohl nicht jeder Kryptologie- (und auch nicht
> die Ansaetze davon) experte sein, um gute Programme schreiben zu
> koennen.

Nein.  Aber wer herkommt, und wissen will, wie er einen Kopierschutz
macht, hat in meinen Augen schon verloren.  Der Endbenutzer zahlt doch
f�r den Aufwand, den ein Programm gemacht hat.  Und wenn sich der Autor
Aufwand macht damit, einen Kopierschutz zu ersinnen, der am Ende doch
umgangen wird, dann zahlt der Kunde, wenn er das Programm kauft, zuviel
Geld.  Und bei mir ist eine Sache schonmal *ganz* klar:  Programme mit
Kopierschutz, z.B. Dongle, kommen mir nicht ins Haus.  Punkt.

> Ach nochwas: Wenn Du so wenig hilfsbereit bist, was machst Du dann hier?
> Dich an anderer Leute Ideen ergoetzen?

"Hier" ist in meinem Fall bln.lehre.informatik, und f�r die Wissenschaft
Informatik interessiere ich mich.  Au�erdem studiere ich Informatik.
Ich wei� ja nicht, in welchem "Brett" *du* das hier gefunden hast, aber
offenbar in keinem wissenschaftlichen.  Denn Wissenschaftler
besch�ftigen sich nicht mit Kopierschutz, sondern mit der L�sung des
Problemes.

Felix

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAwUBMZpUaB/Da1Yoy+f1AQGPBQP+LJiVQ6xmIZQnPGEbE9IO1hyKSGJiOhm2
l/1oPmK1+F7zhYmV2LCF3jyoPI2e429nFFI48HvtglTHU0xza9bsQ31itT/N5R/K
Dy1IT8IeSRVYeJaep6zvEBz9I5u+vBHMRQP5rIaoSFUcoof3LFxQEoKjxcYmqjvT
R52mp59mcYM=
=Jb8J
-----END PGP SIGNATURE-----

On 14 May 1996 14:17:00 GMT, leitner@xorn.prz.tu-berlin.de (Felix von Leitner)
wrote:

>Tats�chlich kann niemand beweisen, da� MD5 sicher
>ist, weil "sicher" einfach nicht mathematisch definiert ist.

Die Sicherheit eines Krypto-Verfahrens wird daran gemessen, wie lange es
dauert, bis der erste erfolgreiche Knackversuch publiziert wird, und wie gro�
die Restriktionen sind, unter denen ein Knacken m�glich ist.

>Die Effizienz einer Implementierung ist von der Sprache grunds�tzlich
>unabh�ngig.  *plonk*

Du sitzt heute wieder mal auf sehr hohem Ro�, was?

Es gibt Sprachen, die aufgrund ihrer Restriktionen eine effiziente
Implementation wirksam verhindern. Beispiel: Ich definiere eine Sprache namens
C--, die keinen Multiplikations-Operator und keine M�glichkeit f�r
Inline-Assembler beinhaltet. Kann ich in so einer Sprache einen effizienten
Gau�schen Algorithmus programmieren? Wohl kaum.

Ferner sind interpretierte Sprachen grunds�tzlich ineffizient.
-- 
Ciao... Sven    |  Internet:    sbs@psbs.franken.de
Herzogenaurach  |  CompuServe:  Sven B. Schreiber 100557,177
Germany         |  MS Network:  sbs_msn@msn.com
http://www.geocities.com/CapitolHill/1441/index.html

On 15 May 1996 22:02:26 GMT, leitner@xorn.prz.tu-berlin.de (Felix von Leitner)
wrote:

>Geniale Software braucht keinen Kopierschutz.  Geniale Software wird
>gekauft, weil sie genial ist.

Soso. Das ist aber eine sehr idealistische Sicht der Welt. Ich w�rde eher
sagen, "ungeniale Software wird _nicht_ kopiert, weil sich kein Schwein daf�r
interessiert." Je interessanter ein Programm, desto gr��er die Bem�hungen, es
zu kopieren bzw. zu knacken (siehe z.B. die Knack-Orgien bei diversen
CAD-Programmen).

>offenbar in keinem wissenschaftlichen.  Denn Wissenschaftler
>besch�ftigen sich nicht mit Kopierschutz, sondern mit der L�sung des
>Problemes.

Ehm... wieviele Wissenschaftler/innen haben sich bereits damit befa�t,
milit�rischen Funkverkehr m�glichst schwer dechiffrierbar zu machen oder
fremden Funkverkehr zu knacken? Ich glaube, du siehst die Arbeit von
Wissenschaftler/inne/n in etwas arg rosigem Licht.
-- 
Ciao... Sven    |  Internet:    sbs@psbs.franken.de
Herzogenaurach  |  CompuServe:  Sven B. Schreiber 100557,177
Germany         |  MS Network:  sbs_msn@msn.com
http://www.geocities.com/CapitolHill/1441/index.html

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 16 May 1996 00:09:27 GMT, Sven B. Schreiber <sbs@psbs.franken.de> wrote:
> >Tats�chlich kann niemand beweisen, da� MD5 sicher
> >ist, weil "sicher" einfach nicht mathematisch definiert ist.
> Die Sicherheit eines Krypto-Verfahrens wird daran gemessen, wie lange es
> dauert, bis der erste erfolgreiche Knackversuch publiziert wird, und wie gro�
> die Restriktionen sind, unter denen ein Knacken m�glich ist.

Das ist Unfug.  Es gibt ziemlich obskure Verfahren, zu denen noch kein
einziger "Knackversuch" publiziert wurde, weil sie einfach noch fast
niemand untersucht hat.

Diese Verfahren gelten nat�rlich *nicht* als sicher.

> >Die Effizienz einer Implementierung ist von der Sprache grunds�tzlich
> >unabh�ngig.  *plonk*

> Du sitzt heute wieder mal auf sehr hohem Ro�, was?

Wer Unsinn behauptet, wird geplonkt.

> Es gibt Sprachen, die aufgrund ihrer Restriktionen eine effiziente
> Implementation wirksam verhindern. Beispiel: Ich definiere eine Sprache namens
> C--, die keinen Multiplikations-Operator und keine M�glichkeit f�r
> Inline-Assembler beinhaltet.

Inline-Assembler ist als Sprach-Feature in Sachen Effizienz
grunds�tzlich f�r die Compiler-Performance irrelevant.

Au�erdem kann ich einen Compiler schreiben, der erkennt, wenn ich ein
Mal mit einem Plus nachbilde und das "richtig" �bersetzt.

> Kann ich in so einer Sprache einen effizienten
> Gau�schen Algorithmus programmieren? Wohl kaum.

Selbstverst�ndlich.

> Ferner sind interpretierte Sprachen grunds�tzlich ineffizient.

Sprachen k�nnen *per Definition* nicht ineffizient sein.

*plonk*

> Germany         |  MS Network:  sbs_msn@msn.com
					 ^^^^^^^^

*plonk*

Felix

- -- 
The man who doesn't read good books has no advantage over the man who
can't read them.
	--Mark Twain (1835 - 1910)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAwUBMZuugh/Da1Yoy+f1AQH2NAQAwR2ZZCtR/Al2UWYpVMF8qPHCf52hoXVy
zgLQ+Kvoo92SzMfBHaDxX0aEOhfe9zlNE/FbHRFHUBmdcLyiSAohoNDfw0wlTfs9
3qZVJcVXrzgaTThExgQfvzJ1IeicyCK75Tg1GJ12/t4qMD1qm103pn+IYsMt2VHh
OkLkX/IbAu8=
=9L2/
-----END PGP SIGNATURE-----

leitner@xorn.prz.tu-berlin.de (Felix von Leitner) schrieb am 14.05.96

> Leuten, die Algorithmus nicht richtig schreiben k�nnen, sollte man
> eigentlich nicht dabei helfen, ihre wertvollen Programme vor Hackern zu
> sch�tzen. Das ist in meinen Augen ein klarer Fall von DLP - dem Deutschen
> Loser-Programmierer. [...]

Dein arrogantes Gelaber (in dieser Nachricht und in anderen) interessiert
keinen Menschen. Schlag' einen anderen Ton an, oder schicke deine Kommen-
tare k�nftig nach /dev/null.
        _
     _ //
     \X/ Ralph
-- 
"And're d�rfen alles haben / d�rfen sich am Feinsten laben /
 und von eben diesen Gaben / m�cht' Herr Rossi auch was haben!"

Philipp Adelt wrote:

> >Es gibt keinen sicheren Schutz.  Auch wenn deine Funktion
> >kryptographisch akzeptiert w�re, sagen wir MD5 oder SHA, dann w�re dein
> >Programm dadurch nicht sicherer.
> Doch, sicher_er_ schon, in dem Sinne, dass es _weniger_ Leuten moeglich
> ist, a) Deinen Key innendrin zu lesen und b) die Abfrage zu umgehen.

Die Schwachstelle bei Deiner L�sung ist der Conditional Jump. Wenn
jemand die Sicherung umgehen will, entfernt er diesen einfach. Niemand
wird sich die M�he machen, Deinen Algorithmus zu entschl�sseln und
umzukehren, was in jedem Falle komplizierter ist.

Es ist also v�llig egal, welchen Verschl�sselungsalgorithmus Du
verwendest. Wenn Du die Sicherheit erh�hen willst, mu�t Du zuerst einmal
den Conditional Jump durch etwas besseres ersetzen.

-----BEGIN PGP SIGNED MESSAGE-----

Hier auf einige Reaktionen per News und Mail zwei Klarstellungen zu meinem 
Posting von neulich.
Ich selbst, staa@cs.tu-berlin.de (Sebastian Staamann) schrieb neulich hier:
...
> unterstellen die Kryptographen "uberpolynomialen Aufwand bis zum
> Gegenbeweis.
Gemeint sind nat"urlich alle Kryptologen, nicht nur die Kryptographen. (Jaja,
wenn man deutsche und englische Literatur zum Thema geleichzeitig liest)

...
>'raussuchen w"urde. Relevant sind hier eigentlich vor allem Geschwindigkeit 
>und Lizensierung.
Lizensierung bezieht sich hier auf den Hash-Algorithmus, der ja auch
patentrechtlich gesch"utzt sein kann. MD5 ist aber f"ur jede Benutzung
freigegeben.

Sebastian.

# Sebastian Staamann                           fon : +49 - 30 - 314 24890 #
# Technische Universitaet Berlin               fax : +49 - 30 - 314 24891 #
# Institut fuer Kommunikations- und Softwaretechnik                       #
# http://ini.cs.tu-berlin.de/~staa/            pgp public key available   #

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQBVAwUBMZyv1bYjKRzvIqsNAQE4ZgH/Y2m4tJW4SxvjgPVsx9muW9n5mDUCyg5q
DxbmKQZ28oQIBtKIuhtQbswoxX2KUBWjFmVZa1SehxLSFHocdwoxkw==
=7VLl
-----END PGP SIGNATURE-----

SZ> Die Schwachstelle bei Deiner L�sung ist der Conditional Jump. Wenn
SZ> jemand die Sicherung umgehen will, entfernt er diesen einfach. Niemand
SZ> wird sich die M�he machen, Deinen Algorithmus zu entschl�sseln und
SZ> umzukehren, was in jedem Falle komplizierter ist.

SZ> Es ist also v�llig egal, welchen Verschl�sselungsalgorithmus Du
SZ> verwendest. Wenn Du die Sicherheit erh�hen willst, mu�t Du zuerst
SZ> einmal den Conditional Jump durch etwas besseres ersetzen.

Er k�nnte ja eine oder mehrere essentielle Funktionen in den Key auslagern,
das Ganze nat�rlich codiert. Dekodiert wird mit einem Schl�ssel, der aus
den Userdaten gewonnen wird.

Selbstmodifizierender Code ist zwar nicht sch�n, funktioniert aber.


Flo
--
NP: Pop Will Eat Itself - Mother

Florian Faber (faber@faba.han.de) wrote:

: SZ> Die Schwachstelle bei Deiner L�sung ist der Conditional Jump. Wenn
: SZ> jemand die Sicherung umgehen will, entfernt er diesen einfach. Niemand
: SZ> wird sich die M�he machen, Deinen Algorithmus zu entschl�sseln und
: SZ> umzukehren, was in jedem Falle komplizierter ist.

: SZ> Es ist also v�llig egal, welchen Verschl�sselungsalgorithmus Du
: SZ> verwendest. Wenn Du die Sicherheit erh�hen willst, mu�t Du zuerst
: SZ> einmal den Conditional Jump durch etwas besseres ersetzen.

: Er k�nnte ja eine oder mehrere essentielle Funktionen in den Key auslagern,
: das Ganze nat�rlich codiert. Dekodiert wird mit einem Schl�ssel, der aus
: den Userdaten gewonnen wird.

: Selbstmodifizierender Code ist zwar nicht sch�n, funktioniert aber.


Aber nicht mehr mit PipeLine unter hoeheren Prozessoren, also Finger weg
davon, das gibt boese Abstuerze.
 
						Danny

Sagt der Pessimist: "Es ist schon so schlimm, es kann nicht mehr schlimmer
                     werden."
Sagt der Optimist: "Oh DOCH !!!"

BADMAN@TBX.berlinet.de (Boris Wylutzki) wrote:
...
>Ich m�chte f�r ein Sharewareprogramm ein Registrier-key-System entwickeln.  
...
>Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode
>verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten
>verkommerzialisert ist werdet Ihr merken, dass Geld nicht von alleine
>programmiert.

Wie passt das zusammen?

On 16 May 1996 22:39:10 GMT, leitner@xorn.prz.tu-berlin.de (Felix von Leitner)
wrote:

>> Du sitzt heute wieder mal auf sehr hohem Ro�, was?
>
>Wer Unsinn behauptet, wird geplonkt.

Na, dann versenke mich doch endlich in deinem Killfile!

>*plonk*

Na also, haben wir's endlich hinter uns...
-- 
Ciao... Sven    |  Internet:    sbs@psbs.franken.de
Herzogenaurach  |  CompuServe:  Sven B. Schreiber 100557,177
Germany         |  MS Network:  sbs_msn@msn.com
http://www.geocities.com/CapitolHill/1441/index.html

Danny Lade (lade@paxp01.mipool.uni-jena.de) wrote:
: : SZ> Es ist also v�llig egal, welchen Verschl�sselungsalgorithmus Du
: : SZ> verwendest. Wenn Du die Sicherheit erh�hen willst, mu�t Du zuerst
: : SZ> einmal den Conditional Jump durch etwas besseres ersetzen.
: : Er k�nnte ja eine oder mehrere essentielle Funktionen in den Key auslagern,
: : das Ganze nat�rlich codiert. Dekodiert wird mit einem Schl�ssel, der aus
: : den Userdaten gewonnen wird.
: Aber nicht mehr mit PipeLine unter hoeheren Prozessoren, also Finger weg
: davon, das gibt boese Abstuerze.

Die Frage ist nur, ob hier der Aufwand dem Nutzen gerecht wird :-) Ein
kleines Biorythmus-Sharewareprogramm (und um irgend so ein kleines Projekt
ging es ja auch am Anfang des Threads) so zu schuetzen ist wie mit Kanonen
auf Spatzen zu schiessen. Leute bleibt auf dem Teppich und ueberlegt euch
eine anwendbare Loesung :-)

-- rhoenie@rhohost.franken.de -----------------------------------------------
rhoenie@rhoen.com        Marcus Herbert, Mergentheimer Strasse 120, Wuerzburg 
#chillout,#muenster    http://www.franken.de/users/rhohost/rhoenie/index.html
-----------------------------------------------------------------------------
       +-:-) : User is the Pope or holds some other religious office.
-----------------------------------------------------------------------------

Der Weltraum. Unendliche Weiten. Wir schreiben den _19.05.96._
"Captain _Konstantin_, ich empfange ein Signal aus dem Sektor _'/Z-NETZ/SPRACHEN/ALGORITHMEN'_. Es k�nnte sich um _'Re: Wie Pruefsumme?'_ handeln." - "Auf den Schirm!"

 > Psycho            Multiple-Choice-Psychotest-Interpreter unter Unix
 > <Name vergessen>  Eliza-artiges Pseudo-KI-Chatprogramm unter UNIX, DOS
 > Adventure         Text-Adventure-Skript-Interpreter unter UNIX
 >                   (die erste Implementierung zur Scroll-Routine kam
 >                   �brigens von mir, gelle, Boris :)
 > <Name vergessen>  File-Split-Tool unter DOS

   TMCount           Grafisch aufbereiteter Geb�hrenz�hler der neuen
                     Geb�hren unter DOS.
   REP               Multipel-Search&Repleace-Tool mit 'CeWL-DeZiGN' :)

   und noch'n paar kleinere Sachen...

 ... obwohl ich eigentlch auf keins der Programme richtig stolz bin... nur  
ich habe *eine Menge* zeit investiert.. n�chte durchprogrammiert usw.

 > Ich wei� nicht, woran er z.Z. arbeitet, ebenso kenne ich seine
 > anderen Programme auch nicht alle, aber das war 'mal ein kleiner
 > Auszug. Also bitte etwas weniger aufgeblasen, der Herr!

Im moment arbeite ich an meinem gr��ten Projekt: MULTICOM, Ein
Mehrbenutzerbetriebssystem f�r DOS mit Passwortabfrage beim anmelden, Mail
und News-System, Restricted Shell, uvm... daf�r soll �brigens auch der Reg-
Key sein, weil mir mein alter zu unsicher erschien. Der Key soll �brigens
f�r schlappe 8 DM zu haben sein.... Wenn ich das Prog je fertig kriege
(ich sitze Tag und nach dran).

Bye!

             ---===<<< E-Mail: BADMAN@TBX.berlinet.de >>>===---

On Tue, 28 May 1996 17:25:00 +0100, Boris Wylutzki <BADMAN@TBX.berlinet.de> wrote:
>    REP               Multipel-Search&Repleace-Tool mit 'CeWL-DeZiGN' :)

Oh Mein Gott!

>  ... obwohl ich eigentlch auf keins der Programme richtig stolz bin... nur  
> ich habe *eine Menge* zeit investiert.. n�chte durchprogrammiert usw.

Das macht dir ja auch keiner streitig!

> Im moment arbeite ich an meinem gr��ten Projekt: MULTICOM, Ein
> Mehrbenutzerbetriebssystem f�r DOS

Haha.  Ein "Betriebssystem f�r DOS".  Sehr witzig.

Mann, DOS *IST* EIN BETRIEBSSYSTEM!  Man kann nicht ein Betriebssystem
f�r DOS schreiben.  Entweder man schreibt ein Programm f�r DOS, oder man
schreibt ein Betriebssystem.

> mit Passwortabfrage beim anmelden,

kewl!

> Mail und News-System, Restricted Shell, uvm... daf�r soll �brigens
> auch der Reg- Key sein, weil mir mein alter zu unsicher erschien. Der
> Key soll �brigens f�r schlappe 8 DM zu haben sein.... Wenn ich das
> Prog je fertig kriege (ich sitze Tag und nach dran).

Und du meinst, die 8 DM pro Benutzer sind es wert, da potentiell nicht
arbeitenden und zu wartenden Code einzubauen, der deinen Key pr�ft und
am Ende doch geknackt werden wird, wenn dein Programm was wert ist?

Felix

-- 
There's no such thing as a free lunch.
	--Milton Friendman

In article <slrn4qmuc2.93b.leitner@xorn.prz.tu-berlin.de>,
Felix von Leitner <leitner@prz.tu-berlin.de> wrote:
>> Im moment arbeite ich an meinem gr��ten Projekt: MULTICOM, Ein
>> Mehrbenutzerbetriebssystem f�r DOS
>
>Haha.  Ein "Betriebssystem f�r DOS".  Sehr witzig.
>
>Mann, DOS *IST* EIN BETRIEBSSYSTEM!  Man kann nicht ein Betriebssystem
>f�r DOS schreiben.  Entweder man schreibt ein Programm f�r DOS, oder man
>schreibt ein Betriebssystem.

Das kommt darauf an, ob man "Betriebssystem" wie zu Anfang der 70er Jahre
definiert oder eine zeitgem��e Definition verwendet.

Denn eigentlich ist man l�ngst davon losgekommen, als Betriebssystem
ausschlie�lich nur diejenige Software zu bezeichnen, die direkt auf
die Hardware aufsetzt.

Heutzutage definiert sich ein Betriebssystem im allgemeinen nicht mehr
dar�ber, worauf es l�uft, sondern welche "virtuelle Maschine", welche
System-Abstraktionen es seinen Anwendungen als Ausf�hrungsumgebung zur
Verf�gung stellt (bei UNIX ist das z.B. das Proze�modell und die
Systemcalls).  Dabei kann ein Betriebssystem gerne -- und de facto ist
das so gut wie immer der Fall -- auf eine weitere virtuelle Maschine
aufsetzen -- also Anwendung f�r ein anderes Betriebsssytem sein.

Ein Beispiel f�r ein weitverbreitetes Betriebssystem, das auf MS-DOS
aufsetzt ist MS-Windows 3.X (was auch immer man davon halten mag).  MACH
und VM sind in Beispiele f�r Betriebssysteme, die gerade f�r den Zweck
geschaffen wurden, Plattformen f�r darauf aufsetzende andere
Betriebssysteme zu sein.  Das BIOS bei IBM-kompatiblen PCs oder die
PowerPC-Plattform (PPCP) sind Beispiele f�r sehr hardware-nahe
"Betriebssysteme".
-- 
�Sind das die Linguisten?  Furchtbar!  Die furchtbaren Weiber!
Ja.  Ich kenn' die!  Das sind richtige Terroristen - geistige!�
	-- ein �lterer Passant �ber ein �ffentliches Seminar
	   der TU-Kulturwissenschaftler(innen)

Thipor Kong wrote in reply to Felix v. Leitner's posting:

> >Mann, DOS *IST* EIN BETRIEBSSYSTEM!  Man kann nicht ein Betriebssystem
> >f�r DOS schreiben.  Entweder man schreibt ein Programm f�r DOS, oder man
> >schreibt ein Betriebssystem.

> 
> Das kommt darauf an, ob man "Betriebssystem" wie zu Anfang der 70er Jahre
> definiert oder eine zeitgem��e Definition verwendet.

Da stimme ich Thipor teilweise zu. Ich verwende im Grundstudium (3.
Semester) folgende Simpel-Definition, die ich hier zur Diskussion
stelle:

"Betriebssystem" ist die zusammenfassende Bezeichnung fuer alle
Programme, die die Ausfuehrung der Benutzerprogramme, die Verteilung
der Betriebsmittel auf die einzelnen Benutzerprogramme und die
Aufrechterhaltung der Betriebsart steuern und ueberwachen.
						(DUDEN Informatik)

Windows waere demnach eine Komponente eines Betriebssystems (Verwaltung
von Resourcen). Allerdings ueberwacht MS-DOS/Windows nicht die
Aufrechterhaltung der Betriebsart (Singeluser Dialogbetrieb) und es ist
daher nur mit vorbehalt als ein Betriebssystem nach obiger Def. zu
bezeichnen.

Meinungen?

Gruesze Gregor
---
Gregor Engelmeier                   | Tel.:   +49 (30) 314-73419
TU-Berlin                           | e-mail: gregor@cs.tu-berlin.de

supergau@cs.tu-berlin.de (Thipor Kong) writes:

 | Das kommt darauf an, ob man "Betriebssystem" wie zu Anfang der 70er Jahre
 | definiert oder eine zeitgem��e Definition verwendet.
 | 
 | Denn eigentlich ist man l�ngst davon losgekommen, als Betriebssystem
 | ausschlie�lich nur diejenige Software zu bezeichnen, die direkt auf
 | die Hardware aufsetzt.
 | 
 | Heutzutage definiert sich ein Betriebssystem im allgemeinen nicht mehr
 | dar�ber, worauf es l�uft, sondern welche "virtuelle Maschine", welche
 | System-Abstraktionen es seinen Anwendungen als Ausf�hrungsumgebung zur
 | Verf�gung stellt (bei UNIX ist das z.B. das Proze�modell und die
 | Systemcalls).  Dabei kann ein Betriebssystem gerne -- und de facto ist
 | das so gut wie immer der Fall -- auf eine weitere virtuelle Maschine
 | aufsetzen -- also Anwendung f�r ein anderes Betriebsssytem sein.
 | 
 | Ein Beispiel f�r ein weitverbreitetes Betriebssystem, das auf MS-DOS
 | aufsetzt ist MS-Windows 3.X (was auch immer man davon halten mag).  MACH
 | und VM sind in Beispiele f�r Betriebssysteme, die gerade f�r den Zweck
 | geschaffen wurden, Plattformen f�r darauf aufsetzende andere
 | Betriebssysteme zu sein.  Das BIOS bei IBM-kompatiblen PCs oder die
 | PowerPC-Plattform (PPCP) sind Beispiele f�r sehr hardware-nahe
 | "Betriebssysteme".

interessanter als eine definierende Abgrenzung des Betriebssystems 
nach unten ist die Frage, wie weit hoch in einem referentiellen 
Schichtenmodell noch zum Betriebssystem gehoerige Bereiche 
zu finden sind.

Gehoert z.B. Clientsoftware wie netscape oder Mosaic noch
zum Betriebssytem? Geben Sun mit java oder Microsoft mit
OLE/Explorer hier Richtungen an?

Fragt sich,
      Benedikt.