[openssl-users] RSA Public Key error

2018-12-11 Thread prithiraj das
Hi,

I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere.
That key has been obtained after removing the first 24 bytes from the
originally generated RSA public key. Those 24 bytes are being replaced by
some custom 16 byte information which is being used as some sort of
identifier in some future task and those 16 bytes are playing no role in
encryption. OpenSSL fails to read this key. asn1parse shows some parsing
error and most importantly RSA encryption in OpenSSL using this key fails.
The untampered version of the RSA public key generated from the same source
and containing the original 24 bytes at the beginning of the key is
successfully read by OpenSSL and the RSA encryption using that key is also
successful in OpenSSL. But our requirement is to use the first key
containing the custom 16 byte information.

My understanding is that the first 24 bytes of RSA public key following
PKCS standards doesn't contain the modulus and exponent details required
for RSA encryption.  But OpenSSL seems to require these 24 bytes for
encryption. Can someone please confirm what kind of information is present
in the first 24 bytes of RSA Public key and/or why does OpenSSL need it? If
possible, please suggest a solution to work with that RSA public key
containing custom 16 byte information at the beginning of the key.


Thanks and Regards,
Prithiraj
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

2018-12-11 Thread Kyle Hamilton
Because only showing the O= is insufficient, you also need to show the
jurisdiction the O= is based in. (In the case of Amazon, it's a Delaware
corporation.)

The fact that browsers are getting tricked into thinking EV doesn't help is
only because their UX designers refuse to allow the information which is
necessary for actual trust to be displayed. It's not the fault of the CAs
or the EV guidelines, it's fully within the hands of the browsers to fix.

But they're worried about "providing free advertising for the CAs" (when I
suggested putting the name of the certifier on the chrome,  so that any
change would raise a flag in the users' mind) or "information overload for
the users" and "insufficient space for other important things" (when I
suggested putting more of the Subject DN on the chrome), even though those
are things that would legitimately put the onus of being tricked fairly on
the user, and off of the browsers which currently don't readily provide the
information.

Regardless, in my view it really doesn't matter. I lost faith in the
browsers being willing to continue to improve things (i.e., work against
the identity homograph arms race) long ago. So now they want to backslide?
I've done my duty to try to convince them to continue to evolve against the
threat landscape. The onus of and blame for their unwillingness to do so is
on them.  Now, I guess we'll only get to see how much of it might stick in
court.

On Sat, Dec 8, 2018, 05:59 Michael Ströder  On 12/7/18 11:44 PM, Michael Wojcik wrote:
> > Homograph attacks combined with phishing would be much cheaper and
> > easier. Get a DV certificate from Let's Encrypt for anazom.com or
> > amazom.com, or any of the Unicode homograph possibilies>
> > Part of the point of EV certificates was supposed to be making the
> > difference in trust visible to end users.
> And how do you avoid such homograph attack on subject DN attribute "O"
> (organization's name) when display the holy EV green sign?
>

By including the jurisdiction the O is organized in, of course.  O=Amazon
Inc,ST=Delaware,C=US.  (That's the point of hierarchical names, after all.
It's to reduce namespace collisions in spaces -- like independent political
entities -- which don't often cooperate together to inhibit problems like
these.)

Interesting note: I could register a corporation named "Bank of America
Corporation" in any state BofA doesn't currently have a presence, to obtain
a potentially EV-valid certificate, and their only recourse might be a
trademark lawsuit.  If I registered it in a foreign nation, they wouldn't
have any recourse at all unless they already had a presence in that
nation.  (Though they might try to convince the feds to prosecute me for
attempted fraud, even if I didn't do anything to actually attempt or
complete a fraud under that name.)  Does this mean that EV is useless? No,
it means that the overarching legal regime enables attacks that
certificates already provide the means to combat -- but only if the
certificate-consuming software properly implements it.  The idea that a
browser thinks EV is useless is worth nothing.  It just means that they
won't invest into this area of security the way they will into preventing
their processes from being hijacked by arbitrary code.

Should they have to invest in this way? I don't know. They took on the role
on their own, either to try to build trust in web-based commerce (where
they succeeded to the tune of tens of billions of dollars in economic
activity every year) or because they had to try to "keep up with the
Joneses" (i.e., Mozilla and Microsoft and Google, who were doing it for the
more altruistic reason). I can't judge whether they "should". I just know
enough to recognize what they "did".


> => EV certs also don't help in this case.
>
> Also in case of amazon.com most users know the pure domain name but not
> the *exact* company name, not to speak of the multitude of names of all
> the subsidiaries.
>

Subsidiary names are relatively irrelevant, as long as the same subsidiary
name shows up when they do the same thing. If it turns out that there's a
need for them to become relevant, a DNS record with the expected Subject DN
could be published, or a sitemap with the expected name of the subsidiary
in question could be made available, or any of a host of other options
could be explored and done. (And let's not forget the homograph attack
enabled by the lack of https-by-default.)

These arguments you make are arguments for letting the nonexistent perfect
be the enemy of the existing good. They're also arguments for not trying to
work toward the hypothetical ideal, and for throwing the baby out with the
bathwater.


> Ciao, Michael.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users