Difference between revisions of "LlXorBase64StringsCorrect"
m |
|||
| Line 32: | Line 32: | ||
===Attack Vectors=== | ===Attack Vectors=== | ||
First thing you need to know is that XOR is limited poly-alphabetic cipher. | First thing you need to know is that XOR is limited poly-alphabetic cipher. | ||
* '''Probability''': In English, letters have different probabilities of occurring because of grammar and spelling rules. XOR does not hide the letter probabilities. | * '''Probability''': In English, letters have different probabilities of occurring because of grammar and spelling rules. XOR does not hide the letter probabilities. This attack only works when the keys is many times smaller then the message. | ||
* '''UTF-8 Rules''': When you convert a string to Base64, UTF-8 encoding is used first. If you assume the inputs are valid UTF-8 encodes some bits can be determined purely upon examination. | * '''UTF-8 Rules''': When you convert a string to Base64, UTF-8 encoding is used first. If you assume the inputs are valid UTF-8 encodes some bits can be determined purely upon examination. | ||
* '''Plain Text''': The user captures outputs for known inputs can expose weaknesses in the key. | * '''Plain Text''': The user captures outputs for known inputs can expose weaknesses in the key. | ||
Revision as of 12:42, 24 May 2008
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
Summary
Function: string llXorBase64StringsCorrect( string str1, string str2 );| 0.0 | Forced Delay |
| 10.0 | Energy |
Correctly performs an exclusive or on two Base 64 strings.
Returns a string that is a Base64 XOR of str1 and str2.
| • string | str1 | – | Base64 string | |
| • string | str2 | – | Base64 string |
str2 repeats if it is shorter than str1. If the inputs are not Base64 strings the result will be erratic. Be sure to read the Notes before designing a cryptographic algorithm.
Examples
Notes
Best Practices
As a cryptographic technique, XOR is weak and there are several attacks that can be leveraged to determine the XOR inputs. Depending upon how the secrets are used cracking a single message could expose the input secrets, resulting in the derived algorithm being broken.
Keep your secrets secret. Use a seeded trap door function to shake up the bits of the secret before using with the XOR and change the seed often.
Do not XOR a value by two differing length values without knowing the implications. It may seem like a good idea but what it actually does is link the fields. While it will give you a longer key value (the Smallest Common Multiple in length), the fields will be linked such that there are really only as many fields as the Greatest Common Divisor. The number of unique fields determines the theoretical maximum number of keys an attacker has to try.
Unique_Key_Fields = Greatest_Common_Divistor(lengths_of_keys) * number_of_keys
Attack Vectors
First thing you need to know is that XOR is limited poly-alphabetic cipher.
- Probability: In English, letters have different probabilities of occurring because of grammar and spelling rules. XOR does not hide the letter probabilities. This attack only works when the keys is many times smaller then the message.
- UTF-8 Rules: When you convert a string to Base64, UTF-8 encoding is used first. If you assume the inputs are valid UTF-8 encodes some bits can be determined purely upon examination.
- Plain Text: The user captures outputs for known inputs can expose weaknesses in the key.
- Brute force: Attacking the key, secret and/or seed
See Also
Deep Notes
Signature |
|---|
function string llXorBase64StringsCorrect( string str1, string str2 ); |