Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 10:45 PM, Andy Polyakov wrote: > > > The test example was provide by the authors of specification. There are > > also examples in the document. May be it will be useful. > > We are apparently talking about slightly different things. Well,

Re: [openssl-dev] PBE_UNICODE

>> > I do not know whether the authors of the CSP have implemented their own >> > mechanism of transforming the password or used any provided by the >> > Windows system default. >> >> What are chances that they too used same formally incorrect approach? > > I think that they use the system

Re: [openssl-dev] PBE_UNICODE

On 11/20/15 10:20, Dmitry Belyavsky wrote: > Dear Andy, > > On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov > wrote: > > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and

Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov wrote: > > > I understand that there should be problems with Windows. > > To eliminate possibility of misunderstanding. Claim is not limited to > problems with Windows, but that OpenSSL handles non-ASCII characters in >

Re: [openssl-dev] PBE_UNICODE

On Thu, Nov 19, 2015 at 11:16:23PM +0100, Andy Polyakov wrote: > > The way I read PKCS12 the string should be big-endian UTF-16 one. [...] > Correct procedure should be to convert it to wchar_t and > then ensure correct endianness. Please note that wchar_t itself might not have any relation with

Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 4:51 PM, Andy Polyakov wrote: > > >> ??? So suggestion is leave it as it is? Well, given the presented > >> evidence doing the right thing should break things for you. But does it > >> mean that one can/should be excused from getting

Re: [openssl-dev] PBE_UNICODE

>> The way I read PKCS12 the string should be big-endian UTF-16 one. > [...] >> Correct procedure should be to convert it to wchar_t and >> then ensure correct endianness. > > Please note that wchar_t itself might not have any relation with > UTF. You should explictly convert from the locale

Re: [openssl-dev] PBE_UNICODE

> There is a specification in > Russian, > http://tk26.ru/methods/containers_v1/Addition_to_PKCS8_v1_0.pdf > > It says: > "The password Psw should be represented in UTF-8 format without trailing > zero byte and passed as the P element of the PBKDF2 algorithm" Yeah, but this describes specific

Re: [openssl-dev] PBE_UNICODE

> ... And on Windows it's even worse. As it stands now > even passing non-ASCII strings as command-line argument [and presumably > at prompt] is not an option. This is not entirely true. Whether or not one can pass non-ASCII strings as command-line argument is language-specific. Or rather code

Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov wrote: > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and presumably > > at prompt] is not an option. > > This is not entirely true. Whether or

Re: [openssl-dev] PBE_UNICODE

Hi, > I use the openssl 1.0.2d. > > There is a commented out definition of the PBE_UNICODE define in the > file pkcs12.h > I expected it to be necessary for correct processing of the Cyrillic > symbols in PKCS12 passwords, but my test shows that the password is > correctly processed when the

[openssl-dev] PBE_UNICODE

Hello OpenSSL Team, I use the openssl 1.0.2d. There is a commented out definition of the PBE_UNICODE define in the file pkcs12.h I expected it to be necessary for correct processing of the Cyrillic symbols in PKCS12 passwords, but my test shows that the password is correctly processed when the