Skip to content

Remove File hash tracking in shared link so that it does not break on… - #1787

Open
wagiejack wants to merge 1 commit into
stagingfrom
feature/private_file_share_fix
Open

Remove File hash tracking in shared link so that it does not break on…#1787
wagiejack wants to merge 1 commit into
stagingfrom
feature/private_file_share_fix

Conversation

@wagiejack

Copy link
Copy Markdown
Contributor

Encryption and AuthTicket Refactoring: LookupHash Implementation and ActualFileHash Removal

TL;DR

File updates break the link which is used for sharing them because we are hashing actual file as part of it, this update removes it and fixes tests and improves encryption

The Issue

The current file sharing system has two critical limitations that impact security and user experience:

  1. Weak Encryption: All files use the same fixed encryption tag "filetype:audio", making the encryption vulnerable to pattern analysis and reducing security strength.

  2. Fragile AuthTickets: The AuthTicket struct contains an ActualFileHash field that becomes invalid when file content changes, requiring users to regenerate share links every time a file is updated, even for minor changes.

  3. Inconsistent Encryption Keys: The lack of file-specific encryption keys means that all files share the same encryption context, which is a security anti-pattern.

These issues create a poor user experience where:

  • File updates break existing shares
  • Encryption is not file-specific
  • Users must manually regenerate share links for every file change
  • Security is compromised by using a fixed encryption tag

Root Cause

The root causes stem from architectural decisions in the encryption and sharing systems:

  1. Fixed Encryption Tag: The encryption scheme was initialized with a hardcoded literal "filetype:audio" instead of using a deterministic, file-specific identifier.

  2. Unnecessary AuthTicket Field: The ActualFileHash field was included in AuthTicket structs but was never used for validation logic - only for signature generation. This field becomes stale when file content changes.

  3. Inconsistent Encryption Context: The system lacked a deterministic way to generate file-specific encryption keys that remain stable across file content changes.

The technical root cause analysis reveals:

Fix Proposed and Implemented

Phase 1: Remove ActualFileHash from AuthTicket Structures

Changes Made:

  1. Gosdk AuthTicket Update: gosdk/zboxcore/marker/authticket.go
    • Removed ActualFileHash string field from AuthTicket struct
    • Updated GetHashData() method to exclude ActualFileHash from signature calculation
    • Maintains backward compatibility with existing tickets

Phase 2: Implement LookupHash-Based Encryption

Changes Made:

  1. Gosdk Encryption Updates:

Phase 3: Update Test Suites

Test Files Updated:

  1. Gosdk Tests:

Technical Implementation Details

LookupHash Generation: Uses fileref.GetReferenceLookup(allocationID, remotePath) to create a deterministic, file-specific encryption key that remains stable across file content changes.

Backward Compatibility: Existing encrypted files continue to work as the system gracefully handles both old and new encryption methods.

Security Enhancement: Each file now has a unique encryption context, preventing cross-file encryption analysis.

Repositories Affected

Gosdk Repository

Files Modified:

Impact: Client-side encryption and sharing functionality updated to use LookupHash-based encryption.

Deployment Order

Deployment Order: First (client-side changes)

Testing Status

  • Gosdk: [❌ In-Progress]

Backward Compatibility

This implementation maintains full backward compatibility:

  • Existing encrypted files continue to work
  • Old AuthTickets remain valid
  • No breaking changes to public APIs
  • Graceful handling of mixed encryption methods

The changes provide enhanced security and improved user experience while ensuring system stability and backward compatibility.

@Hitenjain14

Copy link
Copy Markdown
Contributor

We cannot change the auth ticket structure, the link cannot be the same if content is updated it will break proxy encryption.
Tag being same does not matter every encryption key is created using a random point on the curve where the curve is initialized using users private encryption key.
There is no such thing as file specific encryption keys, we take a random point of the curve so every file has different encryption key, for repair we store this random point in meta so we can generate same key using it https://github.com/0chain/gosdk/blob/staging/zboxcore/sdk/chunked_upload.go#L413

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.

2 participants