Difference between revisions of "LlXorBase64StringsCorrect"
| Line 34: | Line 34: | ||
* '''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. | ||
* '''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. | * '''Plain Text''': The user captures outputs for known inputs can expose weaknesses in the key. | ||
* '''Brute force''': Attacking the key, secret and/or seed | * '''Brute force''': Attacking the key, secret and/or seed | ||
Revision as of 13:40, 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 );| 319 | Function ID |
| 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.
Caveats
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.
- 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
Search JIRA for related Issues
Signature |
|---|
function string llXorBase64StringsCorrect( string str1, string str2 ); |