Re: IDEA - encrypted-SFX-EXE to see secret text

[allen]

fsekrit is uber-cool, man.  A couple little things I think it's missing.

1) Some sort of file > open dialog to import a text file
2) Remember window size on a per-.exe basis.  Some files are wider than others and, surely, I can't be bothered with resizing my own window
3) Take a few command line parameters -- so I can launch fsekrit with the file name and text file to use as the document source already predefined.  This would make it possible to encrypt a text file on the fly using a text editor that supported external tools.

[f0dder]

Importing text files is planned for next version.

Remember window size (and position, when re-opening window after save) is already implemented - current version is 1.0, mouser hasn't updated to that yet, though. 0.6 wasn't meant to be public

Commandline parameters are also planned for the next version. Dunno if I want to support encryption key on commandline, though. Currently the save feature kind-of does this, but it specifies the AES-256 encryption key in HEX format, not your passphrase...

Let me know of any feature requests, bug reports, praise , whatever..

[allen]

Just a warning, I posted a copy of that to the 1.0 thread, which I hadn't found prior to now

[mouser]

im gonna moves these posts to fsekrit section.

[wr975]

Many thanks for fSekrit. Great tool!!! 


>feature requests

The author of Ghost_AES (http://free.pages.at/ghost_hunter/crypt.htm) claims ultimate security because he's not storing the password. So if you decrypt using a wrong password, you'll get unuseable data.I like the idea. It sure makes brute force impossible.

If you also like this idea, perhaps you can add a "don't store password" option in future versions of fSekrit.

[f0dder]

Many thanks for fSekrit. Great tool!!! 


>feature requests

The author of Ghost_AES (http://free.pages.at/ghost_hunter/crypt.htm) claims ultimate security because he's not storing the password. So if you decrypt using a wrong password, you'll get unuseable data.I like the idea. It sure makes brute force impossible.

If you also like this idea, perhaps you can add a "don't store password" option in future versions of fSekrit.

I don't store the password anywhere. I do store a hash of the password plaintext, but it is impossible to reconstruct the password from the hash. It's true that storing the hash means you can automate bruteforcing, but bruteforcing a 256-bit key is infeasible, even if you distribute it massively.

Also, even for a solution where you don't store a hash of the password plaintext, statistical analysis could be used instead of hash-checking; this is remarkably effective. There would be some false positives that would need manual checking, but not too many...

So I'll keep storing the hash for convenience

[wr975]

Thanks for the info! 

[f0dder]

I do store a hash of the password

Oops!
I mean a hash of the PLAINTEXT, of course! (fixing up the previous post, but posting here as well)