|LSL Portal||Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials|
The SHA-1 hashing algorithm is considered broken but the attacks are largely still theoretical and not very practical. Comparison of SHA functions
LSL strings are stored in the UTF-8 format.
There's no way to input a zero-byte value into this function, nor any byte value from 128-255, therefore it's currently broken for many purposes (like HMAC-SHA1). The reason is because LSL strings cannot have a unicode null character (U+0000) in them, and LSL has no escape code for the null character (many programming languages use \0 but LSL does not have this feature). llEscapeURL("%00") yields an empty string. As well, inside this function, each character with a Unicode integer value over U+0127 / 007F are dealt with in UTF-8 fashion: in the hex values, 0xC2 is appended to the byte value (hence 0x0080-0x00FF become 0xC280-0xC2FF inside the llSHA1String() routine). A JIRA has been filed for this.
llSay(0, llSHA1String("Hello, Avatar!")); // returns 2E73318E547AF1B28CC0C96F95DDC9B1EE906B8D
$ echo -n 'Hello, Avatar!' | openssl sha1 2E73318E547AF1B28CC0C96F95DDC9B1EE906B8D
Prior to this, the only way to get the SHA-1 hash was to use the LSL SHA-1 port: SHA-1
function string llSHA1String( string src );