Skip to content

Conversation

@Inder00
Copy link
Contributor

@Inder00 Inder00 commented Oct 12, 2021

Fixes #2097
This pull request adds RSA Support.

generateKeyPair

string, string generateKeyPair( string algorithm, table options, [ function callback ])

Available algorithms: rsa
Return strings representing private and public key

RSA on encode/decodeString

string encodeString( "rsa", string, { key = publicKey })
string decodeString( "rsa", string, { key = privateKey})

Resource for testing: rsatest.zip
Thank you.

@StrixG StrixG added the enhancement New feature or request label Oct 12, 2021
@Inder00
Copy link
Contributor Author

Inder00 commented Oct 15, 2021

Changed enum name because of #2016 (comment)

@Pirulax
Copy link
Contributor

Pirulax commented Oct 17, 2021

I think the returned key should be in hex for consistency with other stuff we already have (like md5) What do others think?

React with emojis.

@AlexTMjugador
Copy link
Member

AlexTMjugador commented Oct 17, 2021

I think that representing keys with hexadecimal characters in this PR would go against the precedents set by the encodeString and teaEncode functions to treat encryption keys as binary strings. Therefore, in my opinion, treating keys as binary strings in this PR minimizes Lua API perplexity.

However, I agree that hash functions should continue to return hexadecimal strings for their results.

@Inder00 Inder00 requested a review from Pirulax October 17, 2021 22:17
Copy link
Contributor

@Pirulax Pirulax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if the test resource passes.

sbx320
sbx320 previously requested changes Oct 18, 2021
Copy link
Member

@sbx320 sbx320 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor things.

Also we need some nicer way of handling async callbacks... too much duplicaiton here. I'll have a look for getting a generalized solution for it going. Doesn't matter for this PR though.

@Inder00 Inder00 requested a review from sbx320 October 18, 2021 18:31
@Inder00 Inder00 requested a review from Pirulax October 20, 2021 20:46
@Inder00
Copy link
Contributor Author

Inder00 commented Oct 21, 2021

@sbx320 review

@Inder00 Inder00 requested a review from Pirulax October 22, 2021 12:59
@Inder00
Copy link
Contributor Author

Inder00 commented Oct 22, 2021

To the moon 🚀

@Inder00
Copy link
Contributor Author

Inder00 commented Oct 25, 2021

To the moon 🚀 (review)

Comment on lines +694 to +697
catch (const CryptoPP::Exception& ex)
{
return std::make_pair(SString(ex.GetWhat()), false);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is better exception handling than just ignoring it and returning false. However, I'm not sure if we want to expose scripts to the implementation-defined messages of CryptoPP. According to the docs, it should be feasible to get an error type and control what string is logged ourselves.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was @Pirulax idea to expose exception cause

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with exposing the exception cause somehow. But I'm not sure if we want to potentially make backwards compatibility more complicated just because some script decided to rely on some precise warning text. This is a pretty minor and far-fetched concern, though, and I'd be happy with this merged as-is.

@AlexTMjugador
Copy link
Member

About the removed tests, I think @sbx320 was not pointing that they were unnecessary and should be removed, but that they were not that useful either because they just tested the entire encryption-decryption cycle, and as such a trivial identity function implementation would also satisfy those tests.

I think that tests are useful for this PR and belong to it, as long as they test encryption and decryption separately: at least one test should test that encryption of a known plaintext with a known key-pair and cipher parameters yields the expected ciphertext, and at least other test should check that decryption of another ciphertext is able to yield back the plaintext.

@Inder00
Copy link
Contributor Author

Inder00 commented Nov 7, 2021

About the removed tests, I think @sbx320 was not pointing that they were unnecessary and should be removed, but that they were not that useful either because they just tested the entire encryption-decryption cycle, and as such a trivial identity function implementation would also satisfy those tests.

I think that tests are useful for this PR and belong to it, as long as they test encryption and decryption separately: at least one test should test that encryption of a known plaintext with a known key-pair and cipher parameters yields the expected ciphertext, and at least other test should check that decryption of another ciphertext is able to yield back the plaintext.

Test has been applied:

  • Encryption: encrypts data using random keypair (encrypt, decrypt and then compare) - encrypt cannot be compared as static data because used RSA encryption scheme OAEP using SHA outputs different encrypted data each time - have to be decrypted to compare.
  • Decryption: decrypts encrypted data in string using private key stored in another string and compare decypted data with expected data.

@Inder00 Inder00 force-pushed the feature/cryptopp_rsa branch from fdfd13c to c652a22 Compare November 7, 2021 04:11
Copy link
Member

@AlexTMjugador AlexTMjugador left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design-wise this looks fine to me, but I have not tested it, and other people might have some stylistic feedback.

@Inder00
Copy link
Contributor Author

Inder00 commented Nov 8, 2021

Design-wise this looks fine to me, but I have not tested it, and other people might have some stylistic feedback.

Thanks for review, a test resource is included in pr 🚀

@Inder00
Copy link
Contributor Author

Inder00 commented Dec 21, 2021

Review someone 🔥

@TheNormalnij
Copy link
Member

Code looks well now. I think it should be refactored into "strategy" pattern with next added algorithm.

@TheNormalnij TheNormalnij dismissed sbx320’s stale review December 21, 2021 19:29

Github bug? I don't see unresolved thread

@TheNormalnij TheNormalnij merged commit e7e3ba5 into multitheftauto:master Dec 21, 2021
@sbx320
Copy link
Member

sbx320 commented Dec 22, 2021

@TheNormalnij not a bug.

Github keeps it as "Changes Requested" regardless of unresolved threads, as there may be changes requested in a top level comment.

TheNormalnij added a commit to TheNormalnij/mtasa-blue that referenced this pull request Dec 22, 2021
@patrikjuvonen patrikjuvonen added this to the Next Release (1.6.0) milestone Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RSA, AES support

9 participants