Skip to content

Conversation

@alienx5499
Copy link
Contributor

Summary

Implements Issue #55 by adding support for additional data in timelock encryption commitments. This allows binding encryption to specific context (e.g., transaction hash, public key) to prevent replay attacks in blockchain use cases.

Changes

Core Implementation

  • TimeLockWithAdditionalData: New function that encrypts data with additional context
  • TimeUnlockWithAdditionalData: New function that decrypts and verifies additional data
  • Wrapper approach: Embeds additional data in plaintext before encryption (format: [4 bytes length][additional data][original data])
  • Backward compatibility: Original TimeLock/TimeUnlock functions unchanged

Files Modified

  • tlock.go: Added new functions with wrapper-based implementation
  • ADDITIONAL_DATA_STATUS.md: Implementation documentation and status

Key Features

  • Encryption with additional data
  • Decryption with additional data verification
  • Replay attack prevention (different contexts = different ciphertexts)
  • All existing tests pass (no regressions)
  • Comprehensive test coverage

Usage Example

// Encrypt with transaction context
txHash := []byte("0x1234...")
ciphertext, err := tlock.TimeLockWithAdditionalData(
    scheme, publicKey, roundNumber, data, txHash)

// Decrypt requires same context
plaintext, err := tlock.TimeUnlockWithAdditionalData(
    scheme, publicKey, beacon, ciphertext, txHash)

Technical Notes

  • Uses wrapper approach due to IBE signature constraints (beacon signature tied to beacon ID)
  • Additional data is verified after decryption rather than being part of IBE key derivation
  • Plaintext length limited by IBE constraints (4 bytes + additional data + original data)
  • All tests pass successfully

Testing

The implementation has been thoroughly tested with comprehensive test cases covering:

  • Encryption with and without additional data
  • Decryption with correct, incorrect, and missing additional data
  • Replay attack prevention scenarios
  • All existing tests continue to pass (no regressions)

Closes #55

@alienx5499
Copy link
Contributor Author

Hey @AnomalRoil
could you please review this PR, when you get a chance?

Copy link
Member

@AnomalRoil AnomalRoil left a comment

Choose a reason for hiding this comment

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

I think there is a misunderstanding. The additional data wouldn't be encrypted, only used in the commitment / key sharing, typically by being added to the hash in step 5 in Algo 1 in https://eprint.iacr.org/2023/189 when generating $r$.

This isn't adding proper support for AD as AD is typically used in cryptographic schemes, I'm afraid.

I think it requires first adding a new method in the IBE package in Kyber before adding support in tlock.

@alienx5499
Copy link
Contributor Author

Hi @AnomalRoil,

I'll reimplement following your feedback:

  • Additional data will NOT be encrypted - included in hash when generating r (step 3/5 of Algorithm 1)
  • Hash: H("IBE-H3" || sigma || msg || additionalData)
  • Different AD = different ciphertexts (replay prevention)
  • Wrong AD fails at cryptographic level (rP check)

Question: You mentioned adding methods to Kyber first. Should I:

  1. Create PR to Kyber repo first with EncryptCCAonG1WithAD, DecryptCCAonG1WithAD, etc., then update tlock?
  2. Keep local implementation in tlock for now?
  3. Different approach?

Which approach do you prefer? Thanks!

@alienx5499
Copy link
Contributor Author

hi @AnomalRoil,
I split the work and opened kyber PR first (drand/kyber#66). That PR adds:

  • h3WithAD, EncryptCCAonG1/2WithAD, and DecryptCCAonG1/2WithAD
  • AD stays outside the plaintext, only enters the commitment hash H("IBE-H3" || sigma || msg || AD) per step 5 of Algorithm 1
  • wrong AD fails at the cryptographic rP check

Once kyber#66 merges, I'll update this tlock PR to use those new functions and remove the wrapper approach.

@alienx5499
Copy link
Contributor Author

hi @AnomalRoil, tlock now uses the new Encrypt/Decrypt…WithAD functions (commit 5ba9120). once kyber#66 merges and releases, I’ll drop the replace directive and update go.mod. this PR now matches the cryptographic approach you described.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add the possibility to have additional data in commitment

2 participants