Toucan software uses 256bit AES encryption using ccrypt (https://en.wikipedia.org/wiki/Ccrypt\)
i want to ask if its secure to use this ccrypt encryption for storing .TXT file with my passwords on cloud storage like Google Drive?
It's secure enough for some governments, so I'd say so.
1 Like
Haha.. not not the best metric to measure crypt security these days...
In case you missed the news, the US NSA paid RSA $10M USD to make a known weak cipher the default crypto in the RSA crypto toolkit used by many products and companies. This was done to create a back door so NSA could easily break the encryption.
On another note, the Rijndael cipher used in AES ccrypt has been the subject of a variety of successful attacks, for example (from the reference above):
So, it's not straightforward to answer questions like "Is ccrypt AES 256bit secure enough?" because the answer depends on what data you are trying to secure.
For the original poster, he says he wants to secure a ".TXT file with my passwords on cloud storage like Google Drive?" ... so that begs a number of security related questions:
Why store them on Google Drive? Why not store the encrypted data on a USB stick or burn it to a CD and keep it in a safe place off the net?
If the passwords are used to encrypt "casual" data and you are not concerned about governments or sophisticated criminals breaking your crypto, then perhaps it is OK to store your encrypted file on the net.
You should know that Google will make your files available to authorities without your knowledge under certain situations - so if you are doing things that make you a suspect to a government (like criminal activity, terrorism, etc.) then your AES crypto file on Google's cloud is certainly not secure and it can be accessed (by governments under certain conditions) and broken if required.
However, if you are just a normal person without a need for super secrecy and not a national security threat or criminal, you still need to realize that when you store on a cloud, it is really "not very secure" by definition. So you will be relying mostly on the strength of the crypto.
Now, if you have passwords protecting $100M USD of assets, then I don't think it's very secure to store these passwords on a cloud with ccrypt AES 256; and you should consider strong crypt with key length of 1024 or greater.
Risk is the intersection of many things (actually three things) - vulnerability, threat, and criticality.
Rijndael 256 has known vulnerabilities, so the rest of your risk management decision is based on threat and criticality. If you are not threatened by governments, criminals, or your ex-wife trying to get into your bank accounts (LOL) and you don't have anything so critical, then maybe you are "OK" using Rijndael 256 on a cloud.
However, I would not recommend it.
I would not recommend you store your encrypted password file on any cloud storage, and instead keep in on a UBS stick or similar "local" media that is easy for you to use, but very difficult for others to access.
And, if your data is very critical, the perhaps consider a 1024 bit key length versus 256.. or longer.
Hope this helps.
3 Likes
I have never heard of ccrypt and your link does not convince me that AES-256 is in use. I mostly use gpg for AES-256 bit encryption. Like this:
gpg -c --cipher-algo aes256 secret.txt
and to decrypt the file:
gpg secret.txt.gpg
Your link talks about using Rijndael, not AES. Read the AES page on wikipedia. Only 3 members of the Rijndael family are used in AES and all of them have a block size 128 bits. Your link says ccrypt is using a blocksize of 256 bits. I wonder if you have block size and key size confused? ccrypt may be good enough for your purposes, but based on your llink I will stay with gpg.
1 Like
I think the original poster (more-than-likely) meant 256 key size, not block size.
From the wikipedia reference:
.
The orgional poster mentioned:
Normally, I would interpret this to mean "256 bit key size" ...
.. and point of reference, the ccrypt man page says:
Also from the ccrypt man page:
Yeah, but read that page the OP linked. It's only 2 sentences or so. It says "However, in the AES standard a 128-bit block size is used, whereas ccrypt uses a 256-bit block size." I don't understand how someone can read that and conclude that AES is in use.
gpg (gnu privacy guard) is open source and should be immune to the back door intentionally placed in prodcuts. Your link about key recovery is worrisome. But they need both ciphertext and plaintext to recover the key.
The word here at work is that we are required to AES-256 still. As long as I can convince a security auditor that AES-256 is in use I am covered. I can do that with gpg. I would not want to try with ccrypt.
AES-256 is a symmetric key algorithm. What symmetric key algorithm would you replace AES-256 with? Those longer keys you mention are usually associated with public key encryption.
Our mandate to use AES-256 ultimately comes from the US Department of Defense who seems to feel that it is adequate protection.
1 Like
True. You are right... those longer keys are not really for symmetric crypto. I will look more into gpg (gpg - OpenPGP encryption and signing tool man page):
neo@www:~# aptitude search gpg
p gpgsm - GNU privacy guard - S/MIME version
p gpgv - GNU privacy guard - signature verification tool
p kgpg - graphical front end for GNU Privacy Guard
p libcrypt-gpg-perl - An Object Oriented Interface to GnuPG
p libgpg-error-dev - library for common error values and messages in GnuPG components (
p libgpg-error0 - library for common error values and messages in GnuPG components
p libgpgme++2 - c++ wrapper library for gpgme
p libgpgme-ruby - GPGME bindings for the Ruby language
p libgpgme-ruby1.8 - GPGME bindings for the Ruby language
p libgpgme-ruby1.9.1 - GPGME bindings for the Ruby language
p libgpgme11 - GPGME - GnuPG Made Easy
p libgpgme11-dev - GPGME - GnuPG Made Easy
p libqgpgme1 - library for GpgME++ integration with Qt
p pgpgpg - Wrapper for using GnuPG in programs designed for PGP
p php-crypt-gpg - PHP PEAR module for encrypting and decrypting with GnuPG
p python-gpgme - python wrapper for the GPGME library
p python-gpgme-dbg - python wrapper for the GPGME library (debug extension)
v python2.6-gpgme -
v python2.6-gpgme -
v python2.6-gpgme-dbg -
v python2.6-gpgme-dbg -
v python2.7-gpgme -
v python2.7-gpgme -
v python2.7-gpgme-dbg -
v python2.7-gpgme-dbg -
Thanks!
You can download the source code to any cipher and impliment it, strictly speaking, they are all open source, including MD6.
The block size and key size are always a factor but strictly speaking you should never need to impliment a stream cipher with a value greater than !n20
I should have called myself Kiss-Ass when I join your forum!
Lets look at what we can find and download for free on the Wiki...
RipeMD160 No attacks known. All results concern simplified variants.
Then we have Keccak, Fugue, ECHO, Blue Midnight Wish, Skein, Groestl, Tiger, Botan, SANDstorm, SWIFFTX... All with no known attack vector!
Some of them wont stand up to cryptanalysis but getting around them is a whole new kettle of fish!
!Enjoy
Dont you just love it when you read the news and hear people that dont know the first thing about programming saying "we'll decrypt the web"... Have they been smoking crack?
http://www.moviesounds.com/matrix/choice.mp3
Awesome thing about some of the technology in use before all this crazy crap started, some of it already impliments Open Hardware, that means the Cryptographic Hash Functions are built in, they have to be - to protect Buisness from Spies & Insider Trading! An it goes without saying to keep "the real Cyber Criminals" Out!