Encryption and Word Documents (0 bytes)
closed account (Lv0f92yv)
I am practicing writing a simple (not practical) encryption algorithm. I do not know how to write a 'good' algorithm, but I have one that seems to work on simple text files. Anybody that knows what they're looking for could probably recover the plaintext in minutes... I understand that this is not really 'secure' by any means.
The encryption algorithm:
The decryption algorithm is the same, except the + is a minus (silly I know).
Note that finalKey[] is just a character array of the user has entered ('key' for example), and is not 'hashed' or 'salted'. (Though I'd be interested in learning how this works)
I have a problem when using this on .docx (microsoft word files), since some of the bytes are zeroes. The result is that the ciphertext displays the key in place of the 0 bytes... (0 + anything = anything), and in this case, the anything is my key.
I have tried to cirumvent this problem by not changing the byte if the original byte is 0, but this causes the file to be encrtypted/decrypted incorrectly.
What am I doing wrong? (Other than a terribly insecure/impractical algorithm).
Although if anyone knows about encryption/has any comments on how I could improve this algorithm, I certainly look forward to advice. I am trying to learn about encryption - any advice that could make this more secure is welcome.
Thanks for reading such a long post...
The encryption algorithm:
|
|
The decryption algorithm is the same, except the + is a minus (silly I know).
Note that finalKey[] is just a character array of the user has entered ('key' for example), and is not 'hashed' or 'salted'. (Though I'd be interested in learning how this works)
I have a problem when using this on .docx (microsoft word files), since some of the bytes are zeroes. The result is that the ciphertext displays the key in place of the 0 bytes... (0 + anything = anything), and in this case, the anything is my key.
I have tried to cirumvent this problem by not changing the byte if the original byte is 0, but this causes the file to be encrtypted/decrypted incorrectly.
What am I doing wrong? (Other than a terribly insecure/impractical algorithm).
Although if anyone knows about encryption/has any comments on how I could improve this algorithm, I certainly look forward to advice. I am trying to learn about encryption - any advice that could make this more secure is welcome.
Thanks for reading such a long post...
closed account (Lv0f92yv)
Maybe I should rephrase. Simply put, I'm trying to figure out why reading '0' bytes from a word document (.docx) and putting those same '0' bytes back into the output file (in the same position they were in originally) is causing a malformatted file. Perhaps the get() and put() functions the way I'm using them does not guarantee that the bytes are being put back in the right order?
If the reason this post has no replies is because it's in the wrong forum, I apologize... I've read the 'read before you post'.
If the reason this post has no replies is because it's in the wrong forum, I apologize... I've read the 'read before you post'.
*thinking*
I still don't get it. You will encrypt a .docx file?
If yes:
You have to be careful, because you destroy bytes.
A signed character (char) is just -127 -> +128 small. When you are over the +128, you destroyed the byte.
bye and have fun (:
I still don't get it. You will encrypt a .docx file?
If yes:
You have to be careful, because you destroy bytes.
A signed character (char) is just -127 -> +128 small. When you are over the +128, you destroyed the byte.
bye and have fun (:
When you say
, do you mean a file of length zero, a character that's the value 0, or the character for the numeral zero?
| '0' bytes |
As MorningStar pointed out, your method of encryption/decryption is completely open to corrupting the data (though it may work fine for strictly alphabetic characters depending on your key).
A slight modification to what you are attempting to do would be to encrypt your data using the XOR boolean operator. Look here for info on the XOR operator: http://cplusplus.com/doc/boolean/
Say you have two byte values, x and k.
y = x^k
y^k will then equal x.
This encryption/decryption will work for all possible byte values.
A slight modification to what you are attempting to do would be to encrypt your data using the XOR boolean operator. Look here for info on the XOR operator: http://cplusplus.com/doc/boolean/
Say you have two byte values, x and k.
y = x^k
y^k will then equal x.
This encryption/decryption will work for all possible byte values.
closed account (Lv0f92yv)
Thanks jRaskell, this bitwise op (^ exclusive or) seems to work. For '0' bytes, I meant the byte I was reading in with the line: int byte = iFile.get();.
A cout << byte; would output a 0 for some parts of the document. Though I foolishly did not think of byte corruption here, which may have been the problem... Though this algorithm works fine on .docx files when I do not handle the '0' byte input. The problem with that is the key is visible in the plaintext as itself when the input is a 0 (since adding 0 to my finalKey[k] = finalKey[k]).
I don't imagine this is much better, since with any constant input data, the key will loop over and over (xor'd as it is) and be easily visible to the naked eye (assuming the key is not as long as the input data).
Aside, how secure DOES a key the length of input data make this sort of bad encryption algorithm?
Suppose data length: 3,000 characters; key length: 3,000 characters. Xor each character of data with each character in the key.
Thanks again for the replies.
A cout << byte; would output a 0 for some parts of the document. Though I foolishly did not think of byte corruption here, which may have been the problem... Though this algorithm works fine on .docx files when I do not handle the '0' byte input. The problem with that is the key is visible in the plaintext as itself when the input is a 0 (since adding 0 to my finalKey[k] = finalKey[k]).
I don't imagine this is much better, since with any constant input data, the key will loop over and over (xor'd as it is) and be easily visible to the naked eye (assuming the key is not as long as the input data).
Aside, how secure DOES a key the length of input data make this sort of bad encryption algorithm?
Suppose data length: 3,000 characters; key length: 3,000 characters. Xor each character of data with each character in the key.
Thanks again for the replies.
closed account (Lv0f92yv)
Even xoring the bits, the result of the 'encrypted' file is:
- most of it appears as garbage, but you can clearly see the key 'bitwiseman' looped accross the areas that were originally read in as zeroes. I'm not sure how to avoid this, other than to 'not handle the zeroes', which causes the decryption process to fail.
2"ws}scminbiUw‹‚ï¸ÄobiXpisvmil9*> [ >>:>4]
NÀmv_ÉsgmanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemaÚ÷& ¬)c ‚äeØ£]Äà&d¤Üm$;dEº¬€ª7Έ±jBœÖ*ß1tê=•C~ ]¤è° —?˜rnðÕO©ÀéÔÔØ<䆫¡"c!Y}ˆî(t²‰˜¶ß+éq nß¡çI“ö{}Õ±WKi’Çç\‹¤Ùù(‡]}…O›Lbfè2£Y·Ÿúuª¿4F>ê{øs›wÇæ ÿqO`øîz±Ø.F0hûðÚ.f^]ºïX~¬ÎÁs?±®<ê?N3Î<9ßqDüR̶&³Ö PDòúŠùž<>_jÝ’$KjÖˆz Ü1± Þ]²å>‹ÐþŽÂLÐÆn$S˜Hš9²—9RÑ«Œ ¢{zž¿7ªÕ
‰½ÊI>«L׈ÿúå Zc½NÜÂdØÈdÓ“Ìkù" ¬©ø6}—”Ø•"èN pØšdþ†mõ€–ìßìäûFº*j›ˆ Ä.ÝÂp›
q†„ B’’àñ
q½)m‹ 0¨ 4¡b[]A¼47Bº¿[wisš’bn2"ws}scminbiUwwâÚ’nbi:uisnmil=
\K IÖsk[Åmcnbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbåæ¬#p$açg¶&¿D¾gC¼»·<Ö QŽnå÷Žhy¥×¿ÓÜÍBÓ$¬7•‘Šª!´ò÷ì½HÂQgÁ0¡×±è*¾
Ãün#<¥:ôày0§Ã ¸MUåãÈOé\ÊÌ€Úò6MMG RÞÁ5ñ¿×'ßý}'k:ûæ¥háÊÔÜ®€ jéüË»7o ˜)Æ¢5W1´g)@s
o Ž¶©àa¿n
´O H=±þD”BxD¸LîôÍdT‰ Õ¼†!’>åììX~Èz좒]õw-7|´Ã]¥ÆOhH*I{ &™*÷ÄF[lan–ww98fiundi|wisDmH‰oªCvis"han~i|v ] N1 <F]
Y C
TÕmrMÍaobitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisemanbitwisÉù*!aH`òžU›êh&åðÞ‚øA¸uò ]%¨%Ñ€ín-Ž4„ËàÝZøâuTMƒg§Š]ìÚ6 ÂUŒm˜ ÎxG‘ë×ìâØx]ÉöÛ™ •õ¨iÁèåZQÁÉCNxMYƒî/²âOL³E¥Hýêù[¿ã‹Z@JÚ¾yÅZ“¦Á —‡îÖ.,EÐ ™$Çr¡LmÆBš–†Œ†ñ–ƒA$ n&S Á)—îa©}àT1m‰9Îr|d3€+`Ix<îw¯`Ì
ÆOEuç}¯<$ægÌsw½ºB ÿF¨ˆ•bH2 ×ú²þZ†¨§Ï3†ŠÉj2û¾Á¼|(1ìX<,n;áºký+&2LV¯”XïS M< &µœ¼²õé_òîàWÔ² #‚(Ó/´ÊÓBŽÎ”citˆ–pe=*mf}tqi{emaOb<m¼ÎYma"´htfise
F<
L>…¾ãº6ð„vlmR¬o ˆéåßãÃ2WúÓ´âºö ÉE$ NQÝ Y0„Æ”åšyY€[˜D ϱÐ%ûê^0ì@
ÚRö+ªóù+€9…übB%™¦þ¼¢ |
- most of it appears as garbage, but you can clearly see the key 'bitwiseman' looped accross the areas that were originally read in as zeroes. I'm not sure how to avoid this, other than to 'not handle the zeroes', which causes the decryption process to fail.
| I'm not sure how to avoid this, other than to 'not handle the zeroes', which causes the decryption process to fail. |
One method to help obfuscate your encryption key in these simple encryption schemes is to apply an iterative permutation to it (more complex schemes use this method as well).
Example: The simplest example would be a predefined pattern of bit-shifts, though this isn't technically a permutation since you will be losing data from the original key. So long as you don't shift more than a couple bits one way or another, it can be used to effectively increase the size of your pattern from 10 bytes to 100 bytes or more. A more appropriate method (and a true permutation), would be re-arranging the bits in a predefined pattern. Take the previous bit-shift example, and loop the end bits back to the other end.
01001101 shifted 3 bits to the left would become 01101010. So you no longer lose those 3 bits of the key.
This isn't a solution to the underlying problem since it doesn't eliminate the pattern but only increases it's size, but it's a step in the right direction. As I said above, it's a process used by more advanced encryption schemes as well, though not exactly in the same way as described above. So learning how to apply permutations to your key will be helpful when learning more advanced techniques.
Example: The simplest example would be a predefined pattern of bit-shifts, though this isn't technically a permutation since you will be losing data from the original key. So long as you don't shift more than a couple bits one way or another, it can be used to effectively increase the size of your pattern from 10 bytes to 100 bytes or more. A more appropriate method (and a true permutation), would be re-arranging the bits in a predefined pattern. Take the previous bit-shift example, and loop the end bits back to the other end.
01001101 shifted 3 bits to the left would become 01101010. So you no longer lose those 3 bits of the key.
This isn't a solution to the underlying problem since it doesn't eliminate the pattern but only increases it's size, but it's a step in the right direction. As I said above, it's a process used by more advanced encryption schemes as well, though not exactly in the same way as described above. So learning how to apply permutations to your key will be helpful when learning more advanced techniques.
closed account (Lv0f92yv)
I will look into this bit shift method. Thanks. Is this how keys are transformed into 128bit/512bit/1024bit keys? By shifting/adding bits until the key is large enough?
Topic archived. No new replies allowed.