https://glossar.hs-augsburg.de/w/api.php?action=feedcontributions&feedformat=atom&user=ChrissGlossarWiki - Benutzerbeiträge [de-formal]2026-07-16T15:54:08ZBenutzerbeiträgeMediaWiki 1.43.3https://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=4621McEliece-Kryptosystem2006-07-06T21:49:52Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
{| cellspacing="3" <br />
!colspan="3" align="left" | Systemparameter<br />
|-<br />
|<math>m</math> || <math>=10</math> || Größe, definiert, Vorgabe von McEliece<br />
|-<br />
|<math>t</math> || <math>=50</math> || Max. Fehleranzahl , definiert, Vorgabe von McEliece<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>n</math> || <math>=2^m</math> || Chiffretext-Blocklänge<br />
|-<br />
|<math>k</math> || <math>=n-mt</math> || Plaintext-Blocklänge<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Schlüssel-Erzeugung<br />
|-<br />
|<math>G</math> || &nbsp; || <math>k \times n</math> Generator-Matrix (erzeugt <math>C</math>) <br />
|-<br />
|<math>S</math> || &nbsp; || <math>k \times k</math> Scramble-Matrix (zufällig, nicht singulär)<br />
|-<br />
|<math>P</math> || &nbsp; || <math>n \times n</math> Permutations-Matrix (zufällig)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>\hat{G}</math> || <math>=SGP</math> || <math>k \times n</math> Matrix<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>K_{pub}</math> || <math>=(\hat{G},t)</math> || Public Key<br />
|-<br />
|<math>K_{prv}</math> || <math>=(G,S,P)</math> || Private Key<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Verschlüsselung<br />
|-<br />
|<math>m</math> || <math>\in (Z_2)^k</math> || Klartext<br />
|-<br />
|<math>z</math> || <math>\in (Z_2)^n</math> || Fehlervektor (zufällig, maximal <math>t</math> Einsen)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>e_K(m,z)</math> || <math>=c=m\hat{G}+z</math> || Verschlüsselungsfunktion<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Entschlüsselung<br />
|-<br />
|<math>\hat{c}</math> || <math>=cP^{-1}</math> || Inverse Permutation<br />
|-<br />
|<math>\hat{m}</math> || <math>=decode(\hat{c})</math> || Goppa-Code dekodieren<br />
|-<br />
|<math>m</math> || <math>=\hat{m}S^{-1}</math> || Klartext<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>d_K(c)</math> || <math>=m=decode(cP^{-1}) \cdot S^{-1}</math> || Gesamte Entschlüsselungsfunktion<br />
|-<br />
|}<br />
<br />
<br />
==Vorteile, Nachteile und Probleme==<br />
Der McEliece Algorithmus war einer der ersten Public-Key-Verfahren und bis heute gab es keine erfolgreichen Angriffe dagegen. Zudem ist die Geschwindigkeit etwa um zwei bis drei Größenordnungen höher als bei RSA [Sch96].<br />
<br />
Daß dieses System nie wirklich im praktischen Einsatz verwendet wurde, liegt an den schwerwiegenden Nachteilen. Gehen wir von dem von McEliece definierten Kryptosystem mit <math>(1024, 524, 101)</math> aus:<br />
<br />
Zum einen ist der öffentliche Schlüssel extrem lang. <math>\hat{G}</math> ist eine Matrix der Größe <math>k \times n</math>. Damit ist der Public Key <math>k \cdot n</math>=536576 Bit lang, dies sind immerhin 65.5 kB.<br />
<br />
Zum anderen ist die Chiffre fast doppelt so groß wie der Klartext. Pro 524 Bit Klartext entstehen 1024 Bit Chiffre. Das ist eine Gesamtlänge von 195%.<br />
<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel:<br />
* [[McEliece-Kryptosystem Beispieldurchlauf]]<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
<br />
==Quellen==<br />
===McEliece Kryptosystem===<br />
* [St95] Douglas Stinson, Cryptography. Theory and Practice, CRC Press, 1995, ISBN: 0-84938-521-0, Seite 193 ff.<br />
* [Sch96] Bruce Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, 2nd ed., John Wiley & Sons Inc., 1996, ISBN: 0-471-12845-7, Seite 479 ff.<br />
* [WiME05] Wikipedia, McEliece Cryptosystem, Wikipedia, The Free Encyclopedia, 23. Dec. 2005 10:39 UTC, http://en.wikipedia.org/w/index.php?title=McEliece_cryptosystem&oldid=32471204<br />
* [En06] ENTROPY, McEliece, Error-correcting Codes als Public Key Verfahren, 01.04.2006, http://entropy.stop1984.com/de/mceliece.html<br />
* [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press Inc., 1996, ISBN: 0849385237<br />
<br />
===Goppa-Code===<br />
* [Pr98] Oliver Pretzel, Codes and Algebraic Curves, Clarendon Press, Oxford, 1998, ISBN: 0-19-850039-4, Seite 3 ff., 7 ff., 48 ff., 60 ff., 71 ff., 174 ff.<br />
* [WiG05] Wikipedia, Goppa Code, Wikipedia, The Free Encyclopedia, 9 Nov. 2005 09:49 UTC, http://en.wikipedia.org/w/index.php?title=Goppa_code&oldid=27806400<br />
* [HP03] W. Cary Huffman, Vera Pless, Fundamentals of Error-Correcting Codes, Cambridge University Press, 2003, ISBN: 0-521-78280-5, Seite 521 ff.<br />
<br />
===Elliptische Kurven===<br />
* [St02] Douglas Stinson, Cryptography. Theory and Practice, 2nd ed., CRC Press, 2002, ISBN: 1-58488-206-9, Seite 247 ff.<br />
* [Wä04] Dietmar Wätjen, Kryptographie. Grundlagen, Algorithmen, Protokolle, Spektrum Akademischer Verlag, 2004, ISBN: 3-8274-1431-8, Seite 241 ff.<br />
<br />
===Sonstige===<br />
* [WiH06] Wikipedia, Hamming-Abstand, Wikipedia, The Free Encyclopedia, 20. April 2006, 12:47 UTC, http://de.wikipedia.org/w/index.php?title=Hamming-Abstand&oldid=15841561<br />
<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem_Beispieldurchlauf&diff=4625McEliece-Kryptosystem Beispieldurchlauf2006-07-06T21:46:52Z<p>Chriss: </p>
<hr />
<div>Dieser Artikel zeigt einen Beispieldurchlauf für das[[McEliece-Kryptosystem]].<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel. Nachfolgend soll ein Bespiel für ein sehr kleines <math>(n,k,d)=(7,4,3)</math> [[McEliece-Kryptosystem]] durchgerechnet werden. Dieses Beispiel baut auf dem in [St95] auf.<br />
<br />
==Systemparameter==<br />
Die Systemparameter wurden mit <math>n=7</math>, <math>k=4</math> und <math>d=3</math> festgelegt. Damit werden 4 Klartext-Bit auf 7 Chiffre-Bit abgebildet. Weiter braucht der verwendete Code einen Hamming-Abstand von 3. Damit lassen sich <math>t=(d-1)/2=1</math> Bitfehler korrigieren.<br />
<br />
==Schlüssel-Erzeugung==<br />
Um das nachfolgende Beispiel einfacher zu halten, erzeugt die Generator-Matrix <math>G</math> keinen Goppa-Code sondern einen Hamming-Code:<br />
<br />
:<math>G=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Hier sieht man, daß <math>d=3</math> gilt, denn jede Zeile unterscheidet sich in mindesten 3 Werten voneinander.<br />
<br />
<br />
Bob erzeugt weiter die zufälligen Matrizen <math>S</math> und <math>P</math>:<br />
<br />
:<math>S=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
:<math>P=\begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
Der erste Teil <math>\hat{G}</math> des öffentlichen Schlüssels berechnet sich wie folgt:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
:<math>\hat{G}=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 & 0 & 0 & 1 \\ 1 & 1 & 0 & 0 & 0 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix}=\hat{G}</math><br />
<br />
<br />
Bob’s öffentlicher Schlüssel lautet nun:<br />
<br />
:<math>K_{pub}=(\hat{G},t)=\left(\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix},1\right)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Alice möchte ihre Nachricht <math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> nun verschlüsseln. Dazu muß noch ein beliebiger Fehlervektor <math>z</math> mit dem maximalen Gewicht <math>t=1</math> und der Länge <math>n=7</math> gewählt werden. In diesem Durchlauf soll <math>z=\begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> sein. Die Chiffre <math>c</math> berechnet sich nun mit<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
<br />
:<math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 0 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix}=c</math><br />
<br />
<br />
==Entschlüsselung==<br />
Nach dem Empfang der Chiffre muß Bob zuerst die Permutation rückgängig machen:<br />
<br />
:<math>\hat{c}=cP^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix} \cdot \begin{pmatrix} 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \\ 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Anschließend wird der Hamming-Code dekodiert. Dazu wird für jede Zeile der Generator-Matrix <math>G</math> der Hamming-Abstand <math>d</math> berechnet. Von der ersten zur vierten Zeile beträgt der Abstand <math>\begin{pmatrix} 1 & 3 & 3 & 2 \end{pmatrix}</math>. Damit ist der dekodierte Code <math>\hat{m}=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix}</math>. Zuletzt wird der Klartext <math>m</math> berechnet:<br />
<br />
<br />
:<math>m=\hat{m}S^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 1 & 0 & 0 \\ 0 & 1 & 1 & 1 \\ 1 & 0 & 0 & 1 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Damit wurde Alice’s Klartext <math>\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> erfolgreich wiederhergestellt.<br />
<br />
<br />
==Quellen==<br />
* [[McEliece-Kryptosystem]]<br />
* [St95] Douglas Stinson, Cryptography. Theory and Practice, CRC Press, 1995, ISBN: 0-84938-521-0, Seite 193 ff.<br />
* [Sch96] Bruce Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, 2nd ed., John Wiley & Sons Inc., 1996, ISBN: 0-471-12845-7, Seite 479 ff.<br />
* [WiME05] Wikipedia, McEliece Cryptosystem, Wikipedia, The Free Encyclopedia, 23. Dec. 2005 10:39 UTC, http://en.wikipedia.org/w/index.php?title=McEliece_cryptosystem&oldid=32471204<br />
* [En06] ENTROPY, McEliece, Error-correcting Codes als Public Key Verfahren, 01.04.2006, http://entropy.stop1984.com/de/mceliece.html<br />
* [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press Inc., 1996, ISBN: 0849385237<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2638Subversion2006-07-06T12:02:23Z<p>Chriss: </p>
<hr />
<div>==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten [[Diff|Diffs]] erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher [[Datenbank]]-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über [[Netzwerk|Netzwerke]] gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-[[Server]]. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Client-Zugriff==<br />
Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].<br />
<br />
Der [[Workspace]] ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.<br />
<br />
Ein [[Checkout]] ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon: <br />
<br />
<code>svn co svn://<server>/<repository></code><br />
<br />
Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte [[Revision|Revisionsstand]].<br />
<br />
Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:<br />
<br />
<code>svn add <Datei-/Pfadname> …</code><br />
<br />
Der Unterschied zwischen zwei Versionen einer Datei ist nun ein [[Diff]]. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand ''i'' auf den neueren Stand ''i''+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein [[Patch]] ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.<br />
<br />
Ein [[Commit]] (Check-In) ist ein [[Diff]] des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.<br />
<br />
Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:<br />
<br />
<code>svn ci -m "<Log-Message>"</code><br />
<br />
Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.<br />
<br />
Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein [[Merge-Konflikt]] auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.<br />
<br />
Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:<br />
<br />
<code>svn up</code><br />
<br />
Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.<br />
<br />
Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem_Beispieldurchlauf&diff=2543McEliece-Kryptosystem Beispieldurchlauf2006-07-06T01:00:58Z<p>Chriss: </p>
<hr />
<div>Dieser Artikel zeigt einen Beispieldurchlauf für das[[McEliece-Kryptosystem]].<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel. Nachfolgend soll ein Bespiel für ein sehr kleines <math>(n,k,d)=(7,4,3)</math> [[McEliece-Kryptosystem]] durchgerechnet werden. Dieses Beispiel baut auf dem in [St95] auf.<br />
<br />
==Systemparameter==<br />
Die Systemparameter wurden mit <math>n=7</math>, <math>k=4</math> und <math>d=3</math> festgelegt. Damit werden 4 Klartext-Bit auf 7 Chiffre-Bit abgebildet. Weiter braucht der verwendete Code einen Hamming-Abstand von 3. Damit lassen sich <math>t=(d-1)/2=1</math> Bitfehler korrigieren.<br />
<br />
==Schlüssel-Erzeugung==<br />
Um das nachfolgende Beispiel einfacher zu halten, erzeugt die Generator-Matrix <math>G</math> keinen Goppa-Code sondern einen Hamming-Code:<br />
<br />
:<math>G=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Hier sieht man, daß <math>d=3</math> gilt, denn jede Zeile unterscheidet sich in mindesten 3 Werten voneinander.<br />
<br />
<br />
Bob erzeugt weiter die zufälligen Matrizen <math>S</math> und <math>P</math>:<br />
<br />
:<math>S=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
:<math>P=\begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
Der erste Teil <math>\hat{G}</math> des öffentlichen Schlüssels berechnet sich wie folgt:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
:<math>\hat{G}=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 & 0 & 0 & 1 \\ 1 & 1 & 0 & 0 & 0 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix}=\hat{G}</math><br />
<br />
<br />
Bob’s öffentlicher Schlüssel lautet nun:<br />
<br />
:<math>K_{pub}=(\hat{G},t)=\left(\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix},1\right)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Alice möchte ihre Nachricht <math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> nun verschlüsseln. Dazu muß noch ein beliebiger Fehlervektor <math>z</math> mit dem maximalen Gewicht <math>t=1</math> und der Länge <math>n=7</math> gewählt werden. In diesem Durchlauf soll <math>z=\begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> sein. Die Chiffre <math>c</math> berechnet sich nun mit<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
<br />
:<math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 0 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix}=c</math><br />
<br />
<br />
==Entschlüsselung==<br />
Nach dem Empfang der Chiffre muß Bob zuerst die Permutation rückgängig machen:<br />
<br />
:<math>\hat{c}=cP^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix} \cdot \begin{pmatrix} 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \\ 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Anschließend wird der Hamming-Code dekodiert. Dazu wird für jede Zeile der Generator-Matrix <math>G</math> der Hamming-Abstand <math>d</math> berechnet. Von der ersten zur vierten Zeile beträgt der Abstand <math>\begin{pmatrix} 1 & 3 & 3 & 2 \end{pmatrix}</math>. Damit ist der dekodierte Code <math>\hat{m}=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix}</math>. Zuletzt wird der Klartext <math>m</math> berechnet:<br />
<br />
<br />
:<math>m=\hat{m}S^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 1 & 0 & 0 \\ 0 & 1 & 1 & 1 \\ 1 & 0 & 0 & 1 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Damit wurde Alice’s Klartext <math>\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> erfolgreich wiederhergestellt.<br />
<br />
<br />
==Quellen==<br />
* [[McEliece-Kryptosystem]]<br />
* [St95] Douglas Stinson, Cryptography. Theory and Practice, CRC Press, 1995, ISBN: 0-84938-521-0, Seite 193 ff.<br />
* [Sch96] Bruce Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, 2nd ed., John Wiley & Sons Inc., 1996, ISBN: 0-471-12845-7, Seite 479 ff.<br />
* [WiME05] Wikipedia, McEliece Cryptosystem, Wikipedia, The Free Encyclopedia, 23. Dec. 2005 10:39 UTC, http://en.wikipedia.org/w/index.php?title=McEliece_cryptosystem&oldid=32471204<br />
* [En06] ENTROPY, McEliece, Error-correcting Codes als Public Key Verfahren, 01.04.2006, http://entropy.stop1984.com/de/mceliece.html<br />
* [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press Inc., 1996, ISBN: 0849385237</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem_Beispieldurchlauf&diff=2458McEliece-Kryptosystem Beispieldurchlauf2006-07-06T01:00:10Z<p>Chriss: </p>
<hr />
<div>Dieser Artikel zeigt einen Beispieldurchlauf für das[[McEliece-Kryptosystem]].<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel. Nachfolgend soll ein Bespiel für ein sehr kleines <math>(n,k,d)=(7,4,3)</math> Kryptosystem durchgerechnet werden. Dieses Beispiel baut auf dem in [St95] auf.<br />
<br />
==Systemparameter==<br />
Die Systemparameter wurden mit <math>n=7</math>, <math>k=4</math> und <math>d=3</math> festgelegt. Damit werden 4 Klartext-Bit auf 7 Chiffre-Bit abgebildet. Weiter braucht der verwendete Code einen Hamming-Abstand von 3. Damit lassen sich <math>t=(d-1)/2=1</math> Bitfehler korrigieren.<br />
<br />
==Schlüssel-Erzeugung==<br />
Um das nachfolgende Beispiel einfacher zu halten, erzeugt die Generator-Matrix <math>G</math> keinen Goppa-Code sondern einen Hamming-Code:<br />
<br />
:<math>G=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Hier sieht man, daß <math>d=3</math> gilt, denn jede Zeile unterscheidet sich in mindesten 3 Werten voneinander.<br />
<br />
<br />
Bob erzeugt weiter die zufälligen Matrizen <math>S</math> und <math>P</math>:<br />
<br />
:<math>S=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
:<math>P=\begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
Der erste Teil <math>\hat{G}</math> des öffentlichen Schlüssels berechnet sich wie folgt:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
:<math>\hat{G}=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 & 0 & 0 & 1 \\ 1 & 1 & 0 & 0 & 0 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix}=\hat{G}</math><br />
<br />
<br />
Bob’s öffentlicher Schlüssel lautet nun:<br />
<br />
:<math>K_{pub}=(\hat{G},t)=\left(\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix},1\right)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Alice möchte ihre Nachricht <math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> nun verschlüsseln. Dazu muß noch ein beliebiger Fehlervektor <math>z</math> mit dem maximalen Gewicht <math>t=1</math> und der Länge <math>n=7</math> gewählt werden. In diesem Durchlauf soll <math>z=\begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> sein. Die Chiffre <math>c</math> berechnet sich nun mit<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
<br />
:<math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 0 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix}=c</math><br />
<br />
<br />
==Entschlüsselung==<br />
Nach dem Empfang der Chiffre muß Bob zuerst die Permutation rückgängig machen:<br />
<br />
:<math>\hat{c}=cP^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix} \cdot \begin{pmatrix} 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \\ 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Anschließend wird der Hamming-Code dekodiert. Dazu wird für jede Zeile der Generator-Matrix <math>G</math> der Hamming-Abstand <math>d</math> berechnet. Von der ersten zur vierten Zeile beträgt der Abstand <math>\begin{pmatrix} 1 & 3 & 3 & 2 \end{pmatrix}</math>. Damit ist der dekodierte Code <math>\hat{m}=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix}</math>. Zuletzt wird der Klartext <math>m</math> berechnet:<br />
<br />
<br />
:<math>m=\hat{m}S^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 1 & 0 & 0 \\ 0 & 1 & 1 & 1 \\ 1 & 0 & 0 & 1 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Damit wurde Alice’s Klartext <math>\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> erfolgreich wiederhergestellt.<br />
<br />
<br />
==Quellen==<br />
* [[McEliece-Kryptosystem]]<br />
* [St95] Douglas Stinson, Cryptography. Theory and Practice, CRC Press, 1995, ISBN: 0-84938-521-0, Seite 193 ff.<br />
* [Sch96] Bruce Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, 2nd ed., John Wiley & Sons Inc., 1996, ISBN: 0-471-12845-7, Seite 479 ff.<br />
* [WiME05] Wikipedia, McEliece Cryptosystem, Wikipedia, The Free Encyclopedia, 23. Dec. 2005 10:39 UTC, http://en.wikipedia.org/w/index.php?title=McEliece_cryptosystem&oldid=32471204<br />
* [En06] ENTROPY, McEliece, Error-correcting Codes als Public Key Verfahren, 01.04.2006, http://entropy.stop1984.com/de/mceliece.html<br />
* [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press Inc., 1996, ISBN: 0849385237</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem_Beispieldurchlauf&diff=2457McEliece-Kryptosystem Beispieldurchlauf2006-07-06T00:59:32Z<p>Chriss: </p>
<hr />
<div>Dieser Artikel zeigt einen Beispieldurchlauf für das[[McEliece-Kryptosystem]].<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel. Nachfolgend soll ein Bespiel für ein sehr kleines <math>(n,k,d)=(7,4,3)</math> Kryptosystem durchgerechnet werden. Dieses Beispiel baut auf dem in [St95] auf.<br />
<br />
==Systemparameter==<br />
Die Systemparameter wurden mit <math>n=7</math>, <math>k=4</math> und <math>d=3</math> festgelegt. Damit werden 4 Klartext-Bit auf 7 Chiffre-Bit abgebildet. Weiter braucht der verwendete Code einen Hamming-Abstand von 3. Damit lassen sich <math>t=(d-1)/2=1</math> Bitfehler korrigieren.<br />
<br />
==Schlüssel-Erzeugung==<br />
Um das nachfolgende Beispiel einfacher zu halten, erzeugt die Generator-Matrix <math>G</math> keinen Goppa-Code sondern einen Hamming-Code:<br />
<br />
:<math>G=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Hier sieht man, daß <math>d=3</math> gilt, denn jede Zeile unterscheidet sich in mindesten 3 Werten voneinander.<br />
<br />
<br />
Bob erzeugt weiter die zufälligen Matrizen <math>S</math> und <math>P</math>:<br />
<br />
:<math>S=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
:<math>P=\begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
Der erste Teil <math>\hat{G}</math> des öffentlichen Schlüssels berechnet sich wie folgt:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
:<math>\hat{G}=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 & 0 & 0 & 1 \\ 1 & 1 & 0 & 0 & 0 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix}=\hat{G}</math><br />
<br />
<br />
Bob’s öffentlicher Schlüssel lautet nun:<br />
<br />
:<math>K_{pub}=(\hat{G},t)=\left(\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix},1\right)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Alice möchte ihre Nachricht <math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> nun verschlüsseln. Dazu muß noch ein beliebiger Fehlervektor <math>z</math> mit dem maximalen Gewicht <math>t=1</math> und der Länge <math>n=7</math> gewählt werden. In diesem Durchlauf soll <math>z=\begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> sein. Die Chiffre <math>c</math> berechnet sich nun mit<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
<br />
:<math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 0 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix}=c</math><br />
<br />
<br />
==Entschlüsselung==<br />
Nach dem Empfang der Chiffre muß Bob zuerst die Permutation rückgängig machen:<br />
<br />
:<math>\hat{c}=cP^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix} \cdot \begin{pmatrix} 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \\ 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Anschließend wird der Hamming-Code dekodiert. Dazu wird für jede Zeile der Generator-Matrix <math>G</math> der Hamming-Abstand <math>d</math> berechnet. Von der ersten zur vierten Zeile beträgt der Abstand <math>\begin{pmatrix} 1 & 3 & 3 & 2 \end{pmatrix}</math>. Damit ist der dekodierte Code <math>\hat{m}=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix}</math>. Zuletzt wird der Klartext <math>m</math> berechnet:<br />
<br />
<br />
:<math>m=\hat{m}S^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 1 & 0 & 0 \\ 0 & 1 & 1 & 1 \\ 1 & 0 & 0 & 1 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Damit wurde Alice’s Klartext <math>\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> erfolgreich wiederhergestellt.<br />
<br />
==Quellen==<br />
* [[McEliece-Kryptosystem]]<br />
* [St95] Douglas Stinson, Cryptography. Theory and Practice, CRC Press, 1995, ISBN: 0-84938-521-0, Seite 193 ff.<br />
* [Sch96] Bruce Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, 2nd ed., John Wiley & Sons Inc., 1996, ISBN: 0-471-12845-7, Seite 479 ff.<br />
* [WiME05] Wikipedia, McEliece Cryptosystem, Wikipedia, The Free Encyclopedia, 23. Dec. 2005 10:39 UTC, http://en.wikipedia.org/w/index.php?title=McEliece_cryptosystem&oldid=32471204<br />
* [En06] ENTROPY, McEliece, Error-correcting Codes als Public Key Verfahren, 01.04.2006, http://entropy.stop1984.com/de/mceliece.html<br />
* [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press Inc., 1996, ISBN: 0849385237</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem_Beispieldurchlauf&diff=2456McEliece-Kryptosystem Beispieldurchlauf2006-07-06T00:58:54Z<p>Chriss: </p>
<hr />
<div>Dieser Artikel zeigt einen Beispieldurchlauf für das[[McEliece-Kryptosystem]].<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel. Nachfolgend soll ein Bespiel für ein sehr kleines <math>(n,k,d)=(7,4,3)</math> Kryptosystem durchgerechnet werden. Dieses Beispiel baut auf dem in [St95] auf.<br />
<br />
==Systemparameter==<br />
Die Systemparameter wurden mit <math>n=7</math>, <math>k=4</math> und <math>d=3</math> festgelegt. Damit werden 4 Klartext-Bit auf 7 Chiffre-Bit abgebildet. Weiter braucht der verwendete Code einen Hamming-Abstand von 3. Damit lassen sich <math>t=(d-1)/2=1</math> Bitfehler korrigieren.<br />
<br />
==Schlüssel-Erzeugung==<br />
Um das nachfolgende Beispiel einfacher zu halten, erzeugt die Generator-Matrix <math>G</math> keinen Goppa-Code sondern einen Hamming-Code:<br />
<br />
:<math>G=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Hier sieht man, daß <math>d=3</math> gilt, denn jede Zeile unterscheidet sich in mindesten 3 Werten voneinander.<br />
<br />
<br />
Bob erzeugt weiter die zufälligen Matrizen <math>S</math> und <math>P</math>:<br />
<br />
:<math>S=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
:<math>P=\begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
Der erste Teil <math>\hat{G}</math> des öffentlichen Schlüssels berechnet sich wie folgt:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
:<math>\hat{G}=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 & 0 & 0 & 1 \\ 1 & 1 & 0 & 0 & 0 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix}=\hat{G}</math><br />
<br />
<br />
Bob’s öffentlicher Schlüssel lautet nun:<br />
<br />
:<math>K_{pub}=(\hat{G},t)=\left(\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix},1\right)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Alice möchte ihre Nachricht <math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> nun verschlüsseln. Dazu muß noch ein beliebiger Fehlervektor <math>z</math> mit dem maximalen Gewicht <math>t=1</math> und der Länge <math>n=7</math> gewählt werden. In diesem Durchlauf soll <math>z=\begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> sein. Die Chiffre <math>c</math> berechnet sich nun mit<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
<br />
:<math>m=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 0 & 1 & 0 \end{pmatrix} + \begin{pmatrix} 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix}=c</math><br />
<br />
<br />
==Entschlüsselung==<br />
Nach dem Empfang der Chiffre muß Bob zuerst die Permutation rückgängig machen:<br />
<br />
:<math>\hat{c}=cP^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 0 & 1 & 1 & 0 & 1 & 1 & 0 \end{pmatrix} \cdot \begin{pmatrix} 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \\ 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Anschließend wird der Hamming-Code dekodiert. Dazu wird für jede Zeile der Generator-Matrix <math>G</math> der Hamming-Abstand <math>d</math> berechnet. Von der ersten zur vierten Zeile beträgt der Abstand <math>\begin{pmatrix} 1 & 3 & 3 & 2 \end{pmatrix}</math>. Damit ist der dekodierte Code <math>\hat{m}=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix}</math>. Zuletzt wird der Klartext <math>m</math> berechnet:<br />
<br />
<br />
:<math>m=\hat{m}S^{-1}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 0 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 1 & 0 & 0 \\ 0 & 1 & 1 & 1 \\ 1 & 0 & 0 & 1 \end{pmatrix}=</math> <br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Damit wurde Alice’s Klartext <math>\begin{pmatrix} 1 & 1 & 0 & 1 \end{pmatrix}</math> erfolgreich wiederhergestellt.</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem_Beispieldurchlauf&diff=2455McEliece-Kryptosystem Beispieldurchlauf2006-07-06T00:41:40Z<p>Chriss: </p>
<hr />
<div>Dieser Artikel zeigt einen Beispieldurchlauf für das[[McEliece-Kryptosystem]].<br />
<br />
==Beispieldurchlauf==<br />
Um einen Algorithmus besser verstehen zu können, hilft meist ein praktisches Beispiel. Nachfolgend soll ein Bespiel für ein sehr kleines <math>(n,k,d)=(7,4,3)</math> Kryptosystem durchgerechnet werden. Dieses Beispiel baut auf dem in [St95] auf.<br />
<br />
==Systemparameter==<br />
Die Systemparameter wurden mit <math>n=7</math>, <math>k=4</math> und <math>d=3</math> festgelegt. Damit werden 4 Klartext-Bit auf 7 Chiffre-Bit abgebildet. Weiter braucht der verwendete Code einen Hamming-Abstand von 3. Damit lassen sich <math>t=(d-1)/2=1</math> Bitfehler korrigieren.<br />
<br />
==Schlüssel-Erzeugung==<br />
Um das nachfolgende Beispiel einfacher zu halten, erzeugt die Generator-Matrix <math>G</math> keinen Goppa-Code sondern einen Hamming-Code:<br />
<br />
:<math>G=\begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix}</math> <br />
<br />
<br />
Hier sieht man, daß <math>d=3</math> gilt, denn jede Zeile unterscheidet sich in mindesten 3 Werten voneinander.<br />
<br />
<br />
Bob erzeugt weiter die zufälligen Matrizen <math>S</math> und <math>P</math>:<br />
<br />
:<math>S=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
:<math>P=\begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}</math> <br />
<br />
<br />
Der erste Teil <math>\hat{G}</math> des öffentlichen Schlüssels berechnet sich wie folgt:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
:<math>\hat{G}=\begin{pmatrix} 1 & 1 & 0 & 1 \\ 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 \\ 1 & 1 & 0 & 0 \end{pmatrix} \cdot \begin{pmatrix} 1 & 0 & 0 & 0 & 1 & 1 & 0 \\ 0 & 1 & 0 & 0 & 1 & 0 & 1 \\ 0 & 0 & 1 & 0 & 0 & 1 & 1 \\ 0 & 0 & 0 & 1 & 1 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 0 & 1 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 0 & 0 & 1 \\ 0 & 1 & 1 & 1 & 0 & 0 & 1 \\ 1 & 1 & 0 & 0 & 0 & 1 & 1 \end{pmatrix} \cdot \begin{pmatrix} 0 & 1 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 0 & 1 \\ 1 & 0 & 0 & 0 & 0 & 0 & 0 \\ 0 & 0 & 1 & 0 & 0 & 0 & 0 \\ 0 & 0 & 0 & 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 0 & 1 & 0 & 0 \end{pmatrix}=</math><br />
<br />
<br />
:<math>=\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix}=\hat{G}</math><br />
<br />
<br />
Bob’s öffentlicher Schlüssel lautet nun:<br />
<br />
:<math>K_{pub}=(\hat{G},t)=\left(\begin{pmatrix} 1 & 1 & 1 & 1 & 0 & 0 & 0 \\ 1 & 1 & 0 & 0 & 1 & 0 & 0 \\ 1 & 0 & 0 & 1 & 1 & 0 & 1 \\ 0 & 1 & 0 & 1 & 1 & 1 & 0 \end{pmatrix},1\right)</math></div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2544McEliece-Kryptosystem2006-07-06T00:18:28Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
{| cellspacing="3" <br />
!colspan="3" align="left" | Systemparameter<br />
|-<br />
|<math>m</math> || <math>=10</math> || Größe, definiert, Vorgabe von McEliece<br />
|-<br />
|<math>t</math> || <math>=50</math> || Max. Fehleranzahl , definiert, Vorgabe von McEliece<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>n</math> || <math>=2^m</math> || Chiffretext-Blocklänge<br />
|-<br />
|<math>k</math> || <math>=n-mt</math> || Plaintext-Blocklänge<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Schlüssel-Erzeugung<br />
|-<br />
|<math>G</math> || &nbsp; || <math>k \times n</math> Generator-Matrix (erzeugt <math>C</math>) <br />
|-<br />
|<math>S</math> || &nbsp; || <math>k \times k</math> Scramble-Matrix (zufällig, nicht singulär)<br />
|-<br />
|<math>P</math> || &nbsp; || <math>n \times n</math> Permutations-Matrix (zufällig)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>\hat{G}</math> || <math>=SGP</math> || <math>k \times n</math> Matrix<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>K_{pub}</math> || <math>=(\hat{G},t)</math> || Public Key<br />
|-<br />
|<math>K_{prv}</math> || <math>=(G,S,P)</math> || Private Key<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Verschlüsselung<br />
|-<br />
|<math>m</math> || <math>\in (Z_2)^k</math> || Klartext<br />
|-<br />
|<math>z</math> || <math>\in (Z_2)^n</math> || Fehlervektor (zufällig, maximal <math>t</math> Einsen)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>e_K(m,z)</math> || <math>=c=m\hat{G}+z</math> || Verschlüsselungsfunktion<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Entschlüsselung<br />
|-<br />
|<math>\hat{c}</math> || <math>=cP^{-1}</math> || Inverse Permutation<br />
|-<br />
|<math>\hat{m}</math> || <math>=decode(\hat{c})</math> || Goppa-Code dekodieren<br />
|-<br />
|<math>m</math> || <math>=\hat{m}S^{-1}</math> || Klartext<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>d_K(c)</math> || <math>=m=decode(cP^{-1}) \cdot S^{-1}</math> || Gesamte Entschlüsselungsfunktion<br />
|-<br />
|}<br />
<br />
<br />
==Vorteile, Nachteile und Probleme==<br />
Der McEliece Algorithmus war einer der ersten Public-Key-Verfahren und bis heute gab es keine erfolgreichen Angriffe dagegen. Zudem ist die Geschwindigkeit etwa um zwei bis drei Größenordnungen höher als bei RSA [Sch96].<br />
<br />
Daß dieses System nie wirklich im praktischen Einsatz verwendet wurde, liegt an den schwerwiegenden Nachteilen. Gehen wir von dem von McEliece definierten Kryptosystem mit <math>(1024, 524, 101)</math> aus:<br />
<br />
Zum einen ist der öffentliche Schlüssel extrem lang. <math>\hat{G}</math> ist eine Matrix der Größe <math>k \times n</math>. Damit ist der Public Key <math>k \cdot n</math>=536576 Bit lang, dies sind immerhin 65.5 kB.<br />
<br />
Zum anderen ist die Chiffre fast doppelt so groß wie der Klartext. Pro 524 Bit Klartext entstehen 1024 Bit Chiffre. Das ist eine Gesamtlänge von 195%.<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
<br />
==Quellen==<br />
===McEliece Kryptosystem===<br />
* [St95] Douglas Stinson, Cryptography. Theory and Practice, CRC Press, 1995, ISBN: 0-84938-521-0, Seite 193 ff.<br />
* [Sch96] Bruce Schneier, Applied Cryptography, Protocols, Algorithms and Source Code in C, 2nd ed., John Wiley & Sons Inc., 1996, ISBN: 0-471-12845-7, Seite 479 ff.<br />
* [WiME05] Wikipedia, McEliece Cryptosystem, Wikipedia, The Free Encyclopedia, 23. Dec. 2005 10:39 UTC, http://en.wikipedia.org/w/index.php?title=McEliece_cryptosystem&oldid=32471204<br />
* [En06] ENTROPY, McEliece, Error-correcting Codes als Public Key Verfahren, 01.04.2006, http://entropy.stop1984.com/de/mceliece.html<br />
* [MOV96] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone, Handbook of Applied Cryptography, CRC Press Inc., 1996, ISBN: 0849385237<br />
<br />
===Goppa-Code===<br />
* [Pr98] Oliver Pretzel, Codes and Algebraic Curves, Clarendon Press, Oxford, 1998, ISBN: 0-19-850039-4, Seite 3 ff., 7 ff., 48 ff., 60 ff., 71 ff., 174 ff.<br />
* [WiG05] Wikipedia, Goppa Code, Wikipedia, The Free Encyclopedia, 9 Nov. 2005 09:49 UTC, http://en.wikipedia.org/w/index.php?title=Goppa_code&oldid=27806400<br />
* [HP03] W. Cary Huffman, Vera Pless, Fundamentals of Error-Correcting Codes, Cambridge University Press, 2003, ISBN: 0-521-78280-5, Seite 521 ff.<br />
<br />
===Elliptische Kurven===<br />
* [St02] Douglas Stinson, Cryptography. Theory and Practice, 2nd ed., CRC Press, 2002, ISBN: 1-58488-206-9, Seite 247 ff.<br />
* [Wä04] Dietmar Wätjen, Kryptographie. Grundlagen, Algorithmen, Protokolle, Spektrum Akademischer Verlag, 2004, ISBN: 3-8274-1431-8, Seite 241 ff.<br />
<br />
===Sonstige===<br />
* [WiH06] Wikipedia, Hamming-Abstand, Wikipedia, The Free Encyclopedia, 20. April 2006, 12:47 UTC, http://de.wikipedia.org/w/index.php?title=Hamming-Abstand&oldid=15841561<br />
<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2454McEliece-Kryptosystem2006-07-06T00:11:06Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
{| cellspacing="3" <br />
!colspan="3" align="left" | Systemparameter<br />
|-<br />
|<math>m</math> || <math>=10</math> || Größe, definiert, Vorgabe von McEliece<br />
|-<br />
|<math>t</math> || <math>=50</math> || Max. Fehleranzahl , definiert, Vorgabe von McEliece<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>n</math> || <math>=2^m</math> || Chiffretext-Blocklänge<br />
|-<br />
|<math>k</math> || <math>=n-mt</math> || Plaintext-Blocklänge<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Schlüssel-Erzeugung<br />
|-<br />
|<math>G</math> || &nbsp; || <math>k \times n</math> Generator-Matrix (erzeugt <math>C</math>) <br />
|-<br />
|<math>S</math> || &nbsp; || <math>k \times k</math> Scramble-Matrix (zufällig, nicht singulär)<br />
|-<br />
|<math>P</math> || &nbsp; || <math>n \times n</math> Permutations-Matrix (zufällig)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>\hat{G}</math> || <math>=SGP</math> || <math>k \times n</math> Matrix<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>K_{pub}</math> || <math>=(\hat{G},t)</math> || Public Key<br />
|-<br />
|<math>K_{prv}</math> || <math>=(G,S,P)</math> || Private Key<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Verschlüsselung<br />
|-<br />
|<math>m</math> || <math>\in (Z_2)^k</math> || Klartext<br />
|-<br />
|<math>z</math> || <math>\in (Z_2)^n</math> || Fehlervektor (zufällig, maximal <math>t</math> Einsen)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>e_K(m,z)</math> || <math>=c=m\hat{G}+z</math> || Verschlüsselungsfunktion<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Entschlüsselung<br />
|-<br />
|<math>\hat{c}</math> || <math>=cP^{-1}</math> || Inverse Permutation<br />
|-<br />
|<math>\hat{m}</math> || <math>=decode(\hat{c})</math> || Goppa-Code dekodieren<br />
|-<br />
|<math>m</math> || <math>=\hat{m}S^{-1}</math> || Klartext<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>d_K(c)</math> || <math>=m=decode(cP^{-1}) \cdot S^{-1}</math> || Gesamte Entschlüsselungsfunktion<br />
|-<br />
|}<br />
<br />
<br />
==Vorteile, Nachteile und Probleme==<br />
Der McEliece Algorithmus war einer der ersten Public-Key-Verfahren und bis heute gab es keine erfolgreichen Angriffe dagegen. Zudem ist die Geschwindigkeit etwa um zwei bis drei Größenordnungen höher als bei RSA [Sch96].<br />
<br />
Daß dieses System nie wirklich im praktischen Einsatz verwendet wurde, liegt an den schwerwiegenden Nachteilen. Gehen wir von dem von McEliece definierten Kryptosystem mit <math>(1024, 524, 101)</math> aus:<br />
<br />
Zum einen ist der öffentliche Schlüssel extrem lang. <math>\hat{G}</math> ist eine Matrix der Größe <math>k \times n</math>. Damit ist der Public Key <math>k \cdot n</math>=536576 Bit lang, dies sind immerhin 65.5 kB.<br />
<br />
Zum anderen ist die Chiffre fast doppelt so groß wie der Klartext. Pro 524 Bit Klartext entstehen 1024 Bit Chiffre. Das ist eine Gesamtlänge von 195%.<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2453McEliece-Kryptosystem2006-07-06T00:05:20Z<p>Chriss: /* Kurzzusammenfassung */</p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
{| cellspacing="3" <br />
!colspan="3" align="left" | Systemparameter<br />
|-<br />
|<math>m</math> || <math>=10</math> || Größe, definiert, Vorgabe von McEliece<br />
|-<br />
|<math>t</math> || <math>=50</math> || Max. Fehleranzahl , definiert, Vorgabe von McEliece<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>n</math> || <math>=2^m</math> || Chiffretext-Blocklänge<br />
|-<br />
|<math>k</math> || <math>=n-mt</math> || Plaintext-Blocklänge<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Schlüssel-Erzeugung<br />
|-<br />
|<math>G</math> || &nbsp; || <math>k \times n</math> Generator-Matrix (erzeugt <math>C</math>) <br />
|-<br />
|<math>S</math> || &nbsp; || <math>k \times k</math> Scramble-Matrix (zufällig, nicht singulär)<br />
|-<br />
|<math>P</math> || &nbsp; || <math>n \times n</math> Permutations-Matrix (zufällig)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>\hat{G}</math> || <math>=SGP</math> || <math>k \times n</math> Matrix<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>K_{pub}</math> || <math>=(\hat{G},t)</math> || Public Key<br />
|-<br />
|<math>K_{prv}</math> || <math>=(G,S,P)</math> || Private Key<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Verschlüsselung<br />
|-<br />
|<math>m</math> || <math>\in (Z_2)^k</math> || Klartext<br />
|-<br />
|<math>z</math> || <math>\in (Z_2)^n</math> || Fehlervektor (zufällig, maximal <math>t</math> Einsen)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>e_K(m,z)</math> || <math>=c=m\hat{G}+z</math> || Verschlüsselungsfunktion<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Entschlüsselung<br />
|-<br />
|<math>\hat{c}</math> || <math>=cP^{-1}</math> || Inverse Permutation<br />
|-<br />
|<math>\hat{m}</math> || <math>=decode(\hat{c})</math> || Goppa-Code dekodieren<br />
|-<br />
|<math>m</math> || <math>=\hat{m}S^{-1}</math> || Klartext<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>d_K(c)</math> || <math>=m=decode(cP^{-1}) \cdot S^{-1}</math> || Gesamte Entschlüsselungsfunktion<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|}<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2452McEliece-Kryptosystem2006-07-06T00:01:31Z<p>Chriss: /* Kurzzusammenfassung */</p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
{| <br />
!colspan="3" align="left" | Systemparameter<br />
|-<br />
|<math>m</math> || <math>=10</math> || Größe, definiert, Vorgabe von McEliece<br />
|-<br />
|<math>t</math> || <math>=50</math> || Max. Fehleranzahl , definiert, Vorgabe von McEliece<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>n</math> || <math>=2^m</math> || Chiffretext-Blocklänge<br />
|-<br />
|<math>k</math> || <math>=n-mt</math> || Plaintext-Blocklänge<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Schlüssel-Erzeugung<br />
|-<br />
|<math>G</math> || &nbsp; || <math>k \times n</math> Generator-Matrix (erzeugt <math>C</math>) <br />
|-<br />
|<math>S</math> || &nbsp; || <math>k \times k</math> Scramble-Matrix (zufällig, nicht singulär)<br />
|-<br />
|<math>P</math> || &nbsp; || <math>n \times n</math> Permutations-Matrix (zufällig)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>\hat{G}</math> || <math>=SGP</math> || <math>k \times n</math> Matrix<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>K_{pub}</math> || <math>=(\hat{G},t)</math> || Public Key<br />
|-<br />
|<math>K_{prv}</math> || <math>=(G,S,P)</math> || Private Key<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Verschlüsselung<br />
|-<br />
|<math>m</math> || <math>\in (Z_2)^k</math> || Klartext<br />
|-<br />
|<math>z</math> || <math>\in (Z_2)^n</math> || Fehlervektor (zufällig, maximal <math>t</math> Einsen)<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>e_K(m,z)</math> || <math>=c=m\hat{G}+z</math> || Verschlüsselungsfunktion<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Entschlüsselung<br />
|-<br />
|<math>\hat{c}</math> || <math>=cP^{-1}</math> || Inverse Permutation<br />
|-<br />
|<math>\hat{m}</math> || <math>=decode(\hat{c})</math> || Inverse Permutation<br />
|-<br />
|<math>m</math> || <math>=\hat{m}S^{-1}</math> || Inverse Permutation<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>d_K(c)</math> || <math>=m=decode(cP^{-1}) \cdot S^{-1}</math> || Inverse Permutation<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|}<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2451McEliece-Kryptosystem2006-07-05T23:46:33Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
{| <br />
!colspan="3" align="left" | Systemparameter<br />
|-<br />
|<math>m</math> || <math>=10</math> || Größe, definiert, Vorgabe von McEliece<br />
|-<br />
|<math>t</math> || <math>=50</math> || Max. Fehleranzahl , definiert, Vorgabe von McEliece<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
|<math>n</math> || <math>=2^m</math> || Chiffretext-Blocklänge<br />
|-<br />
|<math>k</math> || <math>=n-mt</math> || Plaintext-Blocklänge<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Schlüssel-Erzeugung<br />
|-<br />
|<math>d</math> || <math>=2t+1</math> || Hamming-Abstand<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Verschlüsselung<br />
|-<br />
|<br />
|-<br />
|<br />
|-<br />
!colspan="3" align="left" | Entschlüsselung<br />
|-<br />
|<br />
|-<br />
|<br />
|}<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2446McEliece-Kryptosystem2006-07-05T23:34:48Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Kurzzusammenfassung==<br />
====Systemparameter====<br />
{| <br />
|Alpha || Beta || Gamma<br />
|-<br />
|Delta || Epsilon || Zeta<br />
|}<br />
<br />
====Schlüssel-Erzeugung====<br />
{| <br />
|Alpha || Beta || Gamma<br />
|-<br />
|Delta || Epsilon || Zeta<br />
|}<br />
<br />
====Verschlüsselung====<br />
{| <br />
|Alpha || Beta || Gamma<br />
|-<br />
|Delta || Epsilon || Zeta<br />
|}<br />
<br />
====Entschlüsselung====<br />
{| <br />
|Alpha || Beta || Gamma<br />
|-<br />
|Delta || Epsilon || Zeta<br />
|}<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2445McEliece-Kryptosystem2006-07-05T23:28:34Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
==Entschlüsselung==<br />
Zum Entschlüsseln nimmt Bob die empfangene Chiffre und berechnet zuerst ein <math>\hat{c}</math> mit:<br />
<br />
:<math>\hat{c}=cP^{-1}</math> <br />
<br />
<br />
Anschließend wird die Dekodierungsfunktion <math>decode(c)</math> des Goppa-Codes auf <math>\hat{c}</math> angewandt, um das passende <math>\hat{m}</math> zu finden. Dafür muß der Hamming-Abstand <math>d_H(\hat{m}G,\hat{c}) \le t</math> werden. Der Vorteil an Goppa-Codes ist, daß diese Operation, im Gegensatz zu linearen Codes, effizient berechnet werden kann.<br />
<br />
<br />
Zuletzt ermittelt Bob den ursprünglichen Klartext <math>m</math> mit:<br />
<br />
:<math>m=\hat{m}S^{-1}</math> <br />
<br />
<br />
Die komplette Entschlüsselungsfunktion sieht dann so aus:<br />
<br />
:<math>d_K(c)=decode(cP^{-1}) \cdot S^{-1}</math> <br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2440McEliece-Kryptosystem2006-07-05T23:21:16Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
==Verschlüsselung==<br />
Sind die Schlüssel erzeugt, kann Alice mit Hilfe des öffentlichen Schlüssels eine Nachricht verschlüsseln und an Bob senden.<br />
<br />
Dazu teilt sie zuerst ihre Nachricht in binäre Blöcke <math>m \in (\mathbb{Z}_2)^k</math> der Länge <math>k</math> auf. Anschließend verschlüsselt sie die Blöcke mit der Verschlüsselungsfunktion:<br />
<br />
:<math>e_K(m,z)=c=m\hat{G}+z</math><br />
<br />
wobei <math>z \in (\mathbb{Z}_2)^n</math> ein beliebiger Vektor der Länge <math>n</math> ist, der ein maximales Gewicht von <math>t</math> aufweist. Das bedeutet, <math>z</math> besitzt maximal <math>t</math> Einsen. Durch diesen Fehlervektor wird der Chiffretext an maximal <math>t</math> Stellen verändert, also invertiert.<br />
<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2438McEliece-Kryptosystem2006-07-05T23:15:19Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
==Schlüssel-Erzeugung==<br />
Angenommen Alice möchte Bob eine verschlüsselte Nachricht senden. Um sein Schlüsselpaar (öffentlicher und privater Schlüssel) zu erzeugen, muß Bob folgende Schritte ausführen:<br />
<br />
* Zuerst wird eine <math>k \times n</math> Generator-Matrix <math>G</math> für den Goppa-Code <math>C</math> erzeugt. Dies ist eine Matrix, mit der man aus einem binären Klartext der Bitlänge <math>k</math>, die Chiffre mit der Länge <math>n</math> berechnen kann.<br />
* Anschließend erzeugt er eine zufällige, binäre, nicht singuläre <math>k \times k</math> Scramble-Matrix <math>S</math>, die über <math>\mathbb{Z}_2</math> invertierbar ist. Nicht singulär bedeutet, daß sie regulär ist. Ihre Determinante muß also ungleich Null sein, denn nur solche Matrizen lassen sich invertieren. Eine binäre Matrix besitzt nur Elemente aus <math>\mathbb{Z}_2</math>.<br />
* Danach erzeugt er eine ebenfalls zufällige <math>n \times n</math> Permutations-Matrix <math>P</math>. Eine Permutationsmatrix ist eine binäre Matrix, die in jeder Zeile und Spalte nur genau eine 1 enthält.<br />
* Abschließend wird die <math>k \times n</math> Matrix <math>\hat G</math> berechnet:<br />
<br />
:<math>\hat{G}=SGP</math><br />
<br />
<br />
Der komplette Schlüssel K ist nun:<br />
:<math>K:=(G,S,P,\hat{G},t)</math><br />
<br />
<br />
Bob’s öffentlicher Schüssel Kpub ist:<br />
:<math>K_{pub}:=(\hat{G},t)</math><br />
<br />
<br />
Sein privater Schüssel Kprv ist:<br />
:<math>K_{prv}:=(G,S,P)</math><br />
<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2437McEliece-Kryptosystem2006-07-05T22:58:05Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
:<math>McEliece:=(m,t)</math><br />
<br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
<br />
:<math>n=2^m</math><br />
<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
<br />
:<math>k=n-mt</math><br />
<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
<br />
:<math>d=2t+1</math><br />
<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*<math>(n,k,d)</math> z.B. in [St95]<br />
*<math>(n,k,t)</math> z.B. in [Sch96]<br />
*<math>(n,t,k)</math> z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2430McEliece-Kryptosystem2006-07-05T22:46:29Z<p>Chriss: </p>
<hr />
<div>==Überblick==<br />
[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
==Definitionen==<br />
Um die oben genannten drei Verfahren anwenden zu können, müssen zuerst einige Definitionen erfolgen:<br />
<br />
===Code===<br />
Sei <math>C</math> ein binärer <math>(n, k)</math> Goppa-Code, der <math>t</math> Fehler effizient korrigieren kann.<br />
<br />
===Systemparameter===<br />
Um den Aufbau eines McEliece-Kryptosystems eindeutig zu beschreiben, sind die beiden Systemparameter <math>m</math> und <math>t</math> notwendig. <math>m</math> gibt indirekt die Blockgrößen an und <math>t</math> die maximale Anzahl der Fehler, die der verwendete Goppa-Code <math>C</math> noch fehlerfrei korrigieren kann.<br />
<br />
Ein McEliece-Kryptosystem ist also wie folgt definiert:<br />
<br />
<math>McEliece:=(m,t)</math><br />
<br />
Daraus lassen sich drei weitere Parameter berechnen:<br />
* Die Chiffretext-Blocklänge <math>n</math>:<br />
#todo<br />
* Die Plaintext-Blocklänge <math>k</math>:<br />
#todo<br />
* Der minimale Hamming-Abstand <math>d</math> des Codes <math>C</math>:<br />
#todo<br />
<br />
In der Literatur werden die Kryptosysteme meist durch eine der drei, inhaltlich äquivalenten, Notationen beschrieben:<br />
*z.B. in [St95]<br />
*z.B. in [Sch96]<br />
*z.B. in [WiME05]<br />
<br />
Nachfolgend verwende ich die erste Notation mit <math>(n,k,d)</math>.<br />
<br />
McEliece selbst schlug in seinem Original-Papier ein System mit <math>(1024, 524, 101)</math> vor, also <math>(m = 10, t = 50)</math> als minimale Konfiguration eines sicheren Algorithmus. In [MOV96] wird ein etwas unsicheres, dafür aber effizienteres System mit <math>(1024, 644, 77)</math>, also <math>(m = 10, t = 38)</math> vorgestellt.<br />
<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2426McEliece-Kryptosystem2006-07-05T22:39:34Z<p>Chriss: </p>
<hr />
<div>[[Robert McEliece]] entwickelte 1978 eines der ersten asymmetrischen [[Public-Key-Verfahren]]. <br />
<br />
Dieses baut auf allgemeinen binären linearen fehlerkorrigierenden Codes auf und versteckt absichtlich Fehler in der [[Chiffre]], um damit die [[Kryptoanalyse]] erheblich zu erschweren.<br />
<br />
Die Idee ist es, einen allgemeinen [[fehlerkorrigierenden Code]] zu verwenden. Die Dekodierung solcher Codes ist ein [[NP-Problem]]. Allerdings gibt es bestimmte Code-Untergruppen, die eine Lösung in polynomialer Zeit ermöglichen, unter anderen die auch von diesem Algorithmus verwendeten [[Goppa-Code|Goppa-Codes]]. <br />
<br />
Der [[Klartext]] wird also über eine Generator-Matrix in einen Goppa-Code umgewandelt. Dieser wird durch Multiplikation mit zufälligen weiteren [[Matrix|Matrizen]] als allgemeiner linearer Code getarnt.<br />
<br />
Ohne das Wissen der einzelnen zur Herstellung des Codes benutzter Matrizen, kann nun die Chiffre nicht mehr in den ursprünglichen Goppa-Code zurückverwandelt werden, also auch nicht mehr dekodiert werden.<br />
<br />
Der öffentliche Schlüssel beinhaltet eine Generator-Matrix, mit welcher man den Klartext direkt in den oben beschriebenen, allgemeinen linearen Code umwandeln kann. Zusätzlich enthält der Schlüssel, wie viele Fehler anschließend maximal in die Chiffre eingebaut werden sollen, also wie viele Bits invertiert werden sollen.<br />
<br />
Der geheime, private Schlüssel enthält die Information, wie man den allgemeinen linearen Code wieder in einen Goppa-Code zurückverwandeln kann, der anschließend performant dekodiert werden kann und somit die eingebauten Fehler wieder korrigiert.<br />
<br />
Der Algorithmus teilt sich in die drei folgenden Hauptbestandteile auf: '''Die Schlüssel-Erzeugung''', '''das Verschlüsseln''' und '''das Entschlüsseln'''.<br />
<br />
<br />
<br />
==Zusätzliche Informationen==<br />
[[Douglas Stinson]] schreibt in [St95] eine sehr gute Erklärung des McEliece-Kryptosystems mit einem Beispiel. Weitere empfehlenswerte Literatur zu diesem Thema ist in [Sch96] und [WiME05]. Eine kurze deutsche Einführung in dieses Thema findet man in [En06].<br />
<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Kryptographie&diff=4622Kategorie:Kryptographie2006-07-05T22:34:55Z<p>Chriss: </p>
<hr />
<div>[[Kategorie:Mathematik]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=McEliece-Kryptosystem&diff=2424McEliece-Kryptosystem2006-07-05T22:34:41Z<p>Chriss: </p>
<hr />
<div>Neu<br />
[[Kategorie:Kryptographie]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Version&diff=4618Version2006-07-05T22:07:47Z<p>Chriss: </p>
<hr />
<div>#REDIRECT [[Revision]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2484Subversion2006-07-05T22:06:00Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten [[Diff|Diffs]] erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher [[Datenbank]]-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über [[Netzwerk|Netzwerke]] gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-[[Server]]. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Client-Zugriff==<br />
Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].<br />
<br />
Der [[Workspace]] ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.<br />
<br />
Ein [[Checkout]] ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon: <br />
<br />
<code>svn co svn://<server>/<repository></code><br />
<br />
Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte [[Revision|Revisionsstand]].<br />
<br />
Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:<br />
<br />
<code>svn add <Datei-/Pfadname> …</code><br />
<br />
Der Unterschied zwischen zwei Versionen einer Datei ist nun ein [[Diff]]. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand ''i'' auf den neueren Stand ''i''+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein [[Patch]] ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.<br />
<br />
Ein [[Commit]] (Check-In) ist ein [[Diff]] des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.<br />
<br />
Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:<br />
<br />
<code>svn ci -m "<Log-Message>"</code><br />
<br />
Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.<br />
<br />
Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein [[Merge-Konflikt]] auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.<br />
<br />
Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:<br />
<br />
<code>svn up</code><br />
<br />
Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.<br />
<br />
Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2411Subversion2006-07-05T21:55:37Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten [[Diff|Diffs]] erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher [[Datenbank]]-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über [[Netzwerk|Netzwerke]] gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-[[Server]]. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Client-Zugriff==<br />
Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].<br />
<br />
Der [[Workspace]] ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.<br />
<br />
Ein [[Checkout]] ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon: <br />
<br />
<code>svn co svn://<server>/<repository></code><br />
<br />
Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte [[Revision|Revisionsstand]].<br />
<br />
Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:<br />
<br />
<code>svn add <Datei-/Pfadname> …</code><br />
<br />
Der Unterschied zwischen zwei Versionen einer Datei ist nun ein [[Diff]]. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand ''i'' auf den neueren Stand ''i''+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein [[Patch]] ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.<br />
<br />
Ein [[Commit]] (Check-In) ist ein [[Diff]] des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.<br />
<br />
Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:<br />
<br />
<code>svn ci -m "<Log-Message>"</code><br />
<br />
Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.<br />
<br />
Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein Merge-Konflikt auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.<br />
<br />
Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:<br />
<br />
<code>svn up</code><br />
<br />
Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.<br />
<br />
Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2409Subversion2006-07-05T21:45:16Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten [[Diff|Diffs]] erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher [[Datenbank]]-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über [[Netzwerk|Netzwerke]] gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-[[Server]]. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Client-Zugriff==<br />
Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].<br />
<br />
Der [[Workspace]] ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.<br />
<br />
Ein [[Checkout]] ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon: <br />
<br />
<code>svn co svn://<server>/<repository></code><br />
<br />
Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte [[Revision|Revisionsstand]].<br />
<br />
Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:<br />
<br />
<code>svn add <Datei-/Pfadname> …</code><br />
<br />
Der Unterschied zwischen zwei Versionen einer Datei ist nun ein [[Diff]]. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand ''i'' auf den neueren Stand ''i''+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein Patch ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.<br />
<br />
Ein [[Commit]] (Check-In) ist ein [[Diff]] des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.<br />
<br />
Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:<br />
<br />
<code>svn ci -m "<Log-Message>"</code><br />
<br />
Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.<br />
<br />
Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein Merge-Konflikt auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.<br />
<br />
Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:<br />
<br />
<code>svn up</code><br />
<br />
Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.<br />
<br />
Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=4599Versionsverwaltung2006-07-05T21:40:26Z<p>Chriss: </p>
<hr />
<div>==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
====Vorteile====<br />
Die Hauptvorteile – als Verbesserung zu RCS – sind:<br />
* '''Keine dateizentrierte Sichtweise'''<br />
* '''Entwicklungsstil''': Kopieren-Modifizieren-Zusammenfügen d.h. simultanes Arbeiten mehrerer von einander unabhängiger Entwickler möglich<br />
* '''Informationssystem''' für alle (änderungsinteressierte) Entwickler des aktuellen Projekts<br />
* '''Netzwerkfähig''', d.h. Historie ist auf andere Rechner übertragbar und durchgeführte Änderungen lassen sich zuordnen<br />
<br />
===[[Subversion|SVN]]===<br />
Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von [[Subversion]] (SVN).<br />
<br />
====Vorteile====<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2407Subversion2006-07-05T21:29:30Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher [[Datenbank]]-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über [[Netzwerk|Netzwerke]] gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-[[Server]]. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als [[Deamon]] gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Client-Zugriff==<br />
Am einfachsten und schnellsten ist der Einsatz der [[Kommandozeile]]. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].<br />
<br />
Der [[Workspace]] ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.<br />
<br />
Ein [[Checkout]] ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon: <br />
<br />
<code>svn co svn://<server>/<repository></code><br />
<br />
Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte [[Revision|Revisionsstand]].<br />
<br />
Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:<br />
<br />
<code>svn add <Datei-/Pfadname> …</code><br />
<br />
Der Unterschied zwischen zwei Versionen einer Datei ist nun ein Diff. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand ''i'' auf den neueren Stand ''i''+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein Patch ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.<br />
<br />
Ein [[Commit]] (Check-In) ist ein Diff des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.<br />
<br />
Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:<br />
<br />
<code>svn ci -m "<Log-Message>"</code><br />
<br />
Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.<br />
<br />
Ein [[Update]] aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein [[Merge]] führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein Merge-Konflikt auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.<br />
<br />
Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:<br />
<br />
<code>svn up</code><br />
<br />
Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.<br />
<br />
Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2401Subversion2006-07-05T20:49:26Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem [http://svnbook.red-bean.com/ offiziellen Handbuch]:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher Datenbank-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über Netzwerke gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-Server. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als Deamon gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Client-Zugriff==<br />
Am einfachsten und schnellsten ist der Einsatz der Kommandozeile. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im [http://svnbook.red-bean.com/ offiziellen Handbuch].<br />
<br />
Der Workspace ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.<br />
<br />
Ein Checkout ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon: <br />
<br />
<code>svn co svn://<server>/<repository></code><br />
<br />
Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte Revisionsstand.<br />
<br />
Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:<br />
<br />
<code>svn add <Datei-/Pfadname> …</code><br />
<br />
Der Unterschied zwischen zwei Versionen einer Datei ist nun ein Diff. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand ''i'' auf den neueren Stand ''i''+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein Patch ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.<br />
<br />
Ein Commit (Check-In) ist ein Diff des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.<br />
<br />
Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:<br />
<br />
<code>svn ci -m "<Log-Message>"</code><br />
<br />
Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.<br />
<br />
Ein Update aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein Merge führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein Merge-Konflikt auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.<br />
<br />
Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:<br />
<br />
<code>svn up</code><br />
<br />
Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.<br />
<br />
Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter <code>r</code> auch eine beliebige, alte Revision laden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2400Subversion2006-07-05T20:44:28Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Server Einrichten==<br />
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet. <br />
<br />
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:<br />
<br />
<code>svnadmin create <repository></code><br />
<br />
Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher Datenbank-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:<br />
<br />
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.<br />
<br />
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über Netzwerke gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.<br />
<br />
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-Server. Hier soll der einfachere Weg über den Server erklärt werden:<br />
<br />
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.<br />
<br />
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:<br />
<br />
<code>svnserve –d –r .</code><br />
<br />
Der Parameter <code>d</code> bewirkt, daß der Dienst als Deamon gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2405Versionsverwaltung2006-07-05T20:30:47Z<p>Chriss: </p>
<hr />
<div>==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===<br />
Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von [[Subversion]] (SVN).<br />
<br />
====Hauptvorteile====<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Versionsverwaltung&diff=4608Kategorie:Versionsverwaltung2006-07-05T20:28:55Z<p>Chriss: </p>
<hr />
<div>[[Kategorie:Informatik]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Versionsverwaltung&diff=2394Kategorie:Versionsverwaltung2006-07-05T20:28:42Z<p>Chriss: </p>
<hr />
<div>[[Kategorie:xy-eltern]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2399Subversion2006-07-05T20:24:43Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
==Beispiele==<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)<br />
<br />
==Siehe auch==<br />
[[Kategorie:Versionsverwaltung]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2396Versionsverwaltung2006-07-05T20:23:39Z<p>Chriss: </p>
<hr />
<div>==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===<br />
Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von [[Subversion]] (SVN).<br />
<br />
====Hauptvorteile====<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2392Versionsverwaltung2006-07-05T20:22:44Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===<br />
Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von [[Subversion]] (SVN).<br />
<br />
====Hauptvorteile====<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
==Quellen==<br />
* Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178<br />
* Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3<br />
* Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, [http://www.nongnu.org/cvs/ CVS-Homepage]<br />
* Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x<br />
* Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, [http://svnbook.red-bean.com/ http://svnbook.red-bean.com/]<br />
* CollabNet, Inc., Subversion Homepage, [http://subversion.tigris.org/ Subversion-Homepage]<br />
<br />
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2391Versionsverwaltung2006-07-05T20:09:38Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===<br />
Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von [[Subversion]] (SVN).<br />
<br />
====Hauptvorteile====<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2393Subversion2006-07-05T20:06:58Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
==Beispiele==<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
==Siehe auch==<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2389Subversion2006-07-05T20:06:03Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Subversion==<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
===Hauptvorteile===<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
==Beispiele==<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
==Geschichte==<br />
===SCCS===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===RCS===<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===CVS===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
==Quellen==<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
==Siehe auch==<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2388Subversion2006-07-05T20:04:26Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
=Definition=<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
=Subversion=<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
==Hauptvorteile==<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
=Beispiele=<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
=Geschichte=<br />
==SCCS==<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
==RCS==<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
==CVS==<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
=Quellen=<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
=Siehe auch=<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2390Versionsverwaltung2006-07-05T20:02:55Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist das [[Concurrent Versions System]] (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2385Versionsverwaltung2006-07-05T20:01:52Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist [[Concurrent Versions System|CVS]], das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2384Versionsverwaltung2006-07-05T19:58:22Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System|'''Source Code Control System''']] (SCCS) war eine der ersten [[Versionsverwaltung|Versionsverwaltungen]]. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Das [[Revision Control System|'''Revision Control System''']] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist [[Concurrent Versions System|CVS]], das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2382Versionsverwaltung2006-07-05T19:56:39Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das '''Source Code Control System''' (SCCS) war eine der ersten [[Versionsverwaltung|Versionsverwaltungen]]. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]] war das [[Revision Control System|RCS]] ([[Revision Control System]]), das 1985 von Walter Tichy an der Purdue University entwickelt wurde. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist [[Concurrent Versions System|CVS]], das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Versionsverwaltung&diff=2381Versionsverwaltung2006-07-05T19:55:34Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
==Definition==<br />
Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
==Open-Source-Versionsverwaltungen==<br />
===[[Source Code Control System|SSCS]]===<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
===[[Revision Control System|RCS]]===<br />
Die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]] war das [[Revision Control System|RCS]] ([[Revision Control System]]), das 1985 von Walter Tichy an der Purdue University entwickelt wurde. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
===[[Concurrent Versions System|CVS]]===<br />
Die Weiterentwicklung von RCS ist [[Concurrent Versions System|CVS]], das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
===[[Subversion|SVN]]===</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2386Subversion2006-07-05T19:51:41Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
=Definition=<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
=Subversion=<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
==Hauptvorteile==<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
=Beispiele=<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
=Geschichte=<br />
==SCCS==<br />
Das [[Source Code Control System]] (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
==RCS==<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
==CVS==<br />
Die Weiterentwicklung von RCS ist CVS, das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
=Quellen=<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
=Siehe auch=<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2367Subversion2006-07-05T19:45:55Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
=Definition=<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
=Subversion=<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
==Hauptvorteile==<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
=Beispiele=<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
=Geschichte=<br />
==SSCS==<br />
Das [[Source Code Control System]] (SSCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
==RCS==<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
==CVS==<br />
Die Weiterentwicklung von RCS ist CVS, das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
=Quellen=<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
=Siehe auch=<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2359Subversion2006-07-05T19:43:43Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
=Definition=<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
=Subversion=<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
==Hauptvorteile==<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* '''Verzeichnisversionierung''': Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* '''Echte Versionsgeschichte''': Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* '''Atomare Commits''': Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* '''Versionierte Metadaten''': Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* '''Auswahl der Netzwerkschicht''': Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* '''Konsistentes Datenmanagement''': Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* '''Effizientes Branching und Tagging''': Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* '''API''': Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
=Beispiele=<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
=Geschichte=<br />
==SSCS==<br />
Eine der ersten Versionsverwaltungen war das [[Source Code Control System]], kurz SSCS. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
==RCS==<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Sie wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
==CVS==<br />
Die Weiterentwicklung von RCS ist CVS, das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
=Quellen=<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
=Siehe auch=<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2358Subversion2006-07-05T19:43:02Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
=Definition=<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
=Subversion=<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
==Hauptvorteile==<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* Verzeichnisversionierung: Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* Echte Versionsgeschichte: Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* Atomare Commits: Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* Versionierte Metadaten: Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* Auswahl der Netzwerkschicht: Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* Konsistentes Datenmanagement: Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* Effizientes Branching und Tagging: Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* API: Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).<br />
<br />
<br />
=Beispiele=<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
=Geschichte=<br />
==SSCS==<br />
Eine der ersten Versionsverwaltungen war das [[Source Code Control System]], kurz SSCS. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
==RCS==<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Sie wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
==CVS==<br />
Die Weiterentwicklung von RCS ist CVS, das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
=Quellen=<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
=Siehe auch=<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chrisshttps://glossar.hs-augsburg.de/w/index.php?title=Subversion&diff=2357Subversion2006-07-05T19:38:46Z<p>Chriss: </p>
<hr />
<div>{{In Bearbeitung}}<br />
<br />
=Definition=<br />
Eine [[Versionsverwaltung]] hat die Aufgabe, den Werdegang eines [[Projekt|Projektes]] zu protokollieren. Sie übernimmt die [[Versionierung]] und die [[Archivierung]] der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.<br />
<br />
=Subversion=<br />
Bis zum Jahr 2000 entwickelte sich [[Concurrent Versions System|CVS]] zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. [CN06] dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.<br />
<br />
==Hauptvorteile==<br />
Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:<br />
* Verzeichnisversionierung: Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.<br />
* Echte Versionsgeschichte: Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.<br />
* Atomare Commits: Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.<br />
* Versionierte Metadaten: Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.<br />
* Auswahl der Netzwerkschicht: Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.<br />
* Konsistentes Datenmanagement: Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.<br />
* Effizientes Branching und Tagging: Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.<br />
* API: Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.<br />
<br />
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: cvs2svn (CVS to Subversion Repository Converter).<br />
<br />
<br />
=Beispiele=<br />
Beispiele machen sich auch nicht schlecht.<br />
<br />
<br />
<br />
=Geschichte=<br />
==SSCS==<br />
Eine der ersten Versionsverwaltungen war das [[Source Code Control System]], kurz SSCS. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.<br />
<br />
==RCS==<br />
Das [[Revision Control System]] (RCS) war die erste große Versionsverwaltung im [[Open Source|Open-Source-Bereich]]. Sie wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.<br />
<br />
==CVS==<br />
Die Weiterentwicklung von RCS ist CVS, das [[Concurrent Versions System]]. In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in [[C]] komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.<br />
<br />
=Quellen=<br />
*Hinz und Kunz, "Der Bau einer Musterseite", 7. Auflage, Wiki-Verlag, 1931<br />
*[[Kowarschick, W. et al. (2005): Musterquelle]]<br />
*[http://kowa.fh-augsburg.de Kowarschicks gesammelte Werke]<br />
<br />
=Siehe auch=<br />
Zu guter letzt kann Sekundärliteratur angegeben werden, die zwar im Artikel nicht direkt verwendet, aber doch irgendwie interessant ist.<br />
Außerdem sollten eine oder mehrere Kategorien angegeben werden sowie ein Verweis auf den zugehörigen englischen Artikel<br />
in [[GlossaryWiki:Main Page|GlossaryWiki]], auch wenn es diesen noch gar nicht gibt.<br />
<br />
*[[Theory of Constraints (Quellen)]] (eine ganze Sammlung von Quellen in einem Quellen-Dokument)<br />
*[[Wikipedia:Wikipedia:Formatvorlagen|Wikipedia: Formatvorlagen]]<br />
<br />
[[Kategorie:Glossar]]</div>Chriss