7z selbst Compilieren

[CRC]

Hallo,

eigentlich würde meine Anfrage in gleich 3 Subforen passen: Programmieren, Anwendungssoftware und hier.

Weil 7Zip Open Source ist setz ich das schon seit ganz langem ein.
Jetzt kam mir die Idee, daß ich das mal selber compilieren "könnte".

Zwar fehlen mir dazu gerade die technsichen Möglichkeiten (Festplatte voll, Windows will ich neu installieren) - vor allem aber das Wissen um Visual c/C++ fehlt mir – ich kann allenfalls den „Spritrechner“ aus dem Uni-Schnupper-Kurs als Konsolenanwendung schreiben.

Zur Zeit ist die Version 7.34 alpha aktuell. Den letzten Source hab ich nur von der offiziellen 9.22 gefunden.

http://sourceforge.net/projects/sevenzip/files/7-Zip/9.22/

Jetzt steht in der readme.txt im DOC Ordner [gekürzt!]

How to compile
--------------
To compile sources you need Visual C++ 6.0.
For compiling some files you also need
new Platform SDK from Microsoft' Site:

Also you need Microsoft Macro Assembler:
- ml.exe for x86
- ml64.exe for AMD64

Die Beschreibung ist (OK, ist eben beigepacktes README und Adressaten sind mit Sicherheit Programmierexperten! und nicht an normale User) recht schlicht gehalten.
Klar, verstehe ich ungefähr, was er damit meint, da ich von DELPHI herkomme - da gibt es ähnliche Anpassungen in der IDE vorzunehmen. (ja, OK, schimpft ruhig .. dieses ausgestorbene Delphi )
Aber wieviel Aufwand das für ein einzelnes Projekt ist, weiß ich nicht, wenn man alle Installationen [SDK] vornehmen, Compilerschalter und Projekteinstellungen setzen muß … für einen routinierten Programmierer,

Was mich jetzt mal interessieren würde ist, ob man den selben Output erhält, wenn man selber compiliert, wie das verfügbare Binary.

Müßte man sich wirklich VC++6 besorgen? Welche Version (Pro, Std,, Multilang oder Engl. )?
Oder ginge das auch mit den modernen VC++ 2012, evtl. sogar Express?

Nein, mir geht das nicht um Viren. Dafür gäbe es googles VirusTotal.
Und ich vertraue dem Autor ja auch ("blind") - wie jeder andere Chip und computerbildleser auch.

Ich verschlüssel ganz gerne Mal Dateien. (für privat und Internet)

Und da würd ich gern wissen, ob der AES (ja, genau, dieser angeblich noch sichere und gut dokumentierte Algorithmus) auch wirklich so übersetzt wird. Ich hoff mal, daß er den nach bestem Wissen und korrekt implementiert hat, und daß ihm da nicht 'Väterchen' die Hand auf die Schulter gelegt hat ...

Vielleicht Ich hoffe, daß sich hier noch konstruktive Gedankengänge zu finden und eine eventuelle einfach Lösung.
Ganz herzlichen Dank schon mal für Eure Antworten, auf diese triviale und dadurch bestimmt total dämliche Frage und Eure Geduld. Ein Spam/Trollposting liegt mir absolut fern.

 

[mathmos]

Die Beschreibung ist (OK, ist eben beigepacktes README und Adressaten sind mit Sicherheit Programmierexperten! und nicht an normale User) recht schlicht gehalten.

Unter http://www.ski-epic.com/2012_compiling_7zip_on_windows_with_visual_studio_10/index.html gibt es eine ausführlichere Anleitung. Vielleicht hilft dir das schon mal weiter.

 

[Kugelfisch]

Ich verschlüssel ganz gerne Mal Dateien. (für privat und Internet)

Beachte, dass dazu 7-zip nur bedingt geeignet ist, insbesondere ist das nicht der angedachte Verwendungszweck. Da sich verschlüsselte Archive nicht nutzen lassen, ohne sie zu extrahieren, bleibt bei jeder Nutzung eine unverschlüsselte Kopie auf der Festplatte zurück. Sofern du keine Vollverschlüsselung nutzt, wäre einfacher, diese Kopie wiederherzustellen (sofern sie nicht überschrieben wurde), statt die Verschlüsselung anzugreifen. Um sensible Daten zu archivieren würde ich ebenfalls eher eine Lösung nutzen, welche für solche Zwecke gedacht ist, z.B. GnuPG.

Und da würd ich gern wissen, ob der AES (ja, genau, dieser angeblich noch sichere und gut dokumentierte Algorithmus) auch wirklich so übersetzt wird. Ich hoff mal, daß er den nach bestem Wissen und korrekt implementiert hat, und daß ihm da nicht 'Väterchen' die Hand auf die Schulter gelegt hat ...

Das Problem ist, dass du nicht ohne Weiteres feststellen kannst, woher Unterschiede in den Binaries stammen, die sich mit Sicherheit ergeben werden sofern du nicht denselben Quellcode mit demselben Compiler und exakt derselben Konfiguration compilierst. Ausserdem würde ich nicht bezweifeln, dass AES korrekt implementiert ist (eine Backdoor oder ein Bug an dieser Stelle wäre vergleichsweise leicht zu finden, zumal die entstehenden verschlüsselten Dateien dann mit einer Standard-AES-Implementierung inkompatibel wären) - viel interessanter wäre die Frage, ob die Schlüsselableitung und ein ggf. dazu verwendeter PRNG sicher sind. Insbesondere Schwächen in PRNGs sind sehr schwer auffindbar, können im Zweifelsfall kaum von einem Bug oder einem Designfehler unterschieden werden, aber erleichtern Angriffe erheblich (z.B. Dual_EC_DRBG, Debians OpenSSL 2008, ...). Da der primäre Anwendungszweck von 7-zip nicht darin besteht, Daten zu verschlüsseln, wäre ein Fehler an dieser Stelle auch durchaus entschuldbar.

 

[Toady]

Ohne mir nun die sourcen geladen zu haben - ich bezweifle, dass die Macher von 7z Rijndael (der Algo wird wohl gemeint sein) selbst implementiert haben. Bei ner MS-Software würde ich die MS-Implementierung unter System.Security.Cryptography nehmen, und mich hier *streng* ans MSDN halten, es sei denn, ich wüsste ganz genau, was ich tue.
Ansonsten bin ich paranoid genug, um djbs crypto-libs zu nutzen - ich habe viel zu wenig Ahnung von Kryptographie, als dass ich mich an openssl ranwagen würde - und ich bilde mir ein, dass ich halbwegs weis, was ich tue. Openssl ist mir noch zu "lowlevelig", da verlasse ich mich lieber auf Bernstein, Henninger und Lange - die wissen, was sie tun.

YMMV

 

[Kugelfisch]

Ohne mir nun die sourcen geladen zu haben - ich bezweifle, dass die Macher von 7z Rijndael (der Algo wird wohl gemeint sein) selbst implementiert haben.

Doch, hat er, ebenso die komplette Crypto (C/Aes.c, C/AesOpt.c, CPP/7zip/Crypto/*) für sämtliche unterstützten Dateiformate ...
[src=c]/* Aes.c -- AES encryption / decryption
2009-11-23 : Igor Pavlov : Public domain */

#include "Aes.h"
#include "CpuArch.h"

static UInt32 T[256 * 4];
static Byte Sbox[256] = {
/* ... */[/src]
... daher auch meine Warnung, dass es da (durchaus ungewollte) Fehler geben könnte, speziell solche, die man nicht trivial feststellen kann. Ob die AES-Implementierung funktioniert, lässt sich ja selbst von Crypto-Laien anhand von Test-Vektoren relativ leicht überprüfen. Schwachstellen bei der Schlüsselableitung oder dem verwendeten PRNG sind deutlich schwerer zu finden ...

 

[Toady]

Ach du kagge - warum macht man denn sowas?

 

[Kugelfisch]

Mutmasslich einerseits, um externe Abhängigkeiten zu vermeiden, andererseits, weil diverse unterstützte Formate wie z.B. ZIP ausschliesslich oder alternativ zu AES auch proprietäre (und, wie zu erwarten, dementsprechend schwache) Cipher einsetzen. 7-zip ist primär als Packer und nicht zum Verschlüsseln von Dateien gedacht, und wenn die Crypto dann bloss insoweit `funktioniert`, dass sie mit anderen Packern kompatibel ist und keinen offensichtlichen Klartext ausgibt, wäre das zumindest nicht verwunderlich. Konkrete Schwachstellen sind mir zwar nicht bekannt, für sensible Daten würde ich aber wie erwähnt zu Tools wie z.B. GnuPG raten, welche zur Verschlüsselung von Dateien/Inhalten vorgesehen sind.

 

[Toady]

Mutmasslich einerseits, um externe Abhängigkeiten zu vermeiden, andererseits, weil diverse unterstützte Formate wie z.B. ZIP ausschliesslich oder alternativ zu AES auch proprietäre (und, wie zu erwarten, dementsprechend schwache) Cipher einsetzen.

Na, der zweite Punkt ist in dem Kontext ja egal, geht ja primär um Rijndael.
Es ist grundsätzlich ne saublöde Idee, selbst zu versuchen crypto zu implementieren. Fertige libs werden ja eben dadurch erst per Definition "gut" und entsprechend vertrauenswürdig, dass viele Leute sie reviewen (ich komm grade nicht auf den Holländer, der die Regeln formuliert hat - ist schon sehr alt, die Problematik kam schon bei Telegraphenübertragungen auf).
Sich eben noch nebenbei ne eigene crypto-lib zu schreiben, ist schon als Idee saudumm. Jede Plattform bietet mir fertige OS-libs, die ich nur einbacken muss. Du schreibst dir für ne Wintendo-Anwendung ja auch keine neuen OpenFileDialog-Objekte, um Abhängigkeiten zu vermeiden...

 

[Kugelfisch]

Ich möchte das auch keinesfalls unterstützen, sondern nur spekulieren, weshalb die Crypto selbst implementiert wurde
Sicherlich bietet jedes Betriebssystem sogar mehrere Bibliotheken und/oder interne APIs für Kryptografie aller Art. Wenn das Ziel jedoch ist, eine plattformunabhängige Anwendung (wie es 7-zip ist) zu entwickeln, dann muss man entweder Wrapper um die verwendeten APIs schreiben und sicherstellen, dass sich zumindest die vermeintlich deterministischen Teile auf jeder Plattform identisch verhalten (Ver-/Entschlüsselung, Schlüsselableitung, Hash-Funktionen, ... - dadurch muss man sich weitgehend auf Primitiven beschränken), man verwendet eine plattformübergreifende Crypto-Bibliothek, oder eigene (alternativ bestehende, als Quellcode einkompilierbare) Implementierungen. Da im Falle von 7-zip durch die Archivformate ohnehin bereits diverse Vorgaben bestehen, wie der Schlüssel aus dem Passwort abgeleitet werden und welche Cipher verwendet werden müssen, nahm der Autor wohl an, dass eine eigene Implementierung einfacher zu warten und zu portieren wäre. Deshalb würde ich einen Packer auch nicht für sensible Daten nutzen wollen ...

 

[Toady]

Wenn das Ziel jedoch ist, eine plattformunabhängige Anwendung (wie es 7-zip ist) zu entwickeln, dann muss man entweder Wrapper um die verwendeten APIs schreiben und sicherstellen, dass sich zumindest die vermeintlich deterministischen Teile auf jeder Plattform identisch verhalten (Ver-/Entschlüsselung, Schlüsselableitung, Hash-Funktionen, ... - dadurch muss man sich weitgehend auf Primitiven beschränken), man verwendet eine plattformübergreifende Crypto-Bibliothek, oder eigene (alternativ bestehende, als Quellcode einkompilierbare) Implementierungen.

Vielleicht stehe ich ja aufm Schlauch - aber was hindert mich daran, beispielsweise die openssl-libs zu nehmen?

BTW:
http://de.wikipedia.org/wiki/Auguste_Kerckhoffs den suchte ich oben. Der formulierte nämlich u.a.:
das Chiffriersystem sollte von Experten gut untersucht sein
Das halte ich in dem Fall für eine zumindest gewagte Aussage, da das System in seiner Gänze gemeint ist - eben mit den Einschränkungen, die du oben schon genannt hast.

Versuchen Crypto selbst zu implementieren ist schon als Idee shice, die vorhadenen libs sind schon komplex genug (siehe u.a. openssl), und da haben Leute drann gearbeitet, die sich Jahre(!) darüber Gedanken gemacht haben.