How can I encrypt a .txt file? - Developers

[QUOTE=ShaRose;20689572]That's compression, not encryption.[/QUOTE] Yeah I guess you're right but when you think of it it's almost like encryption. :downs:

[QUOTE=Sakarias88;20704261]Yeah I guess you're right but when you think of it it's almost like encryption. :downs:[/QUOTE] Just like an apple is *almost* like an orange! They're both related to growth of fruit! :downs: No, sorry. It's just encoding. Encoding isn't encryption, it's just changing the code used to hold a message. By your definition, your NIC encrypts your entire network traffic.

Use libcrypto from OpenSSL. The API is way over my head though, and the documentation is lacking.

[QUOTE=PvtCupcakes;20709267]Use libcrypto from OpenSSL. The API is way over my head though, and the documentation is lacking.[/QUOTE] You really want him to use p/invoke for this? It's VB. AND the documentation is lacking. Really, bouncy castle is his best bet. [editline]08:40PM[/editline] Though to be fair bouncy castle's documentation is a tad lacking as well, but it's fairly easy to figure out.

Depends how secure you want it. The tougher it is to break, the tougher it is to code, generally speaking. Here's a few options, ranked by security: 1. Simple XOR with a key. Have a variable, 128 bits or so, and, for every 128 bits in the file, XOR it with the key, then store the result. Decrypting is exactly the same. It won't hold up against someone trying to crack it if they know anything about crypto, but it'll stop most people from snooping. 2. RC4. There's bound to be a premade library you can use. If not, there's a small implementation on the Wikipedia page, about fifty lines or so. It's C, but translating it to VB would be easy. Can be cracked by a home computer, but not quickly. 3. AES. I don't think there's a plain VB library, but there's a couple .NET libraries that will do this. Very common algorithm, theoretically unbroken, but potentially crackable by the NSA. 4. Twofish, 256-bit. Similar to AES, but not likely to be broken for at least a decade, and likely to remain secure for quite some time. Problem is, I don't know of any easy-to-use libraries. There's a public-domain implementation that you could use as a basis.

[QUOTE=gman003-main;20711502]Depends how secure you want it. The tougher it is to break, the tougher it is to code, generally speaking. Here's a few options, ranked by security: 1. Simple XOR with a key. Have a variable, 128 bits or so, and, for every 128 bits in the file, XOR it with the key, then store the result. Decrypting is exactly the same. It won't hold up against someone trying to crack it if they know anything about crypto, but it'll stop most people from snooping. 2. RC4. There's bound to be a premade library you can use. If not, there's a small implementation on the Wikipedia page, about fifty lines or so. It's C, but translating it to VB would be easy. Can be cracked by a home computer, but not quickly. 3. AES. I don't think there's a plain VB library, but there's a couple .NET libraries that will do this. Very common algorithm, theoretically unbroken, but potentially crackable by the NSA. 4. Twofish, 256-bit. Similar to AES, but not likely to be broken for at least a decade, and likely to remain secure for quite some time. Problem is, I don't know of any easy-to-use libraries. There's a public-domain implementation that you could use as a basis.[/QUOTE] Way to read the thread. RC4 is broken, AES is weakened, and Why the hell would you use twofish instead of serpent. Xor is not even worth complaining about since it's been suggested already.

Alright alright, can a mod close this so people quit arguin'?

[QUOTE=Chad Mobile;20711685]Alright alright, can a mod close this so people quit arguin'?[/QUOTE] No, crypto argument threads are fun.

use md5! lololol

lol

[QUOTE=ShaRose;20701012]Why would you still use xor. At least use a good stream cipher, eStream suggested HC-256.[/QUOTE] What noctune9 described [i]is[/i] a stream cipher, actually. Generate a pseudorandom stream of bits (the "keystream") based on a secret starting value, and XOR it with the plaintext to obtain ciphertext.

[QUOTE=gman003-main;20711502]Depends how secure you want it. The tougher it is to break, the tougher it is to code, generally speaking. Here's a few options, ranked by security: 1. Simple XOR with a key. Have a variable, 128 bits or so, and, for every 128 bits in the file, XOR it with the key, then store the result. Decrypting is exactly the same. It won't hold up against someone trying to crack it if they know anything about crypto, but it'll stop most people from snooping. 2. RC4. There's bound to be a premade library you can use. If not, there's a small implementation on the Wikipedia page, about fifty lines or so. It's C, but translating it to VB would be easy. Can be cracked by a home computer, but not quickly. 3. AES. I don't think there's a plain VB library, but there's a couple .NET libraries that will do this. Very common algorithm, theoretically unbroken, but potentially crackable by the NSA. 4. Twofish, 256-bit. Similar to AES, but not likely to be broken for at least a decade, and likely to remain secure for quite some time. Problem is, I don't know of any easy-to-use libraries. There's a public-domain implementation that you could use as a basis.[/QUOTE] Just so you're aware, RC4 has long been considered to be broken in practical systems, see [url]http://en.wikipedia.org/wiki/RC4#Security[/url]. I'm not even going to bother talking more about RC4 or about your XOR proposition. Additionally, AES256 is vulnerable to a key distinguisher attack, a related key attack, and a boomerang attack which was recently discovered. This means AES256 is PRACTICALLY broken, in the sense that it should not be implemented in new systems. AES192 is still fine to use, but one should not use it simply because of the potential to discover attacks similar to the ones that work with AES256. AES128 does not offer a heavy enough of a security margin to be used these days. AES128 gives us a 64-bit security margin. AES128, AES192, and AES256 can all be cracked by home computers, just not quickly. In fact, every cipher can be cracked by home computers, some quickly and others not so quickly. So, your earlier comment about that was pretty irrelevant. Serpent offers what no other block cipher can offer right now. Serpent has a 256-bit key size and offers a 128-bit security margin. Serpent has no known attacks on it and has undergone some decent cryptanalysis for quite some time. It has benefits over Twofish, such as not being vulnerable to truncated differential cryptanalysis. Twofish is considered to be practically broken in systems that stream data continuously, or for file encryption. It can however be used in domains similar to what you would use TEA (a long broken block cipher), such as ONE TIME session based password encryption. A one time session is basically a session where you receive a unique key when you connect, you combine your static long term key with it through the use of XOR, and then use the derived key as your real key, and then encrypt your password and send it to the server and then never send anything else using that key. Just informing you and others that not everyone here really knows what they're talking about and that maybe some of you should consider the advice given to you by people who have studied cryptography for quite some time.

[QUOTE=Wyzard;20711958]What noctune9 described [i]is[/i] a stream cipher, actually. Generate a pseudorandom stream of bits (the "keystream") based on a secret starting value, and XOR it with the plaintext to obtain ciphertext.[/QUOTE] I said good. I know it's a basic stream cipher. It's the default 'encryption' used in ECIES, when it uses ECDH to generate a shared secret which is then used to salt a random number generator, which is then xor'd with the plaintext. I would really just keep people away from xor though.

But it's not XOR that's the problem, it's the source of the keystream. XOR with the output of a good stream cipher is fine. XOR with the output of rand(), or the constant value 15, is bad. BTW, with all this talk of stream ciphers, I should add that anyone thinking of using one should make sure to never use the same key twice. That's very insecure, for the same reason one-time pads can't be reused: if you take two ciphertexts encrypted with the same keystream and XOR them together, the result is the two plaintexts XORed together with the cipher completely gone, and that's much easier to break.

[QUOTE=ShaRose;20711659]Way to read the thread. RC4 is broken, AES is weakened, and Why the hell would you use twofish instead of serpent. Xor is not even worth complaining about since it's been suggested already.[/QUOTE] Way to read the post. I said that RC4 is breakable, and that AES is theoretically weaker. As for the twofish/serpent thing, who cares?

I would say to start with something simple... Try [url]http://en.wikipedia.org/wiki/Caesar_cipher[/url], for example, it should be very easy to implement, and it will encrypt the file, although in a very basic way, it would be easy to decrypt, but it's a nice start.

Just use the bult-in .NET AES or DES encryption with a pre-defined key for you program. I made one that encrypted any file using a key generated from another file. (So the only way you'll lose the key is when you delete the "key" file)

[QUOTE=gparent;20704531]Just like an apple is *almost* like an orange! They're both related to growth of fruit! :downs: No, sorry. It's just encoding. Encoding isn't encryption, it's just changing the code used to hold a message. By your definition, your NIC encrypts your entire network traffic.[/QUOTE] [quote=http://en.wikipedia.org/wiki/Encryption] In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. [/quote] Compressed data of which an attacker does not know the algorithm does qualify that definition.

One of the fundamental assumptions in cryptography is that the attacker [I]does[/I] know the algorithm. If he doesn't, all the better, but ciphers are designed to be strong even if the attacker has full knowledge of how they work. All the secrecy has to be in the key. An algorithm that has no key, like a compressor, doesn't qualify. Quoting Bruce Schneier: [quote]If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world's best safecrackers can study the locking mechanism — and you still can't open the safe and read the letter — that's security.[/quote]Data compressed with an unknown algorithm is more like the former than the latter.