Just do
actual_str += char(cipher_num);
You can also use push_back(), though the above is more common.
Just do
actual_str += char(cipher_num);
You can also use push_back(), though the above is more common.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
ok. I have a functioning encrypt/decrypt program working. For the simplicity of what it does, the encryption is strong enough (pseudo-random letter shifts, determined by odd/even, multiple of 3, and multiple of 4, recorded for the user in a text file.)
What I want to improve is the encryption key.
It's a practice in theory for me. I want to find a static method to generate a key, that's complicated enough that breaking it by hand is highly improbable (without knowing the system) but simple enough that it can be generated quickly, without anything too complex on the code side.
What I am really leaning towards is a computerized playfair system. Here's what the function would need to do.
*Build a "board", 5X5. (Multidimensional array? Hopefully not, I don't get along with arrays)
*Fill the board with the alphabet using the users key, never repeating a letter.
*Break the plain text into pairs. (should be simple enough, just pulling letters out from a string)
* Find their locations on the "board" (coordinates, as an example? IE, 1,2 and 2, 2, for say, A and B)
* Find the squares on the board that match up distance from each other, forming a square.
*replace A and B with their counterparts.
*append the encrypted text to a string, removing whitespace.
so. Would a multidimensional array (say char table[5][5]be what I need to use to do this in the most efficient manner?
I have a hard time verbalizing what the cipher does, here's the URL to the wikipedia entry:
Playfair cipher - Wikipedia, the free encyclopedia
Any advice would be extremely helpful!
playfair is fairly easy to break using frequency analysis, especially with modern computers. Because the same digram will always encode to the same pair of letters, it doesn't significantly increase the brute force necessary. If you have a sample of plaintext and its equivalent ciphertext key extraction is trivial. If you have enough ciphertext frequency analysis is straight froward. Cribs can also be used, as with any substitution cipher. For example, in any lengthy english text the letters th will appear very often.
Now if you want a real challenge, try this cipher I recently sent to a friend at NSA-
9a af 4e 54 67 03 b7 ab 23 4a 01 eb ff 5c e0 7b 4f e6 39 2f fa 5e 97 43 ee 05 eb 3e a6 28 7e 7f c6 cf f3 e5 a1 b4 62 09 fd e2 56 1a 82 e7 59 c4 84 49 32 23 67 bf 87 7f 18 b8 32 41 c3 4b 82 c3 af c1 fc 53 ad ce 97 ad 15 15 5a 0f f7 2d b9 97 8a 6e d2 7f 01 42 f7 6f 7a a2 ab 89 9a e1 57 6d 9b f2 46 67 d5 f8 2a 2f 8d db aa 48 22 5d 22 23 5f 06 c7 97 fc b5 52 38 26 14 8c 15 7a 87 fe 5b 33 32 88 80 0f dd 9c b0 14 b3 19 3b 43 b9 53 8b 33 8b 13 83 fc 14 b3 dc 67 40 26 d5 0b cf 2a ed da c1 44 a6 88 07 f2 06 43 50 0a ce 6d b7 0b cb 78 90 4f 76 54 bd f7 9e 27 3e e5 a5 81 43 1c 8b b1 b7 34 b7 36 1e 2a c0 f4 8f cb dd b5 f8 c2 e3 0d ed 80 0e 97 d6 b0 09 d2 7a bc 44 07 d6 c8 df 56 70 b3 e8 77 52 d5 05 bd 26 50 c5 d3 79 38 7d 12 45 f9 d8 08 3e 54 78 e7 5d ce c4 3f 59 4f a9 4c bf 22 83 6d 31 19 07 0e e7 28 72 ef 29 45 20 0e f6 48 de 9c 8b 4b 25 04 27 16 3b 9b 30 a8 ff 58 0e 05 4c ab 13 a9 e8 62 e4 17 ec e8 d7 d2 f2 e8 0b fe 9c 65 28 22 77 a2 32 95 a4 ed de 34 0d c3 3d 03 71 26 37 82 30 e2 1b 08 84 3e 5b c0 91 c2 c3 65 32 f7 9e 10 7a 5a 75 21 2f 68 c3 86 d5 72 24 a5 24 44 1e 1c 7e 9a d9 ac f8 48 0b f7 6e 48 6e 0d 4e 82 c5 72 f4 37 f1 9f 47 0f db c6 2f 38 3f 94 56 25 4d e0 f1 76 9f ee 9b 92 9e dc f4 a0 86 63 06 f7 e2 f7 09 4b 2f 18 bd fe 7a 55 0e 97 3d 1f 8e df ef 2d b3 e7 6f f4 ad 64 ec e3 4f 10 8c bf f0 71 9a b1 11 a2 ff 87 f3 f5 c1 e3 ff a6 2a e1 b3 c0 ea d1 91 6a c3 35 16 28 e0 f4 cd b4 47 cb 20 0a 69 93 6d 13 b0 44 82 a5 cd 43 ee d2 1e 97 4e d1 ec 5e 34 c7 d5 80 84 43 11 c7 32 d9 c6 da e7 9c 36 e3 75 fb 22 74 af 7e 57 6f 73
It is text, taken from a classic novel.
It is English
The cipher is not a one time pad
I sincerely hope you aren't serious.Originally Posted by abachler
playfair is fairly easy to break using frequency analysis, especially with modern computers. Because the same digram will always encode to the same pair of letters, it doesn't significantly increase the brute force necessary. If you have a sample of plaintext and its equivalent ciphertext key extraction is trivial. If you have enough ciphertext frequency analysis is straight froward. Cribs can also be used, as with any substitution cipher. For example, in any lengthy english text the letters th will appear very often.
Now if you want a real challenge, try this cipher I recently sent to a friend at NSA
9a af 4e 54 67 03 b7 ab 23 4a 01 eb ff 5c e0 7b 4f e6 39 2f fa 5e 97 43 ee 05 eb 3e a6 28 7e 7f c6 cf f3 e5 a1 b4 62 09 fd e2 56 1a 82 e7 59 c4 84 49 32 23 67 bf 87 7f 18 b8 32 41 c3 4b 82 c3 af c1 fc 53 ad ce 97 ad 15 15 5a 0f f7 2d b9 97 8a 6e d2 7f 01 42 f7 6f 7a a2 ab 89 9a e1 57 6d 9b f2 46 67 d5 f8 2a 2f 8d db aa 48 22 5d 22 23 5f 06 c7 97 fc b5 52 38 26 14 8c 15 7a 87 fe 5b 33 32 88 80 0f dd 9c b0 14 b3 19 3b 43 b9 53 8b 33 8b 13 83 fc 14 b3 dc 67 40 26 d5 0b cf 2a ed da c1 44 a6 88 07 f2 06 43 50 0a ce 6d b7 0b cb 78 90 4f 76 54 bd f7 9e 27 3e e5 a5 81 43 1c 8b b1 b7 34 b7 36 1e 2a c0 f4 8f cb dd b5 f8 c2 e3 0d ed 80 0e 97 d6 b0 09 d2 7a bc 44 07 d6 c8 df 56 70 b3 e8 77 52 d5 05 bd 26 50 c5 d3 79 38 7d 12 45 f9 d8 08 3e 54 78 e7 5d ce c4 3f 59 4f a9 4c bf 22 83 6d 31 19 07 0e e7 28 72 ef 29 45 20 0e f6 48 de 9c 8b 4b 25 04 27 16 3b 9b 30 a8 ff 58 0e 05 4c ab 13 a9 e8 62 e4 17 ec e8 d7 d2 f2 e8 0b fe 9c 65 28 22 77 a2 32 95 a4 ed de 34 0d c3 3d 03 71 26 37 82 30 e2 1b 08 84 3e 5b c0 91 c2 c3 65 32 f7 9e 10 7a 5a 75 21 2f 68 c3 86 d5 72 24 a5 24 44 1e 1c 7e 9a d9 ac f8 48 0b f7 6e 48 6e 0d 4e 82 c5 72 f4 37 f1 9f 47 0f db c6 2f 38 3f 94 56 25 4d e0 f1 76 9f ee 9b 92 9e dc f4 a0 86 63 06 f7 e2 f7 09 4b 2f 18 bd fe 7a 55 0e 97 3d 1f 8e df ef 2d b3 e7 6f f4 ad 64 ec e3 4f 10 8c bf f0 71 9a b1 11 a2 ff 87 f3 f5 c1 e3 ff a6 2a e1 b3 c0 ea d1 91 6a c3 35 16 28 e0 f4 cd b4 47 cb 20 0a 69 93 6d 13 b0 44 82 a5 cd 43 ee d2 1e 97 4e d1 ec 5e 34 c7 d5 80 84 43 11 c7 32 d9 c6 da e7 9c 36 e3 75 fb 22 74 af 7e 57 6f 73
It is text, taken from a classic novel.
It is English
The cipher is not a one time pad
You do realize that the strength of an encryption algorithm should not depend on how well you can hide the algorithm itself, right? I could easily give you a bunch of random letters and tell you to crack it, but the challenge wouldn't be to break the algorithm, but rather to discover it.
Your friend at the NSA should tell you this.
"What's up, Doc?"
"'Up' is a relative concept. It has no intrinsic value."
The object of this program (for me) isn't to utilize any form of strong encryption, it's to take an area of interest of mine, and apply it to another in a way that challenges my skills, and develop new ones.
I chose playfair because it's a more advanced set of coding skills, not a more advanced code (than I used in another program). It's also a system that is simple to learn by hand, and knowing the system SHOULD make it easier to code, as I don't have to learn a new form of encryption first, then write the code for something that I might or might not be using properly.
My first question still goes back to the table... would I use a character array, 5X5, to enter the alphabet into? Or is there a simpler way to accomplish the same thing?
No reason not to. It doesn't get any simpler than a 5x5 array -- after all that's just a block of 25 bytes for you to use.
Actually you are wrong about that, as one of the jobs of a cryptananlist is doing exactly such discovery, since the enemy will not always provide you with the algorithm they use.
And knowing the algorithm would not aid you in any way. I don't reveal it because it is a trade secret and posting it on a forum where foreign nationals are KNOWN to frequent would be a felony.
Last edited by abachler; 09-01-2009 at 12:49 PM.
unless I'm wrong, that is what he meant... merely cracking the code IS important, but discovering the algorithm that generates it is far more important, since later messages in the same algorithm might as well be plaintext.
Not really. even knowing the algorithm behind AES doesn't make messages encrypted with AES plaintext.
Why is that any less fun?
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I did mis-state myself earlier... I did imply that the key is part of the algorithm, which in a wierd sense, it is, but it wasnt really what I meant. I meant more (and was looking the wrong way at it, and my approach wouldnt have worked well) like, in attempting to break the cipher, one could attack the algorithm itself, using it to produce a key, testing against the encrypted text, repeat as necessary. A faulty approach, now that I think more about it.
Could it, in theory, be possible to use a key as a weapon against the same algorithm? This is more what I had in mind. With both the plaintext and encrypted text in hand, together with a key (which you successfully broke, so you know that it is genuine), would it be possible to perhaps, use the data to generate other keys, regardless of strength? Especially if you could then encrypt the plaintext you had before, compare for similarities and patterns, and start compiling methods to come to the same result? I wouldn't expect it to be done in a person's lifetime against a REAL encryption system, but it would eventually yield results, right? (long after the entire system was trashed for the new version, but still).
I guess it would be like trying to reproduce a door key for every house in the world, and then some, based off the information gleaned from ONE house key... but is it possible?
