Comment by jasonjayr | Hacker News Reader

Comment by jasonjayr | Hacker News Reader

Parent Full thread

We were doing an integration with a partner for our customers, and the contact I was working with insisted on using some OpenSSL primitives that were exposed in PHP:

(a) they reversed the public + private parts of the key, and were upset when I communicated the public part of the key in cleartext

(b) they speced that the string being encrypted could not exceed 8 bytes ......

I tried so very hard and very patiently to explain to them what they were doing wrong, but they confidently insisted on their implementation. To deter fellow devs from trying this, I left loud comments in our code:

> So these guys are totally using RSA Crypto wrong. Though it's a PK Crypto system, they insist on using it backwards, and using signatures to send us cateencrypted values, and we send encrypted values back to them. It's dumb. I suspect someone read through the PHP openssl function list, spotted RSA_encrypt_private and RSA_decrypt_public and decided to get overly clever.

> This consumes a public key, and uses it to 'decrypt' a signature to recover it's original value.

> To further deter use, I will not add additional documentation here. Please read and understand the source if you think you need to use this.

Reminds me of a vendor providing an XML-RPC API with their enterprise product. The customer had a requirement that all PII information be encrypted in transit, and this was used used to send personal information about minors.

I expected them to simply turn on HTTPS like normal people.

Instead after months of effort they came back with XML Encryption. No, not the standardised one, they cooked up the their own bespoke monstrosity with hard-coded RSA keys with both the public and private parts published in their online documentation. The whole thing was base-64 encrypted XML inside more XML.

I flat rejected it, but was overruled because nobody involved had the slightest clue what proper encryption is about. It looked complicated and thorough to a lay person, so it was accepted despite my loud objections.

This is how thing happen in the real world outside of Silicon Valley.

[flagged]

> The whole thing was base-64 encrypted XML

Surely you mean "base64 encoded"

Yes, I meant "base-64 encoded encrypted XML", but I accidentally a word.

The was at least also TLS on top of that, yes?

Of course not! Plain-text HTTP only, because “that’s simpler to debug”.

> they reversed the public + private parts of the key

Is there a reason this is actually a problem? I always thought the public/private key was arbitrary and it was easier and less error prone to give people one key called public and one called private than hand them two keys and say "ok keep one of these a secret".

Don't get me wrong, not defending anyone here, just curious is there's more to it I don't know.

I'd assume that the value intended for public exponent is used as private key exponent. Typically, public key exponent is very small compared to private key exponent. This means that the private key exponent is very small in their scheme, so attacks such as Wiener's attack[0] can be used to break the encryption.

Also, I'd like to add that public exponent is usually fixed to some well-known constant such as 65537, so the attacker might just try brute-forcing when she knows the details of the scheme.

[0]: https://en.wikipedia.org/wiki/Wiener%27s_attack

That's not generally true: typically you can compute the public key from the private key, but not vice versa (i.e. crypto_scalarmult_base() in libsodium).

In RSA, that isn't possible (without assumptions), so a private key file also contains the public key data.

Honestly, I don't know. And as a non-expert on all things crypto, I delegate my trust into the labels that the expert do assign things. There may be a weakness in the algorithm if the keys are reversed, that is not immediately obvious. If the thing we're protecting is worth protecting, it's worth doing it right...

Reply on news.ycombinator.com