Skip to content

Migrating from RSA to Falcon

This use case demonstrates how to migrate digital signatures from RSA-2048 to Falcon-1024, a post-quantum signature algorithm. The process leverages streaming endpoints so large files can be signed, re-signed, and verified without loading all data into memory at once.

Process Overview

  1. Generate an RSA-2048 key – Used initially to sign a file.
  2. Sign a file (streaming) with RSA – The file is signed with the RSA-2048 key.
  3. Generate a Falcon-1024 key – A new post-quantum signing key is created.
  4. Re-sign the file (streaming) from RSA to Falcon – The old RSA signature is validated, and a new Falcon signature is generated, without exposing the data in memory.
  5. Verify the new Falcon signature (streaming) – Confirms that the newly created signature is valid.

flowchart TD
    Start(("Start")) --> Step1[Generate RSA-2048 key]
    Step1 --> Step2["Sign file (streaming) with RSA-2048"]
    Step2 --> Step3[Generate Falcon-1024 key]
    Step3 --> Step4["Re-sign file (streaming) RSA => Falcon"]
    Step4 --> Step5["Verify new signature (streaming) with Falcon"]
    Step5 --> End(("End"))
API Endpoints Involved ======================

Below are the five steps mentioned above, with the endpoints and example requests required to complete each step of the RSA-to-Falcon signature migration.

1. Generate an RSA-2048 Key

Purpose: Create a classical RSA-2048 key to sign data initially.

  • Endpoint: POST /api/key-management/keys
  • Request (JSON):
{
    "kid": "myOldRsaKid",
    "kty": "RSA",
    "alg": "RSA-2048",
    "keyOps": ["sign", "verify"],
    "exportable": true
}
  • Response:
    • 201 Created if the key is successfully generated.
    • (No detailed body or minimal JSON acknowledging success.)

2. Sign a File (Streaming) with RSA

Purpose: Sign a file using the RSA-2048 private key in streaming mode, suitable for large files.

  • Endpoint: POST /api/crypto/stream/sign
  • Multipart Form Fields:
    1. metadata (JSON) -- Must contain the kid referring to the RSA private key.
    2. file (binary) -- The file data to be signed.

Example (multipart/form-data):

Sample Request (pseudo raw HTTP)

POST /api/crypto/stream/sign HTTP/1.1
Host: demo.ankatech.co
Authorization: Bearer <token>
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="metadata"
Content-Type: application/json

{
  "kid": "myOldRsaKid"
}
------Boundary
Content-Disposition: form-data; name="file"; filename="largefile.dat"
Content-Type: application/octet-stream

<FILE_CONTENTS>
------Boundary--`

Response

  • Returns the signature as raw bytes (application/octet-stream).

3. Generate a Falcon-1024 Key

Purpose: Create a Falcon-1024 key, which will become the new signing key for post-quantum security.

  • Endpoint: POST /api/key-management/keys
  • Request (JSON):

{
    "kid": "myNewFalconKid",
    "kty": "FALCON",
    "alg": "Falcon1024",
    "keyOps": ["sign", "verify"],
    "exportable": true
}
- Response: - 201 Created if the key is successfully generated.

4. Re-Sign the File (Streaming) from RSA to Falcon

Purpose: Validate the old RSA signature and produce a new signature under Falcon-1024, all in a continuous streaming process.

  • Endpoint: POST /api/crypto/stream/resign
  • Multipart Form Fields:
    1. metadata (JSON) of type ResignStreamRequest, containing:
      • oldKid: The RSA public key identifier.
      • newKid: The Falcon private key identifier.
      • oldSignatureBase64: The old RSA signature in Base64.
    2. file (binary) -- The data that was previously signed.

Example (multipart/form-data):

Sample Request (pseudo raw HTTP)

POST /api/crypto/stream/resign HTTP/1.1
Host: demo.ankatech.co
Authorization: Bearer <token>
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="metadata"
Content-Type: application/json

{
  "oldKid": "myOldRsaKid",
  "newKid": "myNewFalconKid",
  "oldSignatureBase64": "QmFzZTY0U2lnbmF0dXJl"
}
------Boundary
Content-Disposition: form-data; name="file"; filename="largefile.dat"
Content-Type: application/octet-stream

<FILE_CONTENTS>
------Boundary--`

Response

  • Streams back the new signature (raw bytes) under Falcon-1024 (application/octet-stream).

5. Verify the New Signature (Streaming) with Falcon

Purpose: Confirm the integrity of the newly re-signed data using the Falcon-1024 public key in streaming mode.

  • Endpoint: POST /api/crypto/stream/verify
  • Multipart Form Fields:
    1. metadata (JSON) of type VerifySignatureStreamRequest, containing:
      • kid: The public key identifier for Falcon.
      • signatureBase64: The new signature (in Base64) generated by Falcon.
    2. file (binary) -- The same data that was re-signed.

Example (multipart/form-data):

Sample Request (pseudo raw HTTP)

POST /api/crypto/stream/verify HTTP/1.1
Host: demo.ankatech.co
Authorization: Bearer <token>
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="metadata"
Content-Type: application/json

{
  "kid": "myNewFalconKid",
  "signatureBase64": "QmFzZTY0TmV3RmFsY29uU2ln"
}
------Boundary
Content-Disposition: form-data; name="file"; filename="largefile.dat"
Content-Type: application/octet-stream

<FILE_CONTENTS>
------Boundary--`

Response (JSON):

{
  "valid": true,
  "errorMessage": ""
}
or

{
  "valid": false,
  "errorMessage": "Invalid signature."
}

Key Considerations

  • Data integrity: The file itself remains the same across signing and re-signing. Only the signature changes.
  • Post-quantum security: Falcon-1024 offers strong protection against future quantum threats.
  • No plaintext exposure: By using streaming operations, you handle large files without fully buffering them in memory. For re-sign, the original data is verified under RSA and signed with Falcon, all via a continuous pipeline.
  • Seamless migration: This approach ensures a smooth transition from RSA-based signatures to post-quantum Falcon signatures without downtime or data compromise.