[openssl-dev] PBE_UNICODE
Dmitry Belyavsky
beldmit at gmail.com
Fri Nov 20 12:48:14 UTC 2015
Dear Andy,
On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov <appro at openssl.org> 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
> apparently non-interoperable way. On all systems. I referred to Windows
> as complicating factor in the problem, not whole/separate problem.
Yes, I understand it.
>
>
> > So the test PKCS12 object was created using Windows using a
> > GOST-providing CSP.
> >
> > 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 method, if any, because it means they do
not increase their work :-)
>
> > But in fact the openssl being built without defining the PBE_UNICODE
> > macros was able to parse the test PKCS12.
>
> Right. Doing otherwise will put burden of big-endian UTF-16 conversion
> on caller and chances that caller gets it right are low.
Ok.
>
>
> > Thank you!
>
> ??? 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 things right?
https://tools.ietf.org/html/rfc7292#appendix-B.1 says:
The underlying password-based encryption methods in PKCS #5 v2.1 view
passwords (and salt) as being simple byte strings.
...
What's left unspecified in the above paragraph is precisely where the
byte string representing a password comes from. (This is not an
issue with salt strings, since they are supplied as a password-based
encryption (or authentication) parameter.) PKCS #5 v2.1 says: "[...]
a password is considered to be an octet string of arbitrary length
whose interpretation as a text string is unspecified. In the
interest of interoperability, however, it is recommended that
applications follow some common text encoding rules. ASCII and UTF-8
are two possibilities."
In this specification, however, all passwords are created from
BMPStrings with a NULL terminator. This means that each character in
the original BMPString is encoded in 2 bytes in big-endian format
(most-significant byte first). There are no Unicode byte order
marks. The 2 bytes produced from the last character in the BMPString
are followed by 2 additional bytes with the value 0x00.
As I understand the text herein before, there is no ultimate specification.
So I would prefer a set of options be specified by the caller with a
reasonable default value.
But as I do not have enough PKCS#12 from real-life sources, I can't predict
this default value.
Currently the openssl is in "works for me" state. To propose changes, I
need to have a set of mismatching PKCS#12 files.
--
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151120/1ae9b0c3/attachment.html>
More information about the openssl-dev
mailing list