TXTCrypt 1.0

[tomkupitz]

Hallo,

hier ist ein kleines Tool zum Verschlüsseln (AES Verfahren) von TXT-Dateien (https://www.screensoft.de/txtcrypt.zip). Und so wird's benutzt:

Code:

TXTCrypt - Tool zum Ver- und Entschlüsseln von Textdateien (© 2024 by Thomas Schwobe)
-------------------------------------------------------------------------------------

1. Verschlüsselung

- hier können Sie TXT-Dateien laden und verschlüsseln (Passworteingabe notwendig, max. 16 Zeichen)
- dabei wird eine verschlüsselte CTF-Datei mit gleichem Namen erstellt
- unter Optionen können Sie einstellen, ob hierbei die originale TXT-Datei gelöscht werden soll

2. Entschlüsselung

- hier können Sie eine CTF-Datei laden und entschlüsseln (den Textinhalt anzeigen, Passworteingabe notwendig)
- Sie können den Dateityp CTF (über Windows) mit der Applikation TXTCrypt.exe verknüpfen: 
  a. Doppelklick auf CTF-Datei: TXTCrypt.exe läuft nicht => TXTCrypt.exe wird gestartet und CTF-Datei wird nach Passworteingabe entschlüsselt und Textinhalt wird angezeigt
  b. Doppelklick auf CTF-Datei: TXTCrypt.exe läuft => TXTCrypt.exe (nur eine Instanz möglich)) wird in den Vordergrund gebracht und CTF-Datei wird nach Passworteingabe entschlüsselt und Textinhalt wird angezeigt

Längere Ver- / Entschlüsselungsvorgänge können mit ESCAPE Taste abgebrochen werden.
  
Das Programm unterliegt dem Copyright des Autors. Bei erlaubter Weitergabe muss stets die Herkunft angegeben werden. Die Benutzung der Software erfolgt auf eigene Gefahr. Der Autor übernimmt keinerlei Haftung für eventuelle Schäden die durch die Software entstehen. Eine kommerzielle Nutzung ist untersagt.

Beste Grüße

[EdAdvokat]

Mal wieder ein Textverschlüsselungsprogramm.
Wer wird das wohl nutzen wollen, wenn kein Hinweis auf den verwendeten Algorithmus angegeben wird?
Es gibt aktuell nachweislich geprüfte und quasi-absolut sichere Chiffrierverfahren wie beispielsweise AES und weitere Verfahren, die unter Beobachtung
von kryptologisch-mathematischen geschulten Fachleuten stehen und hinreichend veröffentlicht wurden, die sicher dann als erste Wahl anzusehen wären.
Genannt sei hier nur beispielhaft das Projekt DEC. (hier im Forum ausgibig veröffentlicht und diskutiert)
Auch ist unklar, wie die Passwortübermittlung der Partner gewährleistet werden soll. Kommen hier asymetrische Verfahren zur Anwendung?

Um wirklich Freunde für dieses Projekt gewinnen zu können, sind weitere Angaben erforderlich.

[tomkupitz]

hier liegt das AES Verfahren aus dem TMS Cryptography Pack zu Grunde.

[EdAdvokat]

Es ist sicher keine so gute Idee, lediglich eine unsignierte Exe-Datei hier im Delphi-Forum (Delphi-Praxis) einzustellen, deren Download sofort unterbunden wird.
Der Download wird als Sicherheitsrisiko angesehen und auch die Virenscanner schlagen Alarm.
Doch das ist es nicht allein. Ich empfehle mal das Kerckoffsche Prinzip zu verinnerlichen, damit bei möglichen Nutzern von ernstgemeinten Chiffrierprogrammen Vertrauen
aufgebaut werden kann.
So wäre also Quelltext gefragt, anhand dessen die tatsächlich behauptete Sicherheit geprüft werden könnte.
Dann die wichtige Frage des Key-Managements. Welche Keylänge wird verwendet und wie werden die Keys ausgetauscht. Über Telefon, e-mail, SMS sicher nicht.
Die Angabe TMS-Komponenten reicht da also nicht aus.
Doch die TMS-Komponenten beinhalten eine Reihe von Lösungsmöglichkeiten für die hier nur bruchstückhaft angerissenen Fragen.
Als Hinweis sei erwähnt: Diffie-Hellman-Merkle, RSA, ECC. Eine Reihe von asymetrischen Algorithmen wären für diese Zwecke geeignet.

Doch für ganz wichtig halte ich die Frage der prinzipiellen Eignung der Exe-Datei für Windows 10 / 11-Systeme, also die Signierung der Exe-Datei.
Was nützt es einem Interessierten, wenn sein Download sofort als Sicherheitsrisiko erkannt und dann gelöscht wird. Unter diesen Umständen würde ich
auch die Exe-Datei nicht ausführen wollen, wenn ich sie tatsächlich herunter geladen bekommen würde.

[Kas Ob.]

Hi,

EdAdvokat is right on point, yet i want to add few thoughts/points on this subject.

1) Using TMS Cryptography Pack is not enough to call an implemented functionality secure, there is best practices and there is standards to be applied.
2) How to know that this tool is in fact does encrypt for sure and doesn't leak or even the worse doesn't have a backdoor or master key !!?
3) How to know that this tool didn't reinvented the wheel and made huge mistakes like reusing the IV or the worse, doesn't use one !!?, or chose the wrong padding and it is working now for the lack of specific cases that will lead to data loss.
..


So i suggest the following:
If you don't want to disclose the source ? that is OK, but you have/must disclose the implemented algorithm(s), only then we can validate the functionality and the process, without disclosing the algorithm(s) this tool is highly recommended to not touch or use !
As pointed above (2)(3), there is best practice should be used, there is standards should be applied, there is hundred thousands of hours invested to provide these algorithms and that should not be taken lightly, and most crucial point to remember is that "obfuscation is not security", so disclosing the algorithm(s) is a must, at least we can check that the right usage and check for malicious implementation, like is every byte in that data is accounted for, and there is no backdoor ..etc

From TMS Cryptography Pack documentation i see the following algorithms/standards is right for such usage, namely

Zitat:

RSA (OAEP/PSS and PKCS v1.5) to sign and verify signatures of data with key size up to 4096 bits or to encrypt and decrypt (used to exchange keys)
ECIES to encrypt and decrypt with elliptic curves, the AES and SHA2 (used to exchange keys)

But these will use PKI (asymmetric operation), and there is difference between them, all of them can handle private key this in like OAEP should be provided in external container like an X509 certificate which can be tricky for your case of usage, but not impossible on the contrary you could add certificate store to use for encryption and provide them along the passwords,
For me i like and use ECIES a lot, this standard is very powerful and relatively faster than RSA, with the nicest thing to have which is shorter key, with shorter keys one can utilize PBKDF2 to generate the private for the ECIES from plain password, i do/did that in so many places, a recommendation here always generate the key with salt, in case you want to limit the encryption/decryption to one tool/project then fix the salt in that tool, otherwise combine stapled (in the exe) certificate private key with a user provided password then derive the private key for ECIES.

Why i suggested these above, because without these standard you are reinventing the wheel and you do need to build a sound and reliable data structure (a container) for the encrypted data and the associated parameters, simple case is that AES encryption must not reuse the key for more than one operation, hence the need for the (pseudo) random IV, and this IV should not be derived from the key !, and it can be public, so it must accompany the encrypted data, so the encrypted file should have the IV, also what MAC algorithm in case you want to do it on your own, and when are you MAC'ing the data, in other words did you use MAC, and which algorithm/method ? Encrypt-then-MAC, MAC-then-Encrypt or Encrypt-and-MAC ? also that MAC should be accompany the encrypted file, so we need at least two fields/data to accompany the file, here comes another question with added data, which padding are you using to ensure the reliability of the mentioned fields, ...
So to skip all above, stick to the well known and vetted algorithms, AES is far from enough be just secure out of the box.


side note: didn't run your tool, but providing command line is very nice functionality to have, so you might consider adding it.

[himitsu]

Abgelehnt von Browsern (Edge/Firefox/Chrome) wird der Download vor allem, da hier eine externe unverschlüsselte URL von einer verschlüsselten Webseite aus verlinkt/runtergeladen wird.
HTTP:-DownloadLink von einer HTTPS:-Webseite

Dann sind Screenshots auch immer nett.
Nichtmal auf deiner Seite wird dieses Programm beworben ... jedenfalls nichts gefunden.

Also HTTPS-Link, oder besser ein Link zur Vorstellungsseite auf deiner Homepage und dann dort der Download.


Was für eine Lizenz hat TMS eigentlich?
Wäre es da nicht eventuell angebracht Dieses in den Programminfos mit zu erwähnen?

[Kas Ob.]

Well looking for an extra information, i found this nice page, explaining in short the differences between 3 RSA encryptions
https://www.cryptosys.net/pki/manpki...saschemes.html

as for ECIES
https://en.wikipedia.org/wiki/Integr...ryption_Scheme

Looks confusing at first, but if you look at
https://download.tmssoftware.com/Dow...graphyPack.pdf

we see this example for ECIES encryption

Code:

var
 ecc: TECCEncSign;
 cipher: string;
begin
 ecc:= TECCEncSign.Create;
 ecc.ECCType:= cc25519;
 ecc.OutputFormat:= base64;
 ecc.Unicode:= noUni;
 ecc.NaCl := naclno;
 ecc.GenerateKeys();
 cipher:= ecc.Encrypt('test');
 ecc.Free;
end;

Few things can be adjusted in many ways, but the simplest for your usage, you should replace ecc.GenerateKeys() with different algorithm that derive ECC private key from password (namely PBKDF2 or any better), i don't think you need the OutputFormat to be base64, also strangely enough there is no raw data feeding for most TMS cryptography classes, it is strings everywhere !
I don't think it is a huge problem as i am almost sure the RawData types handling routines are there but not public, (don't own the library so can't tell, but assuming based on my memory using their library form more than 10 years ago when i had subscription)

[Sinspin]

Was ich nicht verstehe, warum nur Textdateien? Wer will schon Textdateien verschlüsseln?
Es macht doch für den Algorithmus keinen Unterschied ob das nun Text ist oder was anderes. Warum dann die Einschränkung?