Remove File hash tracking in shared link so that it does not break on… - #1787
Open
wagiejack wants to merge 1 commit into
Open
Remove File hash tracking in shared link so that it does not break on…#1787wagiejack wants to merge 1 commit into
wagiejack wants to merge 1 commit into
Conversation
wagiejack
requested review from
Hitenjain14,
mr-naveenseven,
storybehind and
vikas7754
August 15, 2025 13:53
Contributor
|
We cannot change the auth ticket structure, the link cannot be the same if content is updated it will break proxy encryption. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Weak Encryption: All files use the same fixed encryption tag
"filetype:audio", making the encryption vulnerable to pattern analysis and reducing security strength.Fragile AuthTickets: The
AuthTicketstruct contains anActualFileHashfield that becomes invalid when file content changes, requiring users to regenerate share links every time a file is updated, even for minor changes.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:
Root Cause
The root causes stem from architectural decisions in the encryption and sharing systems:
Fixed Encryption Tag: The encryption scheme was initialized with a hardcoded literal
"filetype:audio"instead of using a deterministic, file-specific identifier.Unnecessary AuthTicket Field: The
ActualFileHashfield was included inAuthTicketstructs but was never used for validation logic - only for signature generation. This field becomes stale when file content changes.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:
ActualFileHash stringfield fromAuthTicketstructGetHashData()method to excludeActualFileHashfrom signature calculationPhase 2: Implement LookupHash-Based Encryption
Changes Made:
encscheme.InitForEncryptionto usefileref.GetReferenceLookup()for deterministic encryptionreq.encScheme.InitForDecryptionto uselookupHashPhase 3: Update Test Suites
Test Files Updated:
"filetype:audio"withlookupHashin all encryption testsTechnical 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
Backward Compatibility
This implementation maintains full backward compatibility:
The changes provide enhanced security and improved user experience while ensuring system stability and backward compatibility.