|
because the encryption works with padding i added specific char (dont remember, think 255) at the end of the file and i remove it after the decryption.
In a case where the same characters are being used in the end of the file - that is a bug.
there's a simple solution and it's to remove the padding removal in the decryption. this is make the file a bit bigger when decrypting (max 8 chars).
i didnt do so (know the bug it could create) because many files do a CRC check for themselves and this can cause a problem by itself.
Maybe i will think of something else, or maybe add a toggle in next version
feel free to fix it yourself..
Cheers,
Nir Dremer.
|
|
|
|
|
I have experienced such bugs in other projects of mine.
To avoid that problem, I now prefix the "cleartext" with a
32 bit "size" then perform the encryption.
I also add a checksum for cleartext as a suffix.
So, the source "cleartext" is changed to "length prefix" , "cleartext", "checksum".
When decrypting, I can verify that the password was good my testing the stored length
versus the actual length and checking the stored checksum versus the actual checksum.
|
|
|
|
|
Hi
Nice work, I need to ask you some questions, please:
1- Do you think that towfish is better than rijendal or not ?
2- What’s the possibility of cracking the towfish encryption ? ( how many years ?)
3- Is any one could have a back doors for this kind of encryption algorithm?
4- I have a project of encryption separated blokes of size from 64 bytes, do you think the block cipher is good choice ?
5- Is the block cipher better than the stream cipher ?
Thanks
|
|
|
|
|
Hey!
The questions you're asking are basic knowledge in encryption & cryptography.
I would love to answer them but i dont see myself as a certified source for this type of question.
There're many tutorials on the internet that explain encryption in global and specific stream-cipher (search google for encryption tutorial and so on).
i can suggest www.counterpane.com site which is the site of the inventor of blowfish & twofish algorithms Bruce S.. This site has many tutorials and information about the above encryptions in specific and various others.
Hope i helped you out, if not feel free to ask again / more.
Cheers,
Nir Dremer.
|
|
|
|
|
I do have VC6 and tried to convert the project using the converter from http://www.codeproject.com/tools/prjconverter.asp to convert to a VC6 project.
While building the exe I got some messages indicating:
a) BIF_NONEWFOLDERBUTTON was an undefined constant
b) PRECOMP_VC7_TOBEREMOVED was not defined as a compilation option
As many people will still use VC6 I want to ask you if you would be so kind to make an update that is aware of that
|
|
|
|
|
Sorry but File Encryption Utility is based upon ATL7 for GUI classes.
ATL7 Library is only supplied with VC7 so simple converting will not be enough.
You can work with the code and copy it to any other project but the GUI can only be used using VC7.
Sorry for the inconvenient..
Nir
|
|
|
|
|
Hi, Nir
Your code is really brilliant! I've tested the demo project and
I think it's very useful. That's why I've decided to use your
article to help me to include the Blowfish crypting in my project.
But it's VC6 project and as you advised I tried to work with the
code and copy it to my project. I did that but I'm always getting error,
when I try to use BlowFishEnc::encryptStream method:
error LNK2001: unresolved external symbol "public: virtual __thiscall BlowFishEnc::~BlowFishEnc(void)" (??1BlowFishEnc@@UAE@XZ)
error LNK2001: unresolved external symbol "public: virtual unsigned long __thiscall BlowFishEnc::encryptStream(char const *,unsigned long,char *)" (?encryptStream@BlowFishEnc@@UAEKPBDKPAD@Z)
error LNK2001: unresolved external symbol "public: __thiscall BlowFishEnc::BlowFishEnc(char const *)" (??0BlowFishEnc@@QAE@PBD@Z)
Could you, please, advise me what to do, as I'm a new in c++, I tried everything I know but it didn't work?
Here is how I tried to use the Blowfish:
***
I've have Blowfish.h, Blowfish.cpp, Encryption_I.h and sboxs.h in my project's
main directory.
In my CPP file, where I want to use the Blowfish crypting, I have: #include "Blowfish.h"
The function where I try to call the BlowFishEnc::encryptStream method is:
void CEncDecFileView::OnBtnEnc()
{
CIPHER _cipher;
_cipher = ENCRYPT_METHOD;
char _readFile[MAX_PATH];
char _writeFile[MAX_PATH];
char _password[100];
strcpy(_readFile, "c:\\a.txt");
strcpy(_writeFile, "c:\\b.txt");
strcpy(_password, "asdasd");
FILE *readFile = fopen(_readFile, "rb");
if (readFile == 0)
{
MessageBox("Unable to open source file (fopen).");
return;
}
const size_t bufferSize = 1024;
int barSize = 0;
// reaching the end of the file and getting position = getting file size (bytes).
fseek(readFile, 0, SEEK_END);
barSize = ftell(readFile);
fseek(readFile, 0, SEEK_SET);
if (barSize == -1)
{
MessageBox("Unable to get file size (_filelength).");
return;
}
barSize = barSize / bufferSize;
char outfile[MAX_PATH];
strcpy(outfile, _writeFile);
FILE *writeFile = fopen(outfile, "wb");
if (writeFile == 0)
{
MessageBox("Unable to open destination file.");
return;
}
char readBuffer[bufferSize];
char outBuffer[bufferSize];
size_t readRet = 0;
BlowFishEnc encryption(_password);
bool abort = false;
int encRet;
while (!feof(readFile))
{
readRet = fread(readBuffer, sizeof(char), bufferSize, readFile);
encRet = encryption.encryptStream(readBuffer, (DWORD)readRet, outBuffer);
fwrite(outBuffer, sizeof(char), encRet, writeFile);
}
fflush(writeFile);
fclose(writeFile);
fclose(readFile);
ZeroMemory(outBuffer, bufferSize);
ZeroMemory(readBuffer, bufferSize);
}
***
Can you help, please?
Thanks in advance!
Yasen
|
|
|
|
|
Hey!
first, thanks for the comment
From the compiler/linker output you pasted i can see that you didnt link the project correctly.
I believe that you didnt add the CPP files (with the matching names to the H files you included) to the project (not only to the folder but also to MSDEV project).
If you want a more in-depth help send me the project and i'll try fixing it for you.
you can always contact me at ICQ 14515706 or dreamer@netvision.net.il
cheers,
nir
Nir Dremer.
|
|
|
|
|
I am a developer working on a solution for a client that requires that I use the blowfish algorythm for enc. Unfortunately, I do not know C++. Would it be possible for you to package up and post to this site a .NET control containing only the blowfish encrypt and decrypt methods so that they can be implimented from an asp.net page?
Thank you!
|
|
|
|
|
I'm very sorry but the OS i'm using now is Linux and as you can guess i dont have .Net
But i would suggest you to check wwww.counterpane.com which is the site of Bruce Schnier (hope i got it right) who is the inventor of Blowfish and he got tons of links to sources in almost all languages implementing the algorithm.
another alternative is to use the encryption already exist in the .Net - check the other comments, they might help you out.
Nir Dremer.
|
|
|
|
|
Why another encryption utility when Windows provides a secure filesystem?
If you go for "yes, but I can take the files with me or send by mail" - sure, but you can take your files on a EFS media with you too, and mail, well, encrypted mail would be the choice for security here.
I'm missing the reason for this tool. Homegrown encryption (almost) always is unsecure, no matter which algo it uses.
Besides of this, it seems to be cleanly implemented.
...make it about Visual C++, and don't ever mention Visual Basic. Nick Hodapp (MSFT) in Semicolon[^]
|
|
|
|
|
I will start by saying that this is NOT an homegrown encryption - and not even anything close to that!!!
The encryption used here is 100% Blowfish, if you have any product that does not require any header in the encrypted file you can decrypt the file using it (and the password).
In comparison between Open Source Encryption (with known & proved algorithm) vs. close source with unknown algorithm - guess what i choose ??
Just for the fun of it, here are few reasons not to use EFS:
1. EFS requires windows 2000 and above (except XP home).
2. EFS requires NTFS5 file system.
3. EFS requires configuration by the user (time & complexity overhead).
4. Unknown cipher algorithms (at least i haven't found any details).
5. Close Source.
as opposed to File Encryption Utility which is:
1. Open Source.
2. OS Independent (Win2k and below can run it).
3. Simple - A. You can encrypt/decrypt in seconds.
B. You can create encrypted executable which makes it much more easier and undependent of the target environment.
Hope you agree with me now,
Nir
Nir Dremer.
|
|
|
|
|
Nay, still no way to agree
Nir Dremer wrote:
1. EFS requires windows 2000 and above (except XP home).
2. EFS requires NTFS5 file system.
Fine, and? If you need security you wont do it under Win9x, but use NT instead.
3. EFS requires configuration by the user (time & complexity overhead).
Is creating/importing a certificate too much? If you are in an security sensitive environment you have that anyway. (any many much, much more painful things)
Set the encrypted flag on a folder, disk or file and you will never again think about encrypting your files.
4. Unknown cipher algorithms (at least i haven't found any details).
Since it is based on the Window CryptAPI it can only use whatever cypher you have installed there. Lookup the installed cyphers and their usage.
5. Close Source.
And? how many applications that you use every day are closed source? Does that matter?
On the other side, Windows includes also recovery mechanisms for encrypted files.
This is definitely an advantage.
Sorry for the late response.
I don't think this is a serious possesion, and the evil most likely comes from your hand. Colin J Davies, The Lounge
|
|
|
|
|
I will start by saying that everyone is entitled to think as he/she wants
You're coming from the approach that Windows is the only operating system.
I'm working in parallel on Windows and on Linux/Unix Operating systems.
There are many utilities that do what I just did in the article.
Many of those lake of one or more of the issues I raised the last post (including MS OS support).
I've wrote the utility not because I had spare time, but because I had no alternative (in the few minutes I searched the web ).
Cheers,
Nir Dremer.
|
|
|
|
|
Thanks.
Talking about cross platform is a completly different thing, here I agree with you (but hey, ATL7 is not cross platform ).
Since CodeProject is a strictly Windows site it didnt come into my mind that your code might be cross platform. Sorry.
I don't think this is a serious possesion, and the evil most likely comes from your hand. Colin J Davies, The Lounge
|
|
|
|
|
Andreas Saurwein wrote:
Nay, still no way to agree
>Nir Dremer wrote:
>1. EFS requires windows 2000 and above (except XP home).
>2. EFS requires NTFS5 file system.
>
>Fine, and? If you need security you wont do it under Win9x, but use NT instead.
So basically you're saying run NT or forget having secure communications and files? So now you've limited yourself to share encrypted data with someone one NT or above AND they have to be in your active directory. What about the other 5billion people in the world?
>4. Unknown cipher algorithms (at least i haven't found any details).
>
>Since it is based on the Window CryptAPI it can only use whatever cypher you have installed >there. Lookup the installed cyphers and their usage.
Acutally, the EFS is using the DESX algorithm plus RSA public/private keys. So you've selected an encrytption system that is just as vulnerable to linear and differentials attacks as standard DES with slightly higher brute force key attack strength. Not even close to BlowFish, not even as good as DES3. Simply put, I don't think EFS is used by the security community, it looks like more of an administrative headache.
>5. Close Source.
>
>And? how many applications that you use every day are closed source? Does that matter?
You need do some research into encryption first dude. Security through obscurity never works. In fact the US government cryptography standard when through a very extensive public process in order to determine which algorithm would provide the highest level of security. It's the same as exposing a server to the net and offering a prize to anyone who can hack it. You get a better system by allowing others every advantage possible to defeat it. Closed source is about profits and protecting intellectual property that gives a competative advantage. Don't you think that if MicroSoft had a better system they would want the US to adopt it as the defacto standard, a lot more money in that.
>On the other side, Windows includes also recovery mechanisms for encrypted files.
>This is definitely an advantage.
Hmm, well from what i've read on Sysinternals (you should check it out) this "falesafe" recovery mechanisms can be used to fairly easily defeat the system. The whole point of encrypting something is that you need the key to access it. If you can "recover" the key then your system is only as good as the key recovery mechanism. A chain is only as good as it's weakest link.
I think before you trash someone elses work you should look at the big picture, I can think of tons of uses for this.
But to the author of this app, looks like a great little util, i would have prefered if you had used AES instead of blowfish but its really clean and usable. The self extracting is great, and the integration with the context menu is slick too.
|
|
|
|
|
While it is already pretty pointless (did you read the other posts in this thread?), let me answer some of your points:
nicthiessen wrote:
So basically you're saying run NT or forget having secure communications and files? So now you've limited yourself to share encrypted data with someone one NT or above AND they have to be in your active directory. What about the other 5billion people in the world?
As I mentioned already in another thread, we are talking here about Windows (remember, codeproject is a Windows site?). Now, how many of your "5billion" are using Windows? Fine. These few people still have to
a) use this utility (or a ported version to another OS)
b) transmit the password for the encryption to the recipient
While (a) might be possible, (b) causes a major headache for 99.9% of these 5 billions because they would just send the file together with the password in a mail. Bingo.
nicthiessen wrote:
Acutally, the EFS is using the DESX algorithm plus RSA public/private keys. So you've selected an encrytption system that is just as vulnerable to linear and differentials attacks as standard DES with slightly higher brute force key attack strength. Not even close to BlowFish, not even as good as DES3.
Simply wrong. EFS can use any of the installed CSP's. DESX, 3DES, AES, whatever you like as long as you have got a CSP for it.
nicthiessen wrote:
You need do some research into encryption first dude. Security through obscurity never works.
Been there, done that. None of the security features of Windows (NT/2k/XP/2003) is a secret (almost). The CSP's are publicly available information. Many 3rd party CSP's exist long time (wrote one myself), although some of questionable quality. The only obscurity here are developers without a clue, trying to "use" encryption without even knowing what it is supposed to do.
nicthiessen wrote:
Hmm, well from what i've read on Sysinternals (you should check it out) this "failsafe" recovery mechanisms can be used to fairly easily defeat the system.
So far there havent been any concerns on the key recovery as far as I know. Although I didnt find any information which points towards a flaw in this mechanism, you still have the option of NOT enabling the key recovery.
Then even you are on the safe side.
Leon[^] - Enterprise Anti-Spam Server
|
|
|
|
|
Maybe you can clarify this for me, but it seems that EFS and the file encryption utility are meant for different applications. Where efs is aimed mainly at protecting your own files on your own pc or on your network shares, it is not designed for sharing encrypted data with people outside of you windows network. ie. the windows user on company B's network won't have the keys to decrypt the file since their identity couldn't have been added to the key list, so you can't send them an encrypted file.
However this utility was designed to be able to share encrypted data with other contacts outside of your network. All you need is a password. Obviously you'll need to ensure the password is sent safely, not open text in an email, but EFS has exactly the same problem. But now you're not limited to access lists, and you can have separate passwords for every file. My understanding of EFS is once you gain access to someones PC with their login you now have full access to all of their encrypted data.
Maybe you like EFS, that's fine. I don't see a lot of merit in it, but then i have nothing to hide within the company that i work for.
My need was to send an encrypted file via email, efs couldn't do it (i tried, the user didn't exist on the access list, couldn't add him), this app could.
On the side, i'll take your word about the addition of CSP's, but doesn't that then reduce the usefullness since everyone you share with has to have that CSP now? Although i suppose since you're all on the same network it would be easy to transfer. Still that's another of the nice features of this utility, it can make a self extracting file. That's pretty slick, all you need is the right password, and the password isn't stored in the file so it's a strong as the encryption technology.
i'm not trying to bash you, i apologize if i came off that way.
nic
|
|
|
|
|
I think Ruud Van Nistelrooy and Saha is the best partnership in europe.
|
|
|
|
|
Thanks for this excellent and enlightening comment. Whouldnt know what to do without it.
Leon[^] - Enterprise Anti-Spam Server
|
|
|
|
|
Why choose to implement something new now using Blowfish when Schneier et al moved to Twofish as their state of the art years ago?
|
|
|
|
|
Both blowfish and twofish are excellent block-ciphers.
Both are currently being used by many applications.
I've NOT heard about any moving toward twofish.
both algorithms are considered to be very secure.
The fact that one of them is newer does NOT give him the privilige to be better (it's usually the other way arround).
Feel free to implement Twofish for the file encryption utility
(btw: Even the latest attacks which put AES and Serpent in danger are a minor hazzard (and even not at all) to blowfish.)
Nir Dremer.
|
|
|
|
|