I'm going to make this quick and dirty as my first question drew complaints that it was too long. I'm working on a cryptography assignment and I'm having a little trouble with it. I'll post the question then outline the specific area I'm having issues with. Hopefully I may garner a little mroe information that way.
Assignment question
Either download openssl to encrypt a message using DES, or download a python script to perform the encryption and
decryption.
5
(a) Encrypte the phrase:
In the spring of 1861, decades of simmering tensions between the northern and southern United States
over issues including states’ rights versus federal authority, westward expansion and slavery exploded
into the American Civil War (1861-65).
Use DES with the following information: CTR mode; no salt, no IV, with the key, in hex, of the last 64 bits of
the SHA-1 hash of your student ID. Include appropriate screen shots and other evidence to convince me you have
done the encryption.
(b) Verify the "complementation property"
1
of DES. For the message, use the 64 bits, in hex: 2df87ac380f2f4c1. Use
the same key as in the previous part.
My question
Okay SO! I'm not asking for you guys to do my question (although if you want to throw some good directions for me to head I'm totally up for that.
What I do need is clarification on a couple of things.
First of all, I installed openssl with Cygwin and upon trying to encipher the file I hit a number of hitches that completely threw me in regards to the question.
For some reason I have no idea where to put a plaintext file so Cygwin can path directly to it. Trying to use the whole path of the .txt seems to yield errors. So where would I put the plaintext into openssl/cygwin to read directly? (i.e where is it's "root")
(trying a generic encryption command yields an error
"aes-256-cbc -a -salt -in secrets.txt -out secrets.txt.enc
secrets.txt: No such file or directory
2674688:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('secrets.txt','rb')
2674688:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
error in aes-256-cbc
")
Cygwin openssl doesn't seem to come with CTR mode, and CTR mode definitely requires an IV so I presume my professor wants me to do it with all of these options. Do I have to import or otherwise acquire the CTR cipher?
Any other tips on where to get started on this question would be fantastic.
I can't post many URLs but I do want to demonstrate I have done at least some research so I've compiled the lsit of links in a pastebin here: http://pastebin.com/GDhq7GmQ
Anyways I suck at this subject but I do want to do very well, so any inroads you guys can give me would be very appreciated.
Humbly yours,
a slowly failing ITSec firstyear.
I think you are supposed to use the SSL as a library, not as a CLI tool. CTR is not hard to create using "raw" block encryption. There is a encryption mode that is more or less "raw" block encryption.
It's a bit strange that you need to use the last bytes of the SHA-1 hash as a key, normally the first (leftmost) bytes are used.
Related
I have a school project in which I must use brute-force attack to recover the password of an encrypted RAR file. It is obvious that using brute-force on AES256 encryption system is not very useful but the aim of the homework is learning about brute-force so cracking speed is not important. Dictionary attack and known plain text attack is not permitted by the teacher. And I've learned from the posts I've read in this website that these methods are not much better at cracking passwords when it comes to AES either.
From studying various RAR extracting libraries including the official winRAR source code (found in rarlab.com) and the source code of a populer password cracking software called John the Ripper, I realized that finding the hashed key from the RAR file is impossible (This topic was discussed in another question on this website too) .
So the only actual way to actually try brute-force attack on an encrypted RAR file is extracting the archive with the guessed password and calculating CRC32 checksum to see if the files are extracted correctly.
From a RAR-unlocker source code I found the polynomial of CRC32 which is :
X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0
The source code is here: https://github.com/RaMMicHaeL/RAR-Unlocker/blob/master/crc32.cpp
Now my problem is, even though I said at the beginning that cracking speed is not very important, I can't afford to extract to whole archive and calculate CRC32 for every guess. For a big file this could mean minutes for every single try.
So I figured that if I could extract only a small part of the archive(let's say, a couple of bytes) with my guessed key and calculate the CRC32 checksum to see if the files are extracted correctly, I can use the same key to extract the whole file too.
This is where I am right now. I'm very new to cryptography so I am not %100 sure what I proposed above is possible at all. If it is, what is the smallest amount of bytes I can extract from the archive that can be used for checksum? How can I extract my selected amount of bytes from the archive?
Thanks.
In the answers in this question I found a reply: TurboPower LockBox 3: AES128 and padding ISO 10126
(2) For most chaining modes, TPLB3 will automatically add salt. This is normally a good thing, but if you need it without, you can remove the option for it.
How can I do that? Namely I need encryption which has the same cipher text length as the plain text length.
Assuming that you are not using ECB, the simplest way would be to remove the first 8 bytes of the ciphertext. The first 8 bytes (64 bits) is the salt nonce. It is also the low 64 bits of the IV. The high 64 bits of the IV are zero.
Please note: Not salting your messages is very bad practice and a security weakness. (Refer to wikipedia for more information). You say you need encryption which has the same ciphertext length as the plaintext length. This is basically saying, you want weak encryption. It's up to you, but my advice is the think about your requirements very carefully before proceeding.
An alternative technique would be to create your own chaining mode and register it in the cryptographic library. For example, if you wanted CBC without salt, create a class descendant from TCBC (unit TPLB3.CBC) and just override the ChainingFeatures() function to add the cfNoNounce feature. Refer to in-line comments in unit TPLB3.BlockCipher. However, my recommendation is the first method.
You might also like to read answers to related questions:
AES Encrypt/Decrypt Delphi & PHP
TPLockBox3 and PHP - AES Encrypt in Delphi, Decrypt in PHP
Turbopower Lockbox3 - Can I control initialization vector and padding for AES-256 encryption?
Also note that if you are using ECB chaining mode, there is no salt, was this mode has the cfNoNounce feature automatically. (ECB is bad. Don't use it, except for testing purposes).
Footnote:
I am the main author of TPLockBox 3, and I maintain the version of the library at:
http://tplockbox.googlecode.com/
http://lockbox.seanbdurkin.id.au/HomePage
I assume that you are using that version, and not the SourceForge one. I am expecting to release version 3.6.0 on 7-Nov-2014.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading up on file encryption lately, and In many places I've seen warnings that encrypted files are susceptible to decryption by people so inclined regardless of encryption algorithm strength.
However, I can't get my head around how someone would go about attempting to decrypt an encrypted file.
For example, lets say you've got an encrypted file and you'd like to know it's contents. You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. What do you do? (Assume for this example that the encryption algorithm is a symmetric-key algorithm such as AES-256, I.E. a file encrypted with key which requires said key to decrypt it).
Additionally, how would your approach change if you knew the encryption algorithm used? (Assume in this case that the encryption algorithm used is AES-256, with a random key + salt).
There's two ways to answer this question, in the literal sense of how a perfect crypto system is attacked, and how real world systems are attacked. One of the biggest problems you'll find as you begin to learn more about cryptography is that selecting algorithms is the easy part. It's how you manage those keys that becomes impossibly difficult.
The way in which you attack the basic primitives depends on the type of algorithm. In the case of data encrypted by symmetric ciphers like AES you use Brute force attacks. That is, you effectively try every key possible, until you find the right one. Unfortunately, barring changes in the laws of physics trying every possible 256-bit key can't be done. From Wikipedia: "A device that could check a billion billion (10^18) AES keys per second would in theory require about 3×10^51 years to exhaust the 256-bit key space"
The problem with your question about coming across a seemingly encrypted file, with no knowledge of the methods used, is that it's a bit of a hard problem known as a Distinguishing Attack. One of the requirements of all modern algorithms is that their output should be indistinguishable from random data. If I encrypt something under both AES and Twofish, and then give you some random data, absent any other information like headers, there's no way for you to tell them apart. That being said....
You asked how knowledge of the algorithm changes the approach. One assumption cryptographers usually make is that knowledge of the algorithm shouldn't affect security at all, it should all depend on the secret key. Usually whatever protocol you're working with will tell you the algorithm specifications. If this wasn't public, interoprobility would be a nightmare. Cipher Suites, for example, are sets of algorithms that protocols like SSL support. NIST FIPS and the NSA Suite B are algorithms that have been standardized by the Federal Government, that most everyone follows.
In practice though, most crypto-systems have much larger problems.
Bad random number generation: Cryptography requires very good, unpredictable random number generators. Bad random number generators can completely collapse security, as in the case of Netscape's SSL implementation. You also have examples like the Debian RNG bug, where a developer changed code to satisfy a memory leak warning, which ultimately led to Debian generating the same certificate keys for every system.
Timing Attacks: Certain operations take longer to execute on a computer than others. Sometimes, attackers can observe this latency and deduce secret values. This has been demonstrated by remotely recovering a server's private key over a local network.
Attacks against the host: One way to attack a cryptosystem is to attack the host. By cooling memory, its contents can be preserved and inspected in a machine you control.
Rubber hose cryptanalysis: Maybe one of the easiest attacks, you threaten the party with physical harm or incarceration unless they reveal the key. There has been a lot of interesting case law on whether or not courts can force you to reveal crypto keys.
AES256 is effectively unbreakable.
From http://www.wilderssecurity.com/showthread.php?t=212324:
I don't think there's any credible speculation that any agency can
break a properly implemented AES. There are no known cryptanalytic
attacks, and actually bruteforcing AES-256 is probably beyond human
capabilities within any of our lifetimes. Let's assume that 56 bit DES
can be bruteforced in 1 sec, which is a ridiculous assumption to begin
with. Then AES-256 would take 2^200 seconds, which is 5 x 10^52 years.
So, you can see that without any known weakness in AES, it would be a
total impossibility within any of our lifetimes, even with quantum
computing. Our sun will explode, approximately 5 billion years from
now, before we obtain enough computing power to bruteforce AES-256
without a known weakness. IF a weakness in AES is never found, there
is absolutely no reason to ever look for another cipher besides AES.
It will suffice for as long as humans occupy the planet.
With basic Brute force attack for example. You ask a software to try every single combination between 1 character to 15 character with a-z A-Z 0-9 and wait.
The software will start with 0 to 10... then 0a, 0b, 0c until it finds the password. Wikipedia will give you more detail.
I partially agree with Andrew and partially with Jeremy.
In the case, if encryption key is generated correctly (random generated or based on complex password, good key derivation function and random salt) then AES256 is effectively unbreakable (as Andrew said)
On other hand, if a key isn't correctly generated. As example, just straight hash of 4 digit's PIN password, brute force could be very efficient.
Regarding "You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. "
In most case, encrypted files has a header or a footer which specify something (an application used to encrypt a file, encryption algorithm or something else).
You can try to figure out algorithm by padding (as example 3DES has padding and AES has different padding)
I don't know much about the heavy math behind cryptosystems, I get stuck when it gets bad with the Z/nZ algebra, and sometimes with all these exponent of exponents. It's not I don't like it, it's just that the information you find on the web are not easy to follow blindly.
I was wondering: how reliable can a algorithm be when it encodes a message into plain binary. If my algorithm is arbitrary and known only to me, how can a cryptanalist study an encrypted file and decrypt it, with or without having the decoded file ?
I'm thinking about not using ASCII text to code my message, and I have some ideas to make this algorithm/program.
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him, but how does he do then ?
I don't know if I understanded well, but a CS teacher once told me that codes are harder to crack that crypted ciphers.
What do you think ?
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him...
What about:
Attacking an untested self written algorithm with no real research is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with, is a well known and proofed one, that has been correctly used....
In short, DO NOT roll your own cryptography unless you're an expert, no unless you're part of an expert group in that field.
Nintendo failed when they implemented RSA on their own in the Wii, Sony failed too when using it in the PS3 (they pretty much used XKCD's random number function for M...)
And you really think you can win by using security by obscurity?
PS: That doesn't mean that you should take the Wikipedia entry on RSA and roll you own implementation from that one (that's exactly were Sony and Big-N failed), no use a tested, open source implementation.
You seem to be using two words interchangeably but remember that Encoding is Not Encryption
When the attacker has no idea which algorithm you used and it is safe, cryptoanalyst has a hard job. So it is unimportant if you use AES or your own cipher as long as it is as strong and safe as AES. Here is the but. Cryptography is a bit demanding and therefore you have many ways to shoot yourself in a foot without knowing it. I would suggest using standard algorithms, maybe with some safe variations.
Common wisdom is that you should not build your own algorithms, and especially not rely on these algorithms remaining secret.
The conceptual reason is that good encryption is about quantified confidentiality. We do not want our secrets to get cracked, but in a more precise way we want to be able to tell how much it would cost to crack our secrets (and hopefully show that the cost is way too high to be envisioned by any entity on Earth). This is the real advance which occurred a few years after World War II: to understand the distinction between key and algorithm. The key concentrates the secret. The algorithm becomes the implementation.
Since the implementation is, well, implemented, it exists as some code or a device, which is tangible and stored even when it is not used. Keeping an implementation secret requires keeping track of the hard disk on which the code resides at all times. If the attacker sees the binary code, he may be able to reverse-engineer it, something which depends on his wits and patience. The point here is that it is very difficult to be able to say: "it costs X dollars to recover a description of the algorithm".
On the other hand, the key is short. It can be stored safely much more easily; e.g. you could memorize it, and avoid committing it to any permanent storage device. You then have to worry about your key only at times when you use it (and not when you do not, e.g. in the middle of the night, when you sleep). The number of possible keys is a simple mathematical problem. You can easily and accurately estimate the average cost of enumerating the possible keys until your key is found. The key is a sturdy foundation for quantified security.
So you should not roll your own algorithms because then you do not know how much security you get.
Also, most people who rolled their own algorithms found out, usually the hard way, that they did not get much security at all. Designing a good encryption algorithm is hard, because it cannot be automatically tested. Your code may run, and properly decrypt data that it encrypted, but it tells you nothing about how secure the algorithm is. The design of the AES was the result of a process which took several years and involved hundreds of skilled cryptographers (most of whom had a PhD and years of experience in academic research on symmetric encryption). That a lone developer could do as well, let alone better, in the secrecy of his own workshop, looks kind of... implausible.
The biggest part of your strategy is called "security through obscurity." You're making the gamble that, since nobody knows the precise details of your little variation on an idea, they won't be able to figure it out.
I'm not a security expert, but I can tell you that you probably won't come up with something incredibly new. Cryptography has been studied by people for millenia and your idea is highly unlikely to be original. Even if you're a relatively good programmer and code something really tricky, the question will come down to who you're up against. If you're just trying to protect your data from your kid sister, then it will probably be fine. On the other hand, if you're using it to send credit card numbers across the internet, then you're doomed to fail. It will be analysed in ways you didn't think of or don't know, and ultimately cracked.
Another way to think of it: algorithms like AES have been extensively studied by professionals in the field and its level of security is pretty well understood. Anything you come up with by yourself will not have the benefit of having been attacked by the best and brightest minds out there. You will have almost no idea of how good it actually is until people start reporting identity theft.
I heard some time that encryption and cipher are not the same thing, if so, what's the difference?
a cipher is a method (algorithm) used for encryption of some text. But english speakers have that habit of making verbs from nouns... hence ciphering became a synonym of encrypting.
Now, the fun part. If you consider decrypt and decipher, now they have different meanings.
decrypt means applying the decryption key to some code
decipher means finding the meaning of some text that was not deliberately encrypted.
In France (I'm french) we also have funny confusion with similar words. We have "chiffrer" (very similar to "cipher") that is the correct word and means encrypt, but we also use the verb "crypter" that means the same thing but is considered as an anglicism (verb built from english "crypted"). When we go for the opposite words "décrypter" and "dechiffrer" we also have different meanings but not like the english ones... "déchiffrer" means the same that both english words decrypt and decipher depending on the case, but "décrypter" is used when you try to get the clear text without the code (it means breaking the code). I believe there is no english word that means that.
Looking at my answer, I wonder if things were not clearer before it.... natural language is definitely some kind of encryption.
You might take a look at this article on the difference between Encryption and Cryptography. It also addresses the definition of cipher in the process.
Excerpts:
What is Cryptography?
In simple terms, cryptography is the science concerned with the study of secret communication.
What is Encryption?
...
... "encryption" basically is some process or algorithm (known as a cipher) to make information hidden or secret. And to make that process useful, you need some code (or key) to make information accessible.
A cipher is an algorithm of encryption. Ex. substitution cipher, permutation cipher, etc.
Encryption is just the process of obfuscating information.
So in a simplistic sense of the idea, you use a cipher to encrypt stuff. :)