Difference between revisions of "Talk:SHA-2"
Jump to navigation
Jump to search
(This script doesn't work) |
|||
| (13 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Input: | == This script doesn't work. == | ||
'''Input:'''<br> | |||
"foo" (without the quotes) | "foo" (without the quotes) | ||
SHA-256 hash according to this script: | '''SHA-256 hash according to UTF8_SHA_256("foo") in this script:'''<br> | ||
709E80C88487A2411E1EE4DFB9F22A861492D20C4765150C0C794ABD70F8147C | 709E80C88487A2411E1EE4DFB9F22A861492D20C4765150C0C794ABD70F8147C | ||
SHA-256 hash according to every other SHA- | '''SHA-256 hash according to every other SHA-256 hasher I could find on the internet:'''<br> | ||
2C26B46B68FFC68FF99B453C1D30413413422D706483BFA0F98A5E886266E7AE | 2C26B46B68FFC68FF99B453C1D30413413422D706483BFA0F98A5E886266E7AE | ||
[[User:Soto Hax|Soto Hax]] 10:09, 16 November 2013 (PST) | [[User:Soto Hax|Soto Hax]] 10:09, 16 November 2013 (PST) | ||
:I'll work on it. Ob, thanks for the revert. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:16, 16 November 2013 (PST) | |||
:Ok, so the script passes it's self tests in LSLEditor, which is a good indication we are dealing with an order of operations bug or something that LSLEditor does differently than LSL. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 22:03, 18 November 2013 (PST) | |||
:If I had to guess without doing any real work it's probably a Base64 implementation issue with LSLEditor. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 22:19, 18 November 2013 (PST) | |||
:The major change is how the length at the beginning is calculated (god I wish I had written more comments), I'm going to roll that bit of code back seeing as the other changes aren't effected by order of operations and are related to speeding the code up. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 22:33, 18 November 2013 (PST) | |||
It was a Base64 problem. I used the wrong macro. The macro I used doesn't do length checking on the input, so I'm now using the one that does use length checking. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 02:48, 19 November 2013 (PST) | |||
== 256KiB limit == | |||
HA! Nobody noticed the 256KiB limit. I'll be fixing that. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> | |||
:The limit is now 16MiB. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 03:19, 19 November 2013 (PST) | |||
:Darn, I need to revisit this, my solution works great for byte content but sucks for bit content. Save that for another day. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 03:31, 19 November 2013 (PST) | |||
::I could use the WRITEBASE64INTEGER or WRITEBASE64INTEGERPAIR but both are overkill and add too much overhead. I should make a version of the functions that uses DWORDLIST2HEX but hell, I'm not doing it now. I'd like to implement SHA-3 but the memory requirements are amazing. It would take no less than 300 integers just to store the state, which would make it very slow in LSL. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:28, 25 November 2013 (PST) | |||
Latest revision as of 21:28, 25 November 2013
This script doesn't work.
Input:
"foo" (without the quotes)
SHA-256 hash according to UTF8_SHA_256("foo") in this script:
709E80C88487A2411E1EE4DFB9F22A861492D20C4765150C0C794ABD70F8147C
SHA-256 hash according to every other SHA-256 hasher I could find on the internet:
2C26B46B68FFC68FF99B453C1D30413413422D706483BFA0F98A5E886266E7AE
Soto Hax 10:09, 16 November 2013 (PST)
- Ok, so the script passes it's self tests in LSLEditor, which is a good indication we are dealing with an order of operations bug or something that LSLEditor does differently than LSL. -- Strife (talk|contribs) 22:03, 18 November 2013 (PST)
- If I had to guess without doing any real work it's probably a Base64 implementation issue with LSLEditor. -- Strife (talk|contribs) 22:19, 18 November 2013 (PST)
- The major change is how the length at the beginning is calculated (god I wish I had written more comments), I'm going to roll that bit of code back seeing as the other changes aren't effected by order of operations and are related to speeding the code up. -- Strife (talk|contribs) 22:33, 18 November 2013 (PST)
It was a Base64 problem. I used the wrong macro. The macro I used doesn't do length checking on the input, so I'm now using the one that does use length checking. -- Strife (talk|contribs) 02:48, 19 November 2013 (PST)
256KiB limit
HA! Nobody noticed the 256KiB limit. I'll be fixing that. -- Strife (talk|contribs)
- Darn, I need to revisit this, my solution works great for byte content but sucks for bit content. Save that for another day. -- Strife (talk|contribs) 03:31, 19 November 2013 (PST)
- I could use the WRITEBASE64INTEGER or WRITEBASE64INTEGERPAIR but both are overkill and add too much overhead. I should make a version of the functions that uses DWORDLIST2HEX but hell, I'm not doing it now. I'd like to implement SHA-3 but the memory requirements are amazing. It would take no less than 300 integers just to store the state, which would make it very slow in LSL. -- Strife (talk|contribs) 21:28, 25 November 2013 (PST)