4
$\begingroup$

Recently I've been delving into security algorithms, I already knew some of the (easy) math behind AES and RSA and how to and not to implement it. But well, i got a bit bored so i thought I'd just do something fun and i wrote a small bit of code for the OTP (not so difficult)

then i thought, and this concerns my question: If you give someone a OTP key and you tell him that the (say SHA 256) hash of the previous plaintext will be the new key, how secure is this? Obviously you start with a perfectly random key an will never make your plain text longer than your key. (so a proper one time pad function)

So you have a key, you decrypt the cyphertext you get, then you hash the retrieved plaintext and this has will be the key for your next message. In my mind this would be as secure as the OTP when starting with a proper key. But then again my mind isn't really suited for simulating real applications, haha.

So does anyone have an idea on how secure this would be?

EDIT i might want to clarify your next plain text will of course be as long as the generated hash, if you need to write a longer message you will use the hash of your newly typed plain text, and so on.

Improve this question
$\endgroup$
2
  • $\begingroup$ Suppose your hash is 16 bytes long (like MD5), and you need to encrypt known plaintext of 16 bytes as part of a protocol say or some file format, your system is dead after dead. Even e.g. 12 bytes is deadly as you brute force all 4 unknown plain text bytes. $\endgroup$
    – Henno Brandsma
    Feb 23, 2015 at 19:29
  • $\begingroup$ Ahh but there you go this problem has a very easy solution, your very first text will be complete random just as your key will be complete random. It cannot be guessed by brute force. so then you go on to use the hash of every plain text as your OTP message. Also you don't take MD5 for obvious reasons you'd take SHA 512. So I agree you really need to think about how to implement it but when done correctly the problems you describe are non existent. And as i mentioned to Maarten you will never ever use some guessable things like HTML tags. Lets just assume it's only used for text no formats. $\endgroup$
    – Vincent
    Feb 24, 2015 at 7:10

2 Answers 2

Reset to default
8
$\begingroup$

Not as secure as a one time pad. A key concept with one time pads is that no part of them is ever reused. It is a common pitfall of people attempting to implement cryptography to assume that an obscure relationship is necessarily a secure one: it is not. You are create a chain of SHA hashes that can be observed, and potentially decoded.

Therefore what you have described is not an effective one time pad. The one time pad depends on the idea of a pre-compiled book of codes that have no relationship to one another, and that are used exactly once. If any sort of iteration is observed between the ciphertexts, this ruins the pad.

From the outside this seems like a hard code to cryptoanalyze, but I don't think it is massively difficult. Differences between your ciphertext will be analyzed, and when is found that you are not using a standard encryption scheme, the various pitfalls of self implemented crypto will be explored.

The security of your entire system can be no better than the original secret in that case, and the additional secrets generated from original secret actually worsen the security of the system, because they give some clue as to the original secret, however obscure that clue might be. To be as secure as a one time pide, the keys should bear absolutely no observable relationship to one another.

If I were to cryptoanalyze your system, I would first figure out the nature of the cipher text, and the nature of the keys. If I had access to a single key (say by brute forcing, or a flaw in the encryption) then I would be able to detect fairly quickly via automated methods that the key was a SHA hash.

At that point, I would try to guess the plaintext of the hash. If I had access to multiple keys I would notice that key size might correlate to message size in some way. From there it would be obvious that key was related to the message somehow. I will admit that brute forcing an entire message against a SHA hash is unreasonable, but all it takes is one leaked message to start pulling things apart.

If I ever decoded the plaintext from any one of the hashes it would be game over. System cracked. This was a quick analysis, others might be able to go deeper into the math side of this.

Improve this answer
$\endgroup$
5
  • $\begingroup$ This is kind of what i was after, (to recap) if only one message is brute forced or leaked or in any other way obtained the whole idea of this is broken. And obviously this whole scheme can only be as strong as the strength you begin with. I wasn't planning on using this on anything official but i thought it might be a fun thing to make for private use. Am I correct when I say as long as no one finds out the starting key or one of the plain text messages this is 'secure'? (people can know what hash I use) $\endgroup$
    – Vincent
    Feb 23, 2015 at 13:58
  • $\begingroup$ I would say "it is less secure than a one time pad", for fun it's fine, I wouldn't exactly use it for transferring cash or secrets. If you are interested in crypto implementation, I suggest you and a friend try and cryptoanalyze each other's communication with this. The techniques I described aren't trivial, and this would be much harder to crack without any plain text, but I don't think it's impossible. Can't say for sure without thinking about it a little more. $\endgroup$
    – baordog
    Feb 23, 2015 at 14:00
  • 1
    $\begingroup$ It doesn't matter if it's impossible (would of course be great) but now I am wondering how difficult it would be to crack, would it be feasible/easy?. Ahh well, thanks for your help, I'd up vote your post if I hadn't just made an account (need 15 points to up-vote :P ) but your help and insight is really appreciated :) $\endgroup$
    – Vincent
    Feb 23, 2015 at 14:19
  • 1
    $\begingroup$ No problem. If no one else comes along with an answer, make sure to accept :D $\endgroup$
    – baordog
    Feb 23, 2015 at 14:42
  • $\begingroup$ Also he doesn't need to break the whole plaintext just a bit will be enough so he can brute force his way through, since the hashes of the text will be bruteforcable. i don't have it 100% clear how it will work but i know it is a flaw using the hash because those are computable. Jup it would have been fun but the more messages you send with this the weaker it gets. Just wish i was a math genius and could figure out how much weaker it gets every message :P $\endgroup$
    – Vincent
    Feb 24, 2015 at 7:37
2
$\begingroup$

I've got the inkling of a feeling that using the plaintext to derive the next key is not CPA secure. One of the attacks to test a cipher is to have the attacker choose the plaintext. Your scheme will obviously fail this test.

OTP is a theoretical construction. As it is hard to derive a truly random key stream (of the same length of the plaintext) we usually make due with a stream cipher. Your stream cipher however fails basic requirements for a cipher.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Or look at it this way: if you ever lose your plaintext you will lose the key for any message you will ever send afterwards! Many plaintext isn't just a typed message. Instead it contains structures around it; structures that can be guessed such as <html><head><title>Oops</title></head><body>This is not going to go right, isn't it?</body></html> $\endgroup$
    – Maarten Bodewes ♦
    Feb 24, 2015 at 0:42
  • 1
    $\begingroup$ But OTP will always be broken if the attack can chose the plain text right? because if you have the plain text in an OTP scheme and you get it's corresponding cipher text you will always know the OTP key. Also obviously no one would use HTML tags or anything which is always the same, firt and foremost it takes up to much space, for OTP you only encrypt the meaningful characters. 2nd of which using this is like the flaw in the enigma machine where they always send Heil Hitler in every message. It's bad practice. $\endgroup$
    – Vincent
    Feb 24, 2015 at 7:05
  • 2
    $\begingroup$ @VincentAdvocaat this is the same as my point from the comment on the original question. Why bother with a system that one cannot encrypt arbitrary data with? OTP is not broken if plain text is known because key stream is not reused and independently random. So knowing part of it comprises nothing. Here knowing only 32 bytes kills everything. $\endgroup$
    – Henno Brandsma
    Feb 24, 2015 at 7:22
  • 1
    $\begingroup$ Just to clarify, the start of my scheme is OTP. Then i want a new key for my next message which is a hash. Now all i am concerned about is when the attacker knows nothing about the plaintext will he ever be able to break it? obviously if he knows bits of the plaintext he will.. o wait i see, normal OTP doesn't matter if he knows a bit because the rest of the key is random, but here he'll figure out a few bits of the plaintext and he can bruteforce it because of the hash which can verify if he has the correct plaintext. yeh I'm starting to see the flaw here. $\endgroup$
    – Vincent
    Feb 24, 2015 at 7:34
  • 1
    $\begingroup$ Yes, I can see you get the point now. $\endgroup$
    – Maarten Bodewes ♦
    Feb 24, 2015 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.