Skip to main content

Overview

In the encrypted integration, the browser calls SEARCH v4 with encrypt=1, using either a GET or a POST request. Research Defender wraps the normal JSON result in an AES-256-GCM encrypted blob before returning it, so the response that reaches the browser cannot be read without your private key and encryptor key. Your page passes the encrypted blob to your server, and your server decrypts it. You can write the server side in Python, Node.js, C#, or any language with AES-GCM and PBKDF2 support.
This page builds on the advanced integration. See also the secured integration, where your server calls SEARCH directly.

How it works

1

Collect library data in the browser

Load rd_sys_util.min.js, call init(), wait for the datasets, then call pass_params().
2

Request an encrypted result

Call SEARCH v4 with your publishable key and encrypt=1. The response contains a single data field.
3

Send the blob to your server

Post the data value to an endpoint on your server.
4

Decrypt on your server

Derive the key from your private key and encryptor key, decrypt the blob, and parse the JSON.

Prerequisites

  • A Research Defender publishable key, used in the browser
  • A Research Defender private key (a string), used only on your server to decrypt
  • Your encryptor key (a string), used together with the private key to derive the decryption key
  • Your survey number (sy_nr) and the respondent’s session ID (sn_ud)
  • A page served over HTTP(S). Opening the file directly from disk (file://) will not work.
Never include your private key or encryptor key in client-side code. Decrypt only on your server, and load both keys from environment variables or a secrets manager rather than source control.

Step 1: Request an encrypted result

string
GET or POST https://{environment}.rtymgt.com/api/v4/respondents/search/{publishable_key}

Request parameters

For a GET request, send these as query parameters. For a POST request, send them as fields in a JSON body.
string
required
The survey number.
string
required
The respondent’s session ID.
string
required
Set to "1" to receive the result as an encrypted blob.
string
Set to "1" to enable.
string
Set to "1" to enable.
string
Set to "1" to enable.
string
required
The string returned by pass_params(). Send it as the name of a parameter with an empty value: a query parameter for GET, or a JSON field for POST.
Send the request with credentials (credentials: "include") so Research Defender cookies are included.

Encrypted response

Once decrypted, the blob contains the same JSON result as an unencrypted search.

Browser example

encrypted-post.js

Step 2: Decrypt on your server

Blob format

After base64 decoding, the blob has this layout:

Keys

Key derivation

Decryption

Decrypt with AES-256-GCM, using the nonce from the blob and no additional authenticated data. Decryption fails if either key is wrong or the data was modified.
decrypt.py

Full samples

The samples below work together. The browser page posts the encrypted blob to /api/rd-decrypt on your server, and your server decrypts it.
encrypted-client-post.html
encrypted-client-get.html
encrypted_server.py
encrypted_server.js
EncryptedServer.cs
To run the Python or Node.js sample, copy either browser page into a static folder next to the server file as index.html, set the RD_PRIVATE_KEY and RD_ENCRYPTOR_KEY environment variables, start the server (python encrypted_server.py or node encrypted_server.js), and open http://localhost:8000. The Python sample needs pip install flask cryptography, and the Node.js sample needs npm install express.

Security recommendations

  • Keep the private key and encryptor key on your server. Load them from environment variables or a secrets manager, and never send them to the browser.
  • Treat a decryption failure as an error. AES-GCM verifies the data as it decrypts, so a failure means a wrong key or modified data. Do not fall back to trusting the blob.
  • Return only what the page needs. The samples return the full decrypted result for demonstration. In production, return a decision such as pass or fail.
  • Keep decrypted results out of logs unless you need them, and never log your private key or encryptor key.

Troubleshooting