Looking for the most secure command line encryption program

[slavvo67]

I use ccrypt right now but I've see that it's not AES256, so looking to see what I may use to replace it. I know 7zip is out there but wanted to see what everyone is using and what is considered the most secure.

Thanks,

Slavvo67

[rufwoof]

To what end?

The most secure is likely One Time Pad (OTP) - future proof. I wrote a program for that a few years back. Not sure if it still works though as I haven't reviewed it in a long while. http://murga-linux.com/puppy/viewtopic.php?t=102350

Mathematically OTP is the only method proven uncrackable (provided the pad is truly random and used only once). Any viable decryption is as probable as any other viable decryption such that even if a meaningful deciphered/clear text was identified then there's no guarantee that was the correct solution.

Clear text and pad/key are the same length, so you can share one or the other, but cannot decipher without both (each is in effect the key to the other). The downside is conveyance of the key if intended to share the clear text content across distance.

[slavvo67]

Thanks. I'm going to revisit this... Any others?

So, I basically want a command line tool for encryption that is know to be very secure. Being EAS256 has been a proven government standard, I was seeking something along those lines.

I have a front end that I put on top of ccrypt, which works quite well but I was looking to replace the ccrypt code with something thought to be stronger...

[jafadmin]

For disk encryption, use "dmcrypt". For file encryption, I use "openssl".

Both tools do AES256.

[Wognath]

I use gpg, e.g.

Code: Select all

gpg -ca --cipher-algo AES256 file1 && shred -u file1

>edited: wording
**As you probably know, shred is pointless on a ssd according to what I read

[slavvo67]

I've tested openssl to encrypt and decrypt. The problem. I'm seeing is that it keeps the unencrypted file, which if then deleted, can be undeleted....

It also seems to have an option to overwrite but for me, it looks like that method created corrupted data on my test .mp3 file.

Still playing with this as it seems a pretty viable solution..

[slavvo67]

So, Openssl does not write in place, so for me it almost defeats the purpose of using. I guess if you are encrypting and transferring to another drive it would be ok. Ccrypt overwrites the old file with the encrypted on, so as of right now, it seems the better option.

I'll check out the others mentioned above... Thanks again....

[williams2]

openssl ... keeps the unencrypted file, which if then deleted, can be undeleted

afo (Aggressive File Obliterator) is supposed to overwrite files properly, so that the file is completely and permanently erased.

It seems to run in BionicPup64 without the 32 bit compatibility sfs. I don't know if it really is doing what it is supposed to be doing.

rufwoof says:

One Time Pad (OTP) - future proof. I wrote a program for that a few years back

/dev/urandom utilises hardware/environment to induce randomness

I think /dev/urandom is just a simple pseudorandom number generator
(n=a*n+b)

I think it is /dev/random that generates better randomness using hardware/environment.

It can be difficult to be sure an encryption program works well.

For example, if you use a one time pad to encrypt an ascii message, most or all of the bytes in the message will be numbers less than 128, that is, the msb will be 0. So after encryption using xor, all the bytes in the encrypted message will also be less than 128, that is, the msb will also be zeros.

Zipping the message then encrypting it using something like bcrypt or openssl and then using a one time pad might address that problem.

I wrote a simple one time pad program in puppybasic (actually wxbasic bvmc, Moose On The Loose's 32 bit puppybasic doesn't run in BionicPup64)
padenc.bas

Code: Select all

f=FOPEN("msg1","r")
g=FOPEN("RandomNumbers","r")
h=FOPEN("msg1.enc","w")

WHILE NOT EOF(f)
    a=READBYTE(f)
    b=READBYTE(g)
    c=XORBITS(a,b)
    WRITEBYTE(h,c)
END WHILE

paddec.bas

Code: Select all

f=FOPEN("msg1.enc","r")
g=FOPEN("RandomNumbers","r")
h=FOPEN("msg1.dec","w")

WHILE NOT EOF(f)
	a=READBYTE(f)
	b=READBYTE(g)
	c=XORBITS(a,b)
	WRITEBYTE(h,c)
END WHILE

I don't think I can get it any simpler or smaller in puppybasic.

I got the one time pad (the file RandomNumbers) from
https://www.random.org/

[rufwoof]

Yes, data should be compressed first so that there are approximately equal numbers of all bytes.

Re urandom ... https://www.2uo.de/myths-about-urandom

For more randomness you could read system events perhaps such as the cpu temperature every x seconds and reseed or skip that number of random source bytes. Or intermix with the volume level whilst playing a CD/mp3 at the time with random sleeps between samples ..etc. Or even just xor'ing your random stream with that from random.org. Pretty much unlikely to ever be 'calculated'.

[williams2]

Re urandom ... https://www.2uo.de/myths-about-urandom

Yes, I was just reading that. I was going to post the link to support your position, but you beat me to it.

[rufwoof]

In the early 1990's 40 bit keys were used for encryption. By the late 1990's such keys were being cracked in 2 seconds, and even for the 56 bit keys it was only taking days. With more recent power levels .. !!!

What seems strong now will likely be trivial in the future. One time pad has mathematically be proven to be future proof. Even if you try all possible keys that you get all possible plain-text results, you have no method of choosing which one is right. With other methods there's a solution that will clearly be the correct one.

[slavvo67]

Thank you all for the continued input. Now, if files need to be compressed to be approx an equal number of bytes, that seems to be n issue. So, I could have a directory with a text file, a large spreadsheet file, music files, video files, etc. I doubt that I could get vids and text down to similar bytes by compressing. Is that what you're saying or am I misunderstanding?

Using afo after is, IMHO a ridiculous option. I know my question is for the most airtight encryption but there's a practical aspect of not waiting 5 hours to encrypt 1TB or less less of data. If you overwrite at point of encryption, no need to wait forever to wipe the free space.

I know, I know...always the trade off of time vs security, as well. If encryption takes hours, then i think the common person would not use it or will wait longer intervals before using.

[williams2]

I use ccrypt right now but I've see that it's not AES256

From the ccrypt faqs page
http://ccrypt.sourceforge.net/faq.html

Ccrypt uses strong 256-bit encryption which is currently considered to be unbreakable. Technically speaking, ccrypt uses the Rijndael block cipher. Rijndael was also chosen for the "Advanced Encryption Standard" (AES)

It seems that ccrypt is 256 bit AES.
Standard AES uses a 128 bit block size.
ccrypt uses a 256 bit block size, so it is AES but not quite standard AES.

It sounds like you can still use ccrypt if you like it,
it seems to be 256 bit AES.

Did you read somewhere that ccrypt was no longer safe?

Is that what you're saying or am I misunderstanding?

If you are referring to me, I was talking about one time pads (or any streaming cipher that uses xor, like arc4.) If you encrypt ascii text all the bytes would be numbers less than 128 which might make it easier to decrypt.

So you can ignore that comment, it doesn't really answer your original question. Sorry.

[williams2]

If you have been reading here:
https://security.stackexchange.com/ques ... lly-flawed
or
https://crypto.stackexchange.com/questi ... s-security
they seem to say that although ccrypt does not use standard 256 bit AES it is almost the same and probably just about as safe.

They say using a salt and processing the password in a loop to force the computer to work hard and spend time before the decryption starts would make brute force guessing the password harder.

That is probably true. Using a simple easy-to-guess password is not good whatever program you run.