يجب أن تستخدم مفاتيح API للمستخدم padding من نوع OAEP

simon · 1 يونيو 2024، 7:00ص

هناك مشكلة بسيطة وربما مشكلة أكبر:

هناك معلمة nonce مطلوبة غير مذكورة في التوثيق:

  def require_params
    %i[public_key nonce scopes client_id application_name].each { |p| params.require(p) }
  end

الآن المشكلة الأكثر تعقيدًا. تستدعي Discourse الدالة public_encrypt بدون وسائط:

github.com/discourse/discourse

app/controllers/user_api_keys_controller.rb

main


      
          key =
            @client.keys.create!(
              user_id: current_user.id,
              push_url: params[:push_url],
              scopes: scopes.map { |name| UserApiKeyScope.new(name: name) },
            )
          
          # we keep the payload short so it encrypts easily with public key
          # it is often restricted to 128 chars
          @payload = {
            key: key.key,
            nonce: params[:nonce],
            push: key.has_push?,
            api: AUTH_API_VERSION,
          }.to_json
          
          public_key_str = (@client.public_key.presence || params[:public_key])
          public_key = OpenSSL::PKey::RSA.new(public_key_str)
          
          # by default, Ruby uses `PKCS1_PADDING` here
          # see https://docs.ruby-lang.org/en/3.2/OpenSSL/PKey/RSA.html#method-i-public_encrypt

هذا يعني أن وسيطة padding تأخذ القيمة الافتراضية PKCS1_PADDING. من توثيق Ruby:

تشفير string بالمفتاح العام. تأخذ padding القيمة الافتراضية PKCS1_PADDING، والتي يُعرف أنها غير آمنة ولكنها تُحتفظ بها للتوافق مع الإصدارات السابقة.

للأسف، Node v20.14.0 (الإصدار الحالي المستقر) يُرجع خطأ إذا حاولت استدعاء crypto.privateDecrypt مع RSA_PKCS1_PADDING:

function decryptData(data: string, privateKey: string) {
  const buffer = Buffer.from(data, "base64");
  const decrypted = crypto.privateDecrypt(
    {
      key: privateKey,
      padding: crypto.constants.RSA_PKCS1_PADDING,
    },
    buffer
  );
  return decrypted.toString("utf8");
}

TypeError: RSA_PKCS1_PADDING لم يعد مدعومًا لفك التشفير الخاص، يمكن التراجع عن هذا باستخدام --security-revert=CVE-2023-46809

حل محتمل لتطبيقات Node هو تشغيل Node باستخدام علامة عدم الأمان:

node --security-revert=CVE-2023-46809

حل في جانب Discourse سيكون سهلاً، ولكني أشك في أنه سيكسر العديد من التكاملات الحالية:

public_key = OpenSSL::PKey::RSA.new(params[:public_key])
@payload = Base64.encode64(public_key.public_encrypt(@payload, OpenSSL::PKey::RSA::PKCS1_OAEP_PADDING))

mqmenchaca · 14 فبراير 2025، 10:31م

@simon نعم، هذا يسبب بالتأكيد مشاكل مع Node v22. سيكون من الرائع عدم التراجع عن تصحيحات الأمان. سيكون من الجيد تعيين علامة في استدعاء API أو إعداد الموقع في Discourse لاختيار الحشو المطلوب. (بهذه الطريقة يمكن للناس الاحتفاظ بالافتراضي الحالي إذا رغبوا في ذلك.)

mqmenchaca · 15 فبراير 2025، 1:11ص

يعمل اتباع الخطوات هنا تقريبًا باستخدام NodeRSA

github.com/rzcoder/node-rsa

I can't decrypt unencrypted

opened 07:29PM - 17 Apr 22 UTC

alantoledo007

I created a helper to get the public and private key. The pems files have been c…reated with `new NodeRSA ({b:1024})`: ```js const fs = require("fs"); const NodeRSA = require("node-rsa"); const getKeys = () => { const publicPem = fs.readFileSync("./public.pem", "utf8"); const privatePem = fs.readFileSync("./private.pem", "utf8"); const privateKey = new NodeRSA(privatePem); const publicKey = new NodeRSA(publicPem); return { privateKey, publicKey, privatePem, publicPem, }; }; const RSA = { getKeys, }; module.exports = { RSA }; ``` i can encrypt with `publicKey.encrypt(data, "base64")`. And, i can decrypt with `privateKey.decrypt(encryptedData,'utf8')`. but... I can't decrypt if I didn't create any encryption before. Just to give you an idea, I have to do this for the decryption to work: ```js publicKey.encrypt(""); //bug const decryptedData= privateKey.decrypt(encryptedRSA, "utf8"); ``` without ` publicKey.encrypt(""); //bug` the terminal returns next error: ``` throw Error('Error during decryption (probably incorrect key). Original error: ' + e); ^ Error: Error during decryption (probably incorrect key). Original error: Error: error:25078067:DSO support routines:win32_load:could not load the shared library at NodeRSA.module.exports.NodeRSA.$$decryptKey (C:\....\project-name\node_modules\node-rsa\src\NodeRSA.js:301:19) at NodeRSA.module.exports.NodeRSA.decrypt (C:\...\project-name\node_modules\node-rsa\src\NodeRSA.js:249:21) at Object.decrypt (C:\....\MyHelper.js:20:38) at Object.<anonymous> (C:\...\index.js:7:37) at Module._compile (node:internal/modules/cjs/loader:1103:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10) at Module.load (node:internal/modules/cjs/loader:981:32) at Function.Module._load (node:internal/modules/cjs/loader:822:12) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12) at node:internal/main/run_main_module:17:47 ``` npm v8.6.0 node v16.14.2 node-rsa v1.1.1 # Summary ```js // Works const encryptedData = publicKey.encrypt(data, "base64"); const decryptedData = privateKey.decrypt(encryptedData , "utf8"); ``` ```js // Not works // const encryptedData = publicKey.encrypt(data, "base64"); const decryptedData = privateKey.decrypt("your base64 encryption", "utf8"); ``` ```js // Works publicKey.encrypt(""); const decryptedData = privateKey.decrypt("your base64 encryption", "utf8"); ``` reproduce error: 1. Encrypt anything. 2. Copy the encrypted result. 3. remove or comment out the lines of code that do the encryption 4. try decrypt. (not works)

mqmenchaca · 19 فبراير 2025، 3:31م

هل يبدو هذا إضافة بسيطة؟

github.com/discourse/discourse

Add PKCS1_OAEP_PADDING option to UserAPIKeySpec

main ← qmenchaca:AddOAEPPaddingToUserApiKey

opened 03:30PM - 19 Feb 25 UTC

qmenchaca

+7 -1

This commit adds a new site setting to the User API Keys options. The padding op…tion specified here will be used to encrypt the user api key created and sent back to the client. The default, PKCS1_PADDING, is the value currently in place (so existing) integrations won't break),but if a user chooses to use PKCS1_OAEP_PADDING, they can implement it and use it as they see fit.

sam · 24 فبراير 2025، 6:17ص

أفهم أن OAEP موصى به للتطبيقات الجديدة التي تقاوم هجمات CCA / Bleichenbach. إجبار Node ليدنا على القيام بذلك أمر محزن بعض الشيء، ولكني أعتقد أن هذا من أجل “الصالح العام”.

أنا قلق للغاية بشأن جعل هذا مجرد تبديل آخر لمسؤول Discourse للتفكير فيه، فهذا كابوس.

بدلاً من ذلك، سنحتاج إلى إصلاح Discourse Hub لدعم النكهات الجديدة والقديمة في وقت واحد، ووجود شيء ما حول واجهة برمجة التطبيقات الخاصة بنا يشير إلى “إصدار” المفتاح العام.

إنه تغيير معقد يمر عبر العديد من الأنظمة. الإصلاح الذي اقترحته يسبب مشكلة لأن Discourse Hub سيتوقف عن العمل للمسؤولين الذين ينتقلون إلى هذا الوضع.

mqmenchaca · 24 فبراير 2025، 7:44م

شكرًا لك على السياق الإضافي.

للتوضيح، هذه مشكلة أواجهها أثناء التطوير المحلي. لكن عند الاتصال بمواردنا المنشورة على مثيلات AWS EC2، فهي ليست مشكلة. أفترض أن إصدار Node الخاص بهم يحتوي على تخصيصات أو إصدار خلف الكواليس حيث لا توجد مشكلة في مكتبة التشفير.

pmusaraj · 24 فبراير 2025، 10:09م

أدخل الموضوع باردًا ولكن هذا الخطأ يبدو غير صحيح. هذه ليست ميزة تم إزالتها في Node، إنها مشكلة في بعض تثبيتات OpenSSL. من مستندات Node:

استخدام crypto.constants.RSA_PKCS1_PADDING في crypto.privateDecrypt() يتطلب أن يدعم OpenSSL الرفض الضمني (rsa_pkcs1_implicit_rejection).

انظر أيضًا [Bug]: RSA_PKCS1_PADDING is no longer supported for private decryption · Issue #487 · bropat/eufy-security-client · GitHub

عند الاختبار محليًا، يعمل هذا بالنسبة لي: An example of RSA Encryption implemented in Node.js · GitHub حتى عندما أتحول إلى استخدام crypto.constants.RSA_PKCS1_PADDING للحشو لكل من التشفير وفك التشفير. أنا أستخدم OpenSSL 3.4.0 و Node 23.6.1.

الشيء الصعب في استخدام إعداد موقع هو أن العملاء لن يعرفوا أي حشو يدعمه المثيل المحدد. هذا يجعل التوافق عبر المثيلات/الخدمات أصعب في الفهم.

أعتقد أنه يجب علينا توضيح التنفيذ الحالي، أي الإشارة بوضوح إلى أننا نستخدم RSA_PKCS1_PADDING ثم التفكير في ترقية. ربما نحتاج إلى تقديم إصدارات لهذا الـ endpoint، حتى يتمكن العملاء من استخدام الحشو الصحيح بسلاسة قبل/بعد هذا الإصدار.

simon · 24 فبراير 2025، 11:33م

للفهم، هذه ليست طلب ميزة مني، إنها مجرد ملاحظة لاحظتها في يونيو من العام الماضي.

zogstrip · 15 ديسمبر 2025، 6:55ص

تنبيه: تم القيام بذلك وفقًا لـ

github.com/discourse/discourse

FIX: Preserve padding parameter through user API key authorization flow (#36640)

committed 12:56PM - 12 Dec 25 UTC

ZogStriP

+240 -320

Users/apps running OpenSSL in FIPS 140-3 mode cannot decrypt user API key respon…ses because FIPS forbids the legacy PKCS1_PADDING scheme. Commit 300ece3d added support for a `padding=oaep` parameter to use PKCS1_OAEP_PADDING instead, but the parameter was only handled in the POST endpoints. When users go through the authorization UI flow (GET /user-api-key/new → login → POST /user-api-key), the padding parameter was lost because it wasn't captured in the controller or passed through the form's hidden fields. This fix: - Captures @padding in the #new and #otp controller actions - Adds hidden field for padding in new.html.erb and otp.html.erb - Removes unused ALLOWED_PADDING_MODES constant - Refactors specs to be more organized and concise Internal ref - t/170427

الموضوع		الردود	مرات العرض
Discourse MCP User API Key Generator Error Nodejs >20 Support mcp	4	60	2 ديسمبر 2025
User-api-key returning error on generating new key Dev	1	541	9 مايو 2019
Per User API Keys Not Working Support	2	1177	2 سبتمبر 2021
User API keys specification Integrations rest-api , reference	70	34248	22 سبتمبر 2025
Secure way of encrypting payload in Javascript for user authentification Dev	6	1917	28 سبتمبر 2020

يجب أن تستخدم مفاتيح API للمستخدم padding من نوع OAEP

الموضوعات ذات الصلة