Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
can somebody explain this algorithm is secure or not? is there attack to break that? this algorithm uses common XOR cryptography but has some differences:
M(1) = key XOR Message(1)
M(2) = h(key) XOR Message(2)
M(3) = h(h(key)) XOR Message(3)
and so on
Notes:
M(i) is ciphered text
Message(i) is message that we are going to cipher it
key and Message(i) have the same lengths**
attacker just has the ciphered text and knows key making scheme(continues hashing) and XOR cryptography
hash algorithm is SHA-512
If the attacker ever gets to know a plaintext-ciphertext pair, he can calculate the corresponding key. And from that he can calculate all later keys. i.e. it's trivially vulnerable to a known plain text attack.
Note that when I say that the attacker guesses the message, I don't mean that he's sure that his guess is correct. He might make a few trillion guesses, and if one of them is correct, your whole scheme is broken.
And of course you must not ever reuse a key.
A more secure (but twice as slow) algorithm would be:
Key(i+1) = h("A"+key)
M(i) = h("B"+key) XOR Message(i)
Or a construction similar to CTR mode:
M(i) = h(i+key) XOR Message(i)
But I still wouldn't use either.
But there is no reason to use such a homebrew algorithm. There are plenty of existing algorithms that work well. For example if you like a stream cipher design, you could use AES in CTR mode.
Studying encryption algorithms is great fun. Just remember you are playing, not producing anything serious. As long as you are only keeping things like your personal diary (or maybe even passwords) encrypted and you keep the data secure, you will probably be fine. This kind of counts as security through obscurity. I would not recommend encrypting mass quantities of data that you REALLY need to keep private or anything that is available and of interest to the outside world, however.
In this case, if your message is shorter than the key size and hash block size and the key is single use and random, you are effectively using a one-use pad so everything in swell. Provided your random number key generation is perfect, you have an unbreakable encryption mechanism. As you add each block to the message, you are effectively calculating new keys using SHA-512, not adding any particular value. If an attacker can assume the message consists of printable text and if the length of the message is long or the key is used repeatedly, it should would not be too difficult to find the original key.
It would be more effective to calculate:
M(1)=h(N + key) XOR Message(1)
M(2)=h(M(1)) XOR Message(2)
M(3)=h(M(2)) XOR Message(3)
(where N is the number of times the key has been used which is passed in clear text.)
That way the bad guys can’t calculate your key sequence ahead of time and decrypt your message before you can. Also by using a salted hash of the key, the attacker won’t be able to predict the key sequence that will be used next time.
I read somewhere:
The first rule of cryptography is “Cryptography should be left to experts.”
The second rule is “You are not an expert.”
There is a reason people get PhDs in things like Computer Science and Mathematics. There is a lot to learn and discover. Something like this looks fine to me but no doubt it has a gaping hole that an attacker could drive a truck through.
Have fun and don't let grouchy people like me get you down.
/Bob Bryan
Related
So I've been studying this concept of length extension attacks and there are few things that I noticed during my study about it which are not very bright to me.
1.Research papers are explaining how you can append some type of data to the end and make newly formed data. For example
Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege
(notice 2 waffles). My question is if a parser function on the server side can track duplicate attributes, could then the entire length extension attack be nonsense? Because the server would notice duplicate attributes. Is a proper parser that is made to check any duplicates a good solution versus length extension attacks? I'm aware of HMAC approach and other protections, but specifically talking just about parsers here now.
2.Research says that only vulnerable data is H(key|message). They claim that H(message|key) won't work for the attacker because we would have to append a new key (which we obviously don't know). My question is why would we have to append a new key? We don't do it when we are attacking H(key|message). Why can't we rely on the fact that we will pass the verification test (we would create the correct hash) and that if the parser tries to extract the key from it, that it would take the only key in the block we send out and resume from there? Why would we have to send 2 keys? Why doesn't attack against H(message|key) work?
My question is if a parser function on server side can track duplicate attributes, could then the entire length extension attack be a nonsense?
You are talking about a well-written parser. Writing software is hard and writing correct software is very hard.
In that example, you have seen an overwritten attribute. Are you able to say that a good parser must take the last one or the first one? What is the rule? There can be stations that the last one must be taken! That is an attack that can be applied or not. This depends on the station. If you consider that the knowledge of the length extension attack goes back to 1990s, then finding a place applicable to this should amaze someone!. And, it is applied in the wild to Flickr API in 2009, after almost 20 years;
Flickr's API Signature Forgery by Thai Duong and Juliano Rizzo Published on Sep. 28, 2009.
My question is why would we have to append new key? We don't do it when we are attacking H(key|message). Why can't we relay on the fact that we will pass verification test (we would create correct hash) and that if parser tries to extract key from it, that it would take the only key in the block we send out and resume from there. Why would we have to send 2 keys? Why doesnt attack against H(message|key) work?
The attack is a signature forgery. The key is not known to the attacker, but they can still forge new signatures. The new message and signature - extended hash - is sent to the server, then the server takes the key and appends it to the message to execute a canonical verification, that is; if it does the signature is valid.
The parser doesn't extract the key, it already knows the key. The point is that can you make sure that the data is really extended or not. The padding rule is simple, add 1 and fill many zeroes so that the last 64 (128) is the length encoding (very simplified, for example, the final length must be multiple of 512 for SHA256). To see that there is another padding inside you must check every block and then you may claim that there is an extension attack. Yes, you can do this, however, the one of aims of cryptography is to reduce the dependencies, too. If we can create a better signature that eliminates the checking then we suggest to left the others. This enables the software developers to write more secure implementation easily.
Why doesn't attack against H(message|key) work?
Simple, you get the extended message message|extended and send the extended hash
H(message|key|extended) to the server. Then the server takes the message message|extended and appends the key message|extended|key and hashes it H(message|extended|key) and clearly this is not equal to the extended one H(message|key|extended)
Note that the trimmed version of the SHA2 series like SHA-512/256 has resistance to length extension attacks. SHA3 is immune to it by design and that enables a simple KMAC signature scheme. Blake2 is also immune since it is designed with the HAIFA construction.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Lets suppose that we have the next string:
13:45:11:17:-65:107
This string is a product of RSA crypting. Each number is a byte of a crypted info.
We crypted it by a public key. After that we decide to "hide" it, the next way:
1=q,3=f,4=d,5=o,7=y,6=p,0=b,-=u,:=t;
and we have the next string, after all:
qftdotqqtqytupotqby
Supposing that server side will unhide this string by the reverse way. And decrypt by private key.
So i'm asking: if somebody steal this string, but he hasn't any access to our software. He has just a string - qftdotqqtqytupotqby
Is there possibility for him to understand that
qftdotqqtqytupotqby = 13:45:11:17:-65:107
If you make the assumption that the attacker cannot access your software and therefore all he has is some ECB (subsitution ciphered) encoded RSA crypttexts, than the answer is no he can't reverse it. (This assumes the RSA crypttexts are effectively byte-wise "pseudo random" without the secret key. If they have some plaintext predictable header information than the ECB could be attacked.)
This is however a very weak attacker position to be considering. In general you should assume an attacker has a copy of your software, otherwise every copy of your software is in effect a secret master key for the whole system.
I would favor using AES with a compiled in secret key to your homebrew ECB. At least that restricts the secret to the key and not potentially the whole software package. You could also use this technique to compartmentalize the security risk to just software packages with the same compiled in key.
From a strict security perspective, the letter coding is worthless and does not add any protection (see the Kerkhoff principle), since you cannot assume that the attacker does not know your implementation. The security must rest entirely in the key.
Assuming the RSA output really looks exactly as presented in the question (which implies that a ridiculously small RSA keysize was used), then it is easy to at least partly break the simple substitution because the ASCII representation of the RSA ciphertext is highly structured. The most frequent symbol will be the colon (:), while the symbol only appearing right next to a colon will be the minus (-). If there are four symbols between colons, the leftmost is the minus. If there are three symbols between colons, the leftmost is the minus, the one (1) or the two (2). There are 8 digits left which are not as easy, but combined with the small keysize of RSA which is used are no real obstacle.
The following is not directly part of the question, but have to be said as well: Whether the RSA part of your protocol is secure depends on so many factors that it is impossible to write a complete answer. Here just two examples of how the above scheme could be flawed:
The small block size of one byte implies a keysize of 8 bits, which is ridiculously easy to break even with only pen and paper.
If that's plain textbook RSA encryption without secure padding (such as PKCS#1 2.x OAEP), the scheme is fatally flawed. The attacker can simply use the public key to compute a dictionary with the encrypted versions of all 256 byte values and use the dictionary to decrypt all your encrypted bytes.
That being said, doing bytewise RSA is horribly inefficient, you are much better off putting all your bytes in a single RSA block, or if you have too much data for a single block, use a hybrid scheme with a symmetrical algorithm for bulk encryption and only RSA encrypt the random session key, as suggested by user1131467.
I took up cryptography recently, and 1 of my task was to create a kama sutra cipher. Up till the point of generating the keys, I will have no problems. However, due to the nature of kama sutra, I believe that the keys are not supposed to be hard coded into the program, but rather generated for each plain text it takes in.
What I understand is that the cipher text's length should be the same as the length of plain text. However, the thing is that where do I place the key, such that as long as the cipher text is generated by my program, the program would be able to decipher it even if the program was closed. Given that this is an algorithm, I am sure that I should not be looking at storing the key in another flat file/ database.
There are not many related information online regarding this cipher. What I saw are those that allow you to randomise a key set, generate a cipher text based on the given key set. When decrypting, you will also need to provide the same key set. Is this the correct way of implementation?
For those who have knowledge about this, please guide me along.
If you want to be able to decrypt the cyphertext, then you need to be able to recover the key whenever you need. For a classical cypher, this was usually done by using the same key for multiple messages, see the Caesar Cypher for an example. Caesar used a constant key, a -3/+3 shift while Augustus used a +1/-1 shift.
You may want to consult your instructor as to whether a fixed key or a varying key is required.
It will be simpler to develop a fixed key version, and then to add varying key functionality on top. That way you can get the rest of the program working correctly.
You may also want to look at classical techniques for using a keyphrase to mix an alphabet.
When I hear about methods for breaking encryption algorithms, I notice there is often focused on how to decrypt very rapidly and how to reduce the search space. However, I always wonder how you can recognize a successful decryption, and why this doesn't form a bottleneck. Or is it often assumed that a encrypted/decrypted pair is known?
From Cryptonomicon:
There is a compromise between the two
extremes of, on the one hand, not
knowing any of the plaintext at all,
and, on the other, knowing all of it.
In the Cryptonomicon that falls under
the heading of cribs. A crib is an
educated guess as to what words or
phrases might be present in the
message. For example if you were
decrypting German messages from World
War II, you might guess that the
plaintext included the phrase "HElL
HITLER" or "SIEG HElL." You might pick
out a sequence of ten characters at
random and say, "Let's assume that
this represented HEIL HITLER. If that
is the case, then what would it imply
about the remainder of the message?"
...
Sitting down in his office with the
fresh Arethusa intercepts, he went to
work, using FUNERAL as a crib: if this
group of seven letters decrypts to
FUNERAL, then what does the rest of
the message look like? Gibberish?
Okay, how about this group of seven
letters?
Generally, you have some idea of the format of the file you expect to result from the decryption, and most formats provide an easy way to identify them. For example, nearly all binary formats such as images, documents, zipfiles, etc, have easily identifiable headers, while text files will contain only ASCII, or only valid UTF-8 sequences.
In assymetric cryptography you usually have access to the public key. Therefore, any decryption of an encrypted ciphertext can be re-encrypted using the public key and compared to the original ciphertext, thus revealing if the decryption was succesful.
The same is true for symmetric encryption. If you think you have decrypted a cipher, you must also think that you have found the key. Therefore, you can use that key to encrypt your, presumably correct, decrypted text and see if the encrypted result is identical to the original ciphertext.
For symmetric encryption where the key length is shorter than the cipher-text length, you're guaranteed to not be able to produce every possible plain-text. You can probably guess what form your plain--text will take, to some degree -- you probably know whether it's an image, or XML, or if you don't even know that much then you can assume you'll be able to run file on it and not get 'data'. You have to hope that there are only a few keys which would give you even a vaguely sensible decryption and only one which matches the form you are looking for.
If you have a sample plain-text (or partial plain-text) then this gets a lot easier.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was reading a few articles on salts and password hashes and a few people were mentioning rainbow attacks. What exactly is a rainbow attack and what are the best methods to prevent it?
The wikipedia article is a bit difficult to understand. In a nutshell, you can think of a Rainbow Table as a large dictionary with pre-calculated hashes and the passwords from which they were calculated.
The difference between Rainbow Tables and other dictionaries is simply in the method how the entries are stored. The Rainbow table is optimized for hashes and passwords, and thus achieves great space optimization while still maintaining good look-up speed. But in essence, it's just a dictionary.
When an attacker steals a long list of password hashes from you, he can quickly check if any of them are in the Rainbow Table. For those that are, the Rainbow Table will also contain what string they were hashed from.
Of course, there are just too many hashes to store them all in a Rainbow Table. So if a hash is not in the particular table, the hacker is out of luck. But if your users use simple english words and you have hashed them just once, there is a large possibility that a good Rainbow Table will contain the password.
It's when somebody uses a Rainbow table to crack passwords.
If you are worried about this, you should use Salt. There is also a Stack Overlow question that might help you understand salt a little better than Wikipedia...
This is a useful article on Rainbow Tables for the lay person. (Not suggesting you are a layperson, but it's well written and concise.)
Broadly speaking, you encrypt a vast number of possible short plaintext strings (i.e. for passwords), and store the encrypted values alongside the plaintext. This makes it (relatively) straightforward to simply lookup the plaintext when you have the encrypted value.
This is most useful for weak and/or unsalted password hashes. A popular example is the LAN Manager hash, used by versions of Windows up to XP to store user passwords.
Note that a pre-computed rainbow table for even something as simple as the LM hash takes a lot of CPU time to generate and occupies a fair amount of space (on the order of 10s of gigabytes IIRC).
Rainbow Tables basically allow someone to store a large number of precomputed hashes feasibly.
This makes it easy to crack your hashed passwords, since instead of performing a whole heap of hashing functions, the work has already been done and they virtually just have to do a database lookup.
The best protection against this kind of attack is to use a salt (random characters) in your password. i.e. instead of storing md5(password), store md5(password + salt), or even better md5(salt + md5(password)).
Since even with rainbow tables, it is going to be near impossible to store all possible salted hashes.
BTW, obviously you have to store your salt with your hash so that you can authenticate the user.
Late to the party but I was also aware of Rainbow Tables being a method of attack on hashed/unsalted passwords. However on Twitter recently http://codahale.com/how-to-safely-store-a-password/ was shared and depending on your needs and concerns.. you may not be able to salt your way to safe password storage.
I hope this is informative to you.
Wikipedia is your friend:
http://en.wikipedia.org/wiki/Rainbow_table