Quote from: batmaninpink on February 21, 2014, 08:01:54 PM
I just made a pull request which fixes the OS X compile. Do you need anything else?

It didn't work... I posted the error on github

I just made a pull request which fixes the OS X compile. Do you need anything else?

Quote from: currencydebt on February 17, 2014, 07:38:57 AM
Are any of these working, secure, and ready to use or are we still working on it?

I need to evaluate the pull request and integrate it with bts_wallet and will be doing that this week.

Are any of these working, secure, and ready to use or are we still working on it?

Here is the request with the converted password: https://github.com/InvictusInnovations/BitShares/pull/37

I spent a couple of hours wondering why my scrypt code wasn't working... Turned out to be me swapping the parameters. Doh.

Then it was the UTF issue, fortunately I decided to take a break and while taking a bit of fresh air I figured out that it probably was an encoding issue. But yes I shouldve read the forum to save me that bit. Instead I had to deal with the conversion. *shudder*

Admit it you were glad about the tip with the 16-bit strings, that really messed with my head for quite some time...

Ok, guess I was a bit late this time. :)

Anyway, here are my pull requests:

https://github.com/InvictusInnovations/fc/pull/6
https://github.com/InvictusInnovations/BitShares/pull/36

Wow, i should go to sleep... just noticed i had mistaken UTF8 for 8bit chars...  :-[

Quote from: drekrob on February 11, 2014, 08:49:37 PM
This sure isn't my area of expertise. But let's say my password in multibit is four 16bit characters and it comes down to 0x1122334455667788. If the api call converts every input from UTF8 to UTF16 although it wasn't UTF8 in the first place, i would end up with 0x00110022003300440055006600770088 and could not decrypt my wallet. Where is my mistake?

Your mistake was in your application of conversions. 

If the string is already in UTF16 then you convert it to UTF8, pass it in, convert it back to UTF16 and you are good to go.

But when I grab a string from the command line it will be in UTF8, so I convert it to UTF16 and we are good to go.

When I grab a string from Qt I will grab it in UTF8, convert to to UTF16 and be good to go.

When the user enters their string into a QLineEdit then they will enter same characters they did in multibit and Qt will handle the representation internally (in what ever form they use).

This sure isn't my area of expertise. But let's say my password in multibit is four 16bit characters and it comes down to 0x1122334455667788. If the api call converts every input from UTF8 to UTF16 although it wasn't UTF8 in the first place, i would end up with 0x00110022003300440055006600770088 and could not decrypt my wallet. Where is my mistake?

Quote from: drekrob on February 11, 2014, 08:05:08 PM
That would make it impossible to use for everyone who uses 16bit chars in Multibit. Ascii password users only...

No it wouldn't.  All 16 bit UTF can be converted to and from 8 bit UTF.   When I produce a GUI that accepts characters in UTF8, it will convert to the proper UTF16 prior to being hashed for the password.

That would make it impossible to use for everyone who uses 16bit chars in Multibit. Ascii password users only...

The API calls for. UTF8. You should convert to utf 16 inside the call.


Sent from my iPhone using Tapatalk

oh and btw, the reason decryption did not work for me: Java Strings are UTF-16 (big endian)
So if you want to supply password you need to consider that!