[{"data":1,"prerenderedAt":2570},["ShallowReactive",2],{"MARKDOWN_en_resources_white-paper":3},{"id":4,"title":5,"body":6,"description":2560,"extension":2561,"meta":2562,"navigation":2563,"path":2564,"seo":2565,"stem":2568,"__hash__":2569},"markdown\u002Fen\u002Fresources\u002Fwhite-paper.md","Retyc White Paper: Encrypted File Transfer and Datarooms",{"type":7,"value":8,"toc":2494},"minimark",[9,23,28,33,39,42,51,53,61,63,67,104,106,110,125,132,135,138,150,152,156,161,164,167,188,192,195,237,241,247,250,253,259,262,278,280,284,292,296,299,302,309,313,316,324,327,353,357,360,545,548,553,557,560,851,856,860,971,975,978,981,989,996,1003,1008,1011,1017,1028,1033,1039,1042,1045,1047,1051,1055,1058,1064,1070,1076,1079,1101,1105,1124,1139,1152,1156,1159,1165,1172,1175,1181,1185,1188,1208,1213,1226,1230,1237,1242,1254,1257,1303,1314,1318,1325,1328,1335,1339,1344,1351,1389,1392,1400,1404,1411,1425,1428,1430,1434,1438,1450,1457,1460,1471,1475,1478,1492,1498,1504,1508,1511,1543,1546,1551,1556,1559,1577,1580,1582,1586,1590,1597,1645,1648,1652,1659,1662,1668,1672,1679,1690,1694,1707,1714,1720,1723,1727,1730,1732,1736,1740,1743,1748,1774,1779,1796,1801,1818,1822,1825,1830,1862,1867,1884,1891,1896,1913,1915,1919,1923,1933,1936,1940,1943,1954,1957,1961,1967,1970,1974,1977,1981,1998,2002,2005,2013,2016,2027,2030,2032,2036,2040,2043,2048,2062,2068,2072,2075,2079,2093,2098,2102,2105,2109,2120,2125,2129,2132,2139,2143,2154,2159,2161,2165,2169,2172,2337,2345,2353,2357,2360,2364,2371,2374,2378,2381,2400,2402,2406,2409,2412,2438,2441,2443,2447,2452,2482,2484,2489],[10,11,12],"p",{},[13,14],"img",{"alt":15,"className":16,"src":21,"width":22},"Retyc logo full blue",[17,18,19,20],"mx-auto","my-8","block","w-auto","\u002Fbrand\u002FRetyc_Logo_Blue.png",300,[24,25,27],"h1",{"id":26},"white-paper-retyc","White Paper - Retyc",[29,30,32],"h2",{"id":31},"encrypted-file-transfer-and-datarooms-architecture-security-and-independence","Encrypted File Transfer and Datarooms: Architecture, Security, and Independence",[10,34,35],{},[36,37,38],"strong",{},"TripleStack SAS \u002F Version 1.0 \u002F April 2026",[40,41],"hr",{},[43,44,45],"blockquote",{},[10,46,47],{},[48,49,50],"em",{},"This document is intended for technical decision-makers, information systems directors, chief information security\nofficers (CISOs), data protection officers (DPOs), and compliance leaders within organizations operating in the European\nUnion.",[40,52],{},[43,54,55],{},[10,56,57,60],{},[36,58,59],{},"Original version takes precedence"," — This white paper was originally written in French. Although translations may\nbe made available for the convenience of international readers, only the original French version is authoritative and\nshall prevail in the event of any difference in interpretation, contradiction, or technical nuance.",[40,62],{},[29,64,66],{"id":65},"contents","Contents",[68,69,70,74,77,80,83,86,89,92,95,98,101],"ol",{},[71,72,73],"li",{},"Executive summary",[71,75,76],{},"The challenge: protecting sensitive data in a demanding regulatory environment",[71,78,79],{},"Technical architecture and security model",[71,81,82],{},"End-to-end encryption with mechanisms resistant to quantum threats",[71,84,85],{},"Zero-knowledge architecture: confidentiality by design",[71,87,88],{},"European technological independence",[71,90,91],{},"Features: file transfer and datarooms",[71,93,94],{},"Operational transparency",[71,96,97],{},"Use cases and target sectors",[71,99,100],{},"Plans and deployment",[71,102,103],{},"Conclusion",[40,105],{},[29,107,109],{"id":108},"_1-executive-summary","1. Executive summary",[10,111,112,113,116,117,120,121,124],{},"Retyc is a European platform for secure file transfer and collaborative datarooms, developed and operated by TripleStack\nSAS, an independent French company. It is built on three inseparable pillars: ",[36,114,115],{},"end-to-end encryption with mechanisms\nresistant to quantum threats",", ",[36,118,119],{},"a zero-knowledge architecture",", and ",[36,122,123],{},"European digital independence",".",[10,126,127,128,131],{},"In a context shaped by intensifying cyber threats, growing geopolitical tensions, the tightening of the European\nregulatory framework (GDPR, NIS2, DORA), and increasing awareness of risks linked to U.S. extraterritorial legislation (\nCloud Act, FISA), organizations need solutions that do not rely solely on contractual or regulatory assurances, but on *\n",[48,129,130],{},"cryptographic guarantees","*.",[10,133,134],{},"By design, Retyc limits any access to your content in plaintext, including by its own teams. Files are encrypted locally\non the user’s device before being sent to our servers. Only authorized recipients hold the decryption keys.",[10,136,137],{},"This white paper presents Retyc’s technical architecture, security model, regulatory compliance implications, and use\ncases for demanding organizations.",[43,139,140],{},[10,141,142,145,146,149],{},[36,143,144],{},"Terminology"," — In this document, the term \"password\" refers, depending on the context, either to an authentication\nsecret (login) or to a secret input used for client-side encryption (technical equivalent of a ",[48,147,148],{},"passphrase",").",[40,151],{},[29,153,155],{"id":154},"_2-the-challenge-protecting-sensitive-data-in-a-demanding-regulatory-environment","2. The challenge: protecting sensitive data in a demanding regulatory environment",[157,158,160],"h3",{"id":159},"_21-a-strengthening-european-regulatory-framework","2.1 A strengthening European regulatory framework",[10,162,163],{},"The General Data Protection Regulation (GDPR, 2016\u002F679) has imposed strict obligations on the processing of personal\ndata since 2018. Compliance is no longer optional: penalties can reach 4% of annual global turnover.",[10,165,166],{},"Beyond the GDPR, several sector-specific regulations reinforce security requirements, including:",[168,169,170,176,182],"ul",{},[71,171,172,175],{},[36,173,174],{},"NIS2"," (Directive on security of network and information systems, 2022): broadens cybersecurity obligations to many\nsectors",[71,177,178,181],{},[36,179,180],{},"DORA"," (Digital Operational Resilience Act, 2022): imposes digital resilience requirements on the financial sector",[71,183,184,187],{},[36,185,186],{},"Professional secrecy"," (lawyers, chartered accountants, doctors): ethical obligations reinforced by disciplinary and\nlegal sanctions in case of breach.",[157,189,191],{"id":190},"_22-the-real-threat-facing-file-transfers","2.2 The real threat facing file transfers",[10,193,194],{},"File transfer between organizations is one of the most exposed vectors in the security chain. Traditional solutions such\nas consumer cloud sharing, email attachments, or FTP servers present documented vulnerabilities:",[168,196,197,207,221,227],{},[71,198,199,202,203,206],{},[36,200,201],{},"Data exposed on the provider’s servers",": consumer sharing platforms encrypt data in transit (HTTPS \u002F TLS) and\nsometimes at rest on their servers, but they ",[36,204,205],{},"retain the decryption keys",". Unauthorized access to the servers, a\njudicial request, or a data breach can fully expose your content.",[71,208,209,212,213,216,217,220],{},[36,210,211],{},"Exposure to extraterritorial legislation",": providers operated by U.S. companies (even when data centers are\nphysically located within the European Union) are subject to the ",[48,214,215],{},"Cloud Act"," (2018) and the ",[48,218,219],{},"Foreign Intelligence\nSurveillance Act (FISA)",", which authorize U.S. authorities to access data stored by those companies, including data\nbelonging to European clients, without necessarily informing the data subjects.",[71,222,223,226],{},[36,224,225],{},"Lack of traceability",": informal solutions (email, instant messaging) do not provide any audit trail of access or\nany revocation of rights after sending (even if the file is deleted from the server, local copies remain accessible).",[71,228,229,232,233,236],{},[36,230,231],{},"Future threats to current data",": the so-called ",[48,234,235],{},"harvest now, decrypt later"," strategy consists of capturing\nencrypted data today in anticipation of future hardware advances (notably quantum computers) that could make it\npossible to decrypt it in a few years. Sensitive data transmitted today with conventional encryption could be\ncompromised tomorrow.",[157,238,240],{"id":239},"_23-the-limits-of-contractual-approaches","2.3 The limits of contractual approaches",[10,242,243,244,124],{},"Faced with these issues, many providers emphasize organizational and contractual guarantees: confidentiality clauses,\nsecurity commitments, certifications, audits, or internal policies. These elements are useful, but ",[36,245,246],{},"they are not\nsufficient on their own to guarantee the effective confidentiality of data",[10,248,249],{},"In practice, purely contractual protection does not change the provider’s actual technical capabilities. If data is\naccessible in plaintext on its servers, it remains exposed in the event of a technical compromise, human error, internal\nabuse, or an access request from a competent authority.",[10,251,252],{},"In other words, a contractual commitment may govern use. It does not remove the technical possibility of accessing the\ndata.",[10,254,255,258],{},[36,256,257],{},"The most robust protection therefore relies on the cryptographic architecture itself",": when content is encrypted\nclient-side and the decryption keys are not accessible to the provider, confidentiality no longer depends solely on a\npromise, an internal procedure, or a contractual framework. It rests on a verifiable technical constraint.",[10,260,261],{},"This is the logic underlying Retyc’s architecture.",[43,263,264,271],{},[10,265,266,267,270],{},"Some services reserve the right to change their terms of use, including on sensitive data-related matters. This\ndependence on an evolving contractual framework introduces ",[36,268,269],{},"uncertainty about the real level of confidentiality"," over\ntime.",[10,272,273,274,124],{},"A cryptographic constraint does not depend on an internal policy.\n",[275,276,277],"u",{},"Retyc does not rely on a contractual promise, but on an architecture designed to make data inaccessible in\nplaintext to the provider",[40,279],{},[29,281,283],{"id":282},"_3-technical-architecture-and-security-model","3. Technical architecture and security model",[43,285,286],{},[10,287,288,291],{},[36,289,290],{},"Note"," — Two types of passwords are used in Retyc for each registered user: a login password (authentication) and an\nencryption password (protection of the private key). Retyc strongly discourages using the same password for both\npurposes.",[157,293,295],{"id":294},"_31-core-principle","3.1 Core principle",[10,297,298],{},"Retyc’s architecture is designed to prevent any operator access to content in plaintext, including by the service\nprovider itself.",[10,300,301],{},"This is not a matter of trusting our teams or the robustness of our internal policies. It is a cryptographic constraint\nimposed by our architecture: the decryption keys (in plaintext) for your content never pass through our servers and are\nnever accessible to our infrastructure.",[10,303,304],{},[13,305],{"alt":306,"className":307,"src":308,"width":22},"Zero-knowledge simple",[17,18,19,20],"\u002Fimg\u002Fwhitepaper\u002Fzero_knowledge.png",[157,310,312],{"id":311},"_32-architecture-overview","3.2 Architecture overview",[10,314,315],{},"Retyc’s architecture combines several complementary layers:",[10,317,318],{},[13,319],{"alt":320,"className":321,"src":322,"width":323},"Retyc architecture",[17,18,19,20],"\u002Fimg\u002Fwhitepaper\u002Farchitecture_en.png",600,[10,325,326],{},"When a user sends a file via Retyc:",[68,328,329,336,339,346],{},[71,330,331,332,335],{},"The file is ",[36,333,334],{},"encrypted locally in the browser"," with the public key of the authorized recipient or recipients. If\nthere is no registered recipient, an ephemeral key is generated for the transfer and encrypted with a password chosen\nby the sender.",[71,337,338],{},"The encrypted file is sent to our servers: we only see unreadable data.",[71,340,341,342,345],{},"The recipient retrieves the encrypted file and decrypts it ",[36,343,344],{},"locally in their browser"," with their private key.",[71,347,348,349,352],{},"Each user’s private key is stored on our servers in ",[36,350,351],{},"encrypted form with the user’s encryption password",", which we\ndo not know.",[157,354,356],{"id":355},"_33-what-retyc-can-and-cannot-do","3.3 What Retyc can and cannot do",[10,358,359],{},"It is essential to be explicit about the technical limits of our access:",[361,362,363,379],"table",{},[364,365,366],"thead",{},[367,368,369,373,376],"tr",{},[370,371,372],"th",{},"Data",[370,374,375],{},"Scope",[370,377,378],{},"Accessible to Retyc?",[380,381,382,397,411,424,441,453,465,477,489,521,533],"tbody",{},[367,383,384,388,391],{},[385,386,387],"td",{},"Email, first name, last name",[385,389,390],{},"Global",[385,392,393,396],{},[36,394,395],{},"Yes"," — required for operation",[367,398,399,402,405],{},[385,400,401],{},"File content (plaintext)",[385,403,404],{},"Retyc",[385,406,407,410],{},[36,408,409],{},"No"," — encrypted before upload",[367,412,413,416,418],{},[385,414,415],{},"File metadata (name, size, type)",[385,417,404],{},[385,419,420,423],{},[36,421,422],{},"Partially"," — file size is not encrypted (necessary for storage management), but other metadata (type, name) is encrypted.",[367,425,426,429,431],{},[385,427,428],{},"Special case: file names in a dataroom",[385,430,404],{},[385,432,433,435,436,440],{},[36,434,409],{}," — the name is encrypted; a ",[437,438,439],"code",{},"sha256"," hash with a 256-bit random salt (CSPRNG), itself encrypted E2EE with the session key, is used for version management. Since the salt is inaccessible to the server in plaintext, the server cannot infer file names.",[367,442,443,446,448],{},[385,444,445],{},"Transfer messages",[385,447,404],{},[385,449,450,452],{},[36,451,409],{}," — E2EE encrypted",[367,454,455,458,460],{},[385,456,457],{},"Activity log and messaging (dataroom)",[385,459,404],{},[385,461,462,464],{},[36,463,422],{}," — message content and sensitive metadata are encrypted. Information required for operation (e.g. users, event types) remains visible.",[367,466,467,470,472],{},[385,468,469],{},"Transfer \u002F dataroom title",[385,471,404],{},[385,473,474,476],{},[36,475,395],{}," — not E2EE encrypted",[367,478,479,482,484],{},[385,480,481],{},"A user’s private key",[385,483,404],{},[385,485,486,488],{},[36,487,409],{}," — stored only in encrypted form",[367,490,491,494,497],{},[385,492,493],{},"Login password",[385,495,496],{},"IAM",[385,498,499,501,502,116,505,116,508,116,511,116,514,517,518,124],{},[36,500,409],{}," — hashed server-side with argon2 (version ",[437,503,504],{},"1.3",[437,506,507],{},"type=id",[437,509,510],{},"iterations=5",[437,512,513],{},"parallelism=1",[437,515,516],{},"memory=19 MiB","). ",[36,519,520],{},"If authentication is performed via an external provider, no password is stored",[367,522,523,526,528],{},[385,524,525],{},"Recovery of the encryption password \u002F private key",[385,527,404],{},[385,529,530,532],{},[36,531,409],{}," — if the encryption password is lost, access to encrypted data is permanently lost.",[367,534,535,538,540],{},[385,536,537],{},"Email address (notifications)",[385,539,390],{},[385,541,542,544],{},[36,543,395],{}," — used to send all email notifications (transfer received, dataroom invitation, verification code, etc.). The email delivery provider does not receive files or encrypted content.",[10,546,547],{},"This transparency about our technical limits is a core part of our commitment to users.",[43,549,550],{},[10,551,552],{},"The \"IAM\" scope (Identity and Access Management) covers authentication and user management data (handled by the\nKeycloak v26.x application). The \"Retyc\" scope covers data related to transfers, datarooms, and files. The \"Global\"\nscope covers data present in both systems.",[157,554,556],{"id":555},"_34-assumptions-and-limits-of-the-security-model","3.4 Assumptions and limits of the security model",[10,558,559],{},"Retyc significantly reduces several risks related to the transfer and storage of sensitive files. However, it is\nimportant to acknowledge the limits inherent to any security solution:",[361,561,562,577],{},[364,563,564],{},[367,565,566,569,571,574],{},[370,567,568],{},"Threat \u002F Risk",[370,570,375],{},[370,572,573],{},"Risk reduction by Retyc",[370,575,576],{},"Limits",[380,578,579,592,607,621,640,654,668,682,696,710,724,738,753,768,782,794,808,822,837],{},[367,580,581,584,586,589],{},[385,582,583],{},"User device compromise",[385,585,390],{},[385,587,588],{},"-",[385,590,591],{},"If the user’s device is compromised by malware or physical access, locally encrypted data may be exposed. Retyc recommends strong client-side security practices (antivirus, MFA, access management).",[367,593,594,597,599,604],{},[385,595,596],{},"Automated attacks (scans, brute force, etc.)",[385,598,390],{},[385,600,601],{},[36,602,603],{},"High",[385,605,606],{},"Retyc implements application protection mechanisms (WAF) and intrusion detection, including solutions such as CrowdSec, to identify and block malicious behavior. Targeted or sophisticated attacks may still bypass these mechanisms.",[367,608,609,612,614,618],{},[385,610,611],{},"Brute-force attack against the authentication system",[385,613,496],{},[385,615,616],{},[36,617,603],{},[385,619,620],{},"Keycloak implements protections against brute-force attacks (rate limiting, account lockout).",[367,622,623,626,628,633],{},[385,624,625],{},"Brute-force attack against the password protecting a private key",[385,627,404],{},[385,629,630],{},[36,631,632],{},"Partial",[385,634,635,636,639],{},"The private key is encrypted with scrypt (",[437,637,638],{},"N=2^18","), making each attempt very costly in time and resources. Actual resistance still depends on the strength of the password chosen by the user: a weak password significantly reduces this protection despite the derivation cost.",[367,641,642,645,647,651],{},[385,643,644],{},"Attack against cryptographic algorithms",[385,646,404],{},[385,648,649],{},[36,650,603],{},[385,652,653],{},"Retyc uses modern and robust algorithms against known attacks, with a hybrid scheme integrating mechanisms resistant to quantum threats according to current knowledge.",[367,655,656,659,661,665],{},[385,657,658],{},"Configuration or implementation error",[385,660,390],{},[385,662,663],{},[36,664,632],{},[385,666,667],{},"Although we follow secure development best practices, human error in configuration or implementation could introduce a vulnerability. We have rigorous code review and security testing processes in place to reduce this risk.",[367,669,670,673,675,679],{},[385,671,672],{},"Insider threat (privilege abuse)",[385,674,390],{},[385,676,677],{},[36,678,603],{},[385,680,681],{},"Due to the zero-knowledge architecture, even a malicious employee or privilege abuse does not provide the technical means to access content in plaintext.",[367,683,684,687,689,693],{},[385,685,686],{},"Judicial request",[385,688,390],{},[385,690,691],{},[36,692,603],{},[385,694,695],{},"In the event of an access request from a competent authority, Retyc and its file hosting provider can only provide unreadable encrypted data and connection logs. We cannot decrypt what we have no means to decrypt.",[367,697,698,701,703,707],{},[385,699,700],{},"Data breach on the provider’s servers",[385,702,390],{},[385,704,705],{},[36,706,603],{},[385,708,709],{},"In the event of a data breach on our servers, encrypted content remains unreadable. We do not store plaintext data that could be exposed. However, this does not provide access to plaintext content.",[367,711,712,715,717,721],{},[385,713,714],{},"Breach of data stored in the database (email, first name, last name)",[385,716,390],{},[385,718,719],{},[36,720,632],{},[385,722,723],{},"In the event of a personal data breach, user identity information could be exposed.",[367,725,726,729,731,735],{},[385,727,728],{},"Theft of session cookies or other authentication data",[385,730,390],{},[385,732,733],{},[36,734,632],{},[385,736,737],{},"In the event of session cookie theft, an attacker could potentially access a user account. We recommend using MFA to reduce this risk and not using Retyc on shared or unsecured devices. To limit the risk, session validity is time-limited and inactive sessions are automatically logged out.",[367,739,740,743,746,750],{},[385,741,742],{},"Malicious script injection attack (XSS) on the user interface",[385,744,745],{},"Retyc (web only)",[385,747,748],{},[36,749,603],{},[385,751,752],{},"We apply strict security policies (CSP, HSTS) to reduce the risk of XSS attacks.",[367,754,755,758,760,765],{},[385,756,757],{},"Theft of the transfer password",[385,759,404],{},[385,761,762],{},[36,763,764],{},"Low",[385,766,767],{},"If an attacker obtains a transfer password, they can access the content as long as the transfer is active. The sender can disable the transfer at any time to revoke access. For sensitive data, we recommend using registered recipients (asymmetric keys).",[367,769,770,773,775,779],{},[385,771,772],{},"Revoked user who already downloaded files before revocation",[385,774,404],{},[385,776,777],{},[36,778,764],{},[385,780,781],{},"If a revoked user already downloaded the files before revocation, they may keep a local copy. Revocation prevents future access but cannot erase copies already downloaded. We recommend limiting link validity periods to reduce this risk.",[367,783,784,787,789,791],{},[385,785,786],{},"Forgotten private key password",[385,788,404],{},[385,790,588],{},[385,792,793],{},"In the absence of a \"Master Key,\" forgetting the password by the sole holder of access results in data loss. However, multiple authorized members provide access redundancy.",[367,795,796,799,801,805],{},[385,797,798],{},"Source code compromise",[385,800,404],{},[385,802,803],{},[36,804,632],{},[385,806,807],{},"In the event of source code compromise, an attacker could theoretically introduce a vulnerability or backdoor. However, the zero-knowledge architecture limits the risk of access to encrypted data. We follow strict code review and security practices to minimize this risk.",[367,809,810,813,815,819],{},[385,811,812],{},"Compromise of a user’s private key (exfiltration or targeted attack)",[385,814,404],{},[385,816,817],{},[36,818,632],{},[385,820,821],{},"In the event of compromise of a user’s private key, data encrypted for that user could be exposed. However, other users and their data remain protected. In case of suspicion or compromise, key rotation and changing the encryption password help limit the impact.",[367,823,824,827,830,834],{},[385,825,826],{},"Compromise of hosting infrastructure (Scaleway, Clever Cloud)",[385,828,829],{},"Hosting",[385,831,832],{},[36,833,632],{},[385,835,836],{},"In the event of hosting infrastructure compromise, encrypted data remains unreadable. However, such a compromise could lead to temporary service unavailability and possible exposure of unencrypted data.",[367,838,839,842,844,848],{},[385,840,841],{},"Use of a revoked key to decrypt past data",[385,843,404],{},[385,845,846],{},[36,847,764],{},[385,849,850],{},"During key rotation, the old encrypted private key is deleted server-side and the session key is re-encrypted for the relevant spaces. Residual risk is limited to the case where the user kept a local copy of their private key outside Retyc. Rotating a user’s key only re-encrypts the session key for transfers they created and datarooms where they are an administrator. In other cases, rekeying must be triggered by a space administrator.",[43,852,853],{},[10,854,855],{},"Note — The security of mechanisms relying on a password depends on the strength of the chosen secret.\nWe recommend using strong, unique passwords.",[157,857,859],{"id":858},"_35-mechanisms-minimizing-residual-risks","3.5 Mechanisms minimizing residual risks",[361,861,862,874],{},[364,863,864],{},[367,865,866,869,872],{},[370,867,868],{},"Mitigation mechanism",[370,870,871],{},"Description",[370,873,576],{},[380,875,876,887,898,908,919,929,939,949,960],{},[367,877,878,881,884],{},[385,879,880],{},"Optional strong authentication (MFA)",[385,882,883],{},"We recommend and support two-factor authentication to strengthen the security of user accounts.",[385,885,886],{},"Does not protect against attacks directly targeting the user’s device or client-side configuration errors.",[367,888,889,892,895],{},[385,890,891],{},"Strict HSTS, CSP, CORS, and permissions policy",[385,893,894],{},"We apply strict HTTP security policies to protect against man-in-the-middle attacks and script injection.",[385,896,897],{},"Does not protect against attacks directly targeting the user’s device.",[367,899,900,903,906],{},[385,901,902],{},"WAF and anomaly monitoring",[385,904,905],{},"We use a web application firewall (WAF) and intrusion detection systems to monitor suspicious activity on our servers.",[385,907,886],{},[367,909,910,913,916],{},[385,911,912],{},"Rate limiting and brute-force protection",[385,914,915],{},"We implement rate-limiting mechanisms to reduce the impact of automated abuse and certain denial-of-service attacks.",[385,917,918],{},"Hosting may become temporarily unavailable during a denial-of-service attack, but data remains protected.",[367,920,921,924,927],{},[385,922,923],{},"Regular updates and vulnerability monitoring",[385,925,926],{},"We actively track security vulnerabilities and apply regular updates to fix potential flaws.",[385,928,886],{},[367,930,931,934,937],{},[385,932,933],{},"No third-party tracking scripts and minimal collection of personal data",[385,935,936],{},"We do not use any third-party cookies that could be exploited for advertising tracking or behavioral analytics, and we limit personal data collection to what is strictly necessary.",[385,938,886],{},[367,940,941,944,947],{},[385,942,943],{},"Authentication with Keycloak and role-based access management (RBAC)",[385,945,946],{},"We use Keycloak to manage authentication by limiting session duration and applying granular role-based access control.",[385,948,886],{},[367,950,951,954,957],{},[385,952,953],{},"Encryption key rotation",[385,955,956],{},"We provide the ability to rotate encryption keys to limit the impact of a possible compromise.",[385,958,959],{},"Key rotation helps limit the impact of a compromise, but does not protect against any data exposed before rotation.",[367,961,962,965,968],{},[385,963,964],{},"Account deactivation by an administrator (Business\u002FEnterprise)",[385,966,967],{},"An administrator can deactivate a user account, immediately cutting off all access to resources: invalidation of active sessions (authentication) and revocation of access rights (ACLs).",[385,969,970],{},"Does not remove file copies already downloaded locally by the user before deactivation.",[157,972,974],{"id":973},"_36-identity-and-access-lifecycle-management","3.6 Identity and access lifecycle management",[10,976,977],{},"Retyc uses Keycloak for identity and access management (IAM).",[10,979,980],{},"Users can sign in with:",[168,982,983,986],{},[71,984,985],{},"an email address and password",[71,987,988],{},"external identity providers (SSO) compatible with SAML 2.0 or OpenID Connect.",[10,990,991,992,995],{},"Sessions are ",[36,993,994],{},"time-limited",", and inactive users are automatically logged out.\nIn the event of suspected compromise or abnormal behavior, sessions can be manually invalidated by a Retyc\nadministrator.",[10,997,998,999,1002],{},"Access to the authentication service is ",[36,1000,1001],{},"restricted to the strictly necessary scope"," required for Retyc to operate. A\ndedicated reverse proxy limits public exposure to the authentication area used by the platform only, reducing the attack\nsurface.",[10,1004,1005],{},[36,1006,1007],{},"Access management in organizations",[10,1009,1010],{},"In an organization-based setup (Business and Enterprise plans), administrators can manage collaborator access and revoke\naccess rights.",[10,1012,1013,1016],{},[36,1014,1015],{},"Invited but unregistered users"," can be removed at any time by an administrator, resulting in the deletion of the data\nthey own (transfers, datarooms).",[10,1018,1019,1020,1023,1024,1027],{},"By contrast, when a user ",[36,1021,1022],{},"already has an account at the time of invitation",", removing their access to an organization\nends their rights within that organization ",[36,1025,1026],{},"without deleting their account or the data"," they own.",[10,1029,1030],{},[36,1031,1032],{},"Integration with enterprise environments",[10,1034,1035,1036,149],{},"Retyc offers a mechanism for automatically assigning users to an organization based on their email address (e.g.\n",[437,1037,1038],{},"@company.tld",[10,1040,1041],{},"Retyc also supports integration with identity providers (IdPs) owned by customer organizations, subject to compatibility\nwith Keycloak, notably via standards such as SAML 2.0 or OpenID Connect.",[10,1043,1044],{},"This approach makes it possible to rely on the organization’s existing authentication mechanisms (internal directory,\nSSO, MFA) without duplicating identities, while preserving consistent user affiliation management. The associated\nsecurity policies, when delegated to the customer’s IdP, remain under that customer’s control.",[40,1046],{},[29,1048,1050],{"id":1049},"_4-end-to-end-encryption-with-mechanisms-resistant-to-quantum-threats","4. End-to-end encryption with mechanisms resistant to quantum threats",[157,1052,1054],{"id":1053},"_41-beyond-conventional-encryption","4.1 Beyond conventional encryption",[10,1056,1057],{},"There are three levels of data protection in file sharing solutions:",[10,1059,1060,1063],{},[36,1061,1062],{},"Level 1 — Encryption in transit (HTTPS \u002F TLS)",": protection during network transfer. Standard today, but insufficient:\nyour data arrives decrypted on the provider’s servers, which can access it.",[10,1065,1066,1069],{},[36,1067,1068],{},"Level 2 — Encryption at rest (server-side encryption)",": files are encrypted on the provider’s servers. This protects\nagainst physical attacks, but the provider retains the decryption keys. It can access content for maintenance, analysis,\nor in response to legal requests.",[10,1071,1072,1075],{},[36,1073,1074],{},"Level 3 — End-to-end encryption (E2EE)",": the approach adopted by Retyc. Files are encrypted on the sender’s device\nbefore any upload. Only authorized recipients can decrypt them. The provider does not hold the elements required to\naccess content in plaintext.",[10,1077,1078],{},"These first two levels (transport and storage) are now industry standards and do not, by themselves, constitute a\nconfidentiality protection mechanism against the provider.",[43,1080,1081,1091],{},[10,1082,1083,1084,1087,1088,124],{},"The file sharing market often maintains ",[36,1085,1086],{},"frequent confusion",": some solutions marketed as “encrypted” actually rely\non encryption in transit or at rest, standard mechanisms now widely used and ",[36,1089,1090],{},"insufficient to guarantee data\nconfidentiality",[10,1092,1093,1094,1097,1098,124],{},"These approaches leave the provider with the ",[36,1095,1096],{},"technical ability to access plaintext data"," and are not equivalent to\nend-to-end encryption. ",[275,1099,1100],{},"Retyc adopts the latter approach",[157,1102,1104],{"id":1103},"_42-age-encryption-cryptography","4.2 age-encryption cryptography",[10,1106,1107,1108,1111,1112,1115,1116,1123],{},"Retyc relies on the ",[36,1109,1110],{},"age"," encryption format, designed to provide a modern, simple, and robust approach to file\nencryption. Age can be considered a ",[36,1113,1114],{},"trusted component",": its specification is public and formal, it relies on proven\ncryptographic primitives, and it is designed and maintained by ",[1117,1118,1122],"a",{"href":1119,"rel":1120},"https:\u002F\u002Ffilippo.io",[1121],"nofollow","Filippo Valsorda",", a\nrecognized cryptographer (former security lead of Google’s Go team).",[10,1125,1126,1127,1132,1133,1138],{},"On the web application side, Retyc uses ",[1117,1128,1131],{"href":1129,"rel":1130},"https:\u002F\u002Fgithub.com\u002FFiloSottile\u002Ftypage",[1121],"age-encryption",", the\nTypeScript implementation of the ",[1117,1134,1137],{"href":1135,"rel":1136},"https:\u002F\u002Fage-encryption.org\u002Fv1",[1121],"age specification",".\nThis approach makes it possible to execute cryptographic operations directly client-side,\nwithout exposing plaintext content to the server.",[10,1140,1141,1142,1147,1148,1151],{},"The transparency of the cryptographic code is an additional guarantee: the ",[36,1143,1144,1146],{},[437,1145,1131],{}," library"," is open source\nand its code can be inspected and audited by independent third-party experts. The source code of the web application (\nfrontend and backend) is not public, but the ",[36,1149,1150],{},"Retyc CLI is open source"," and auditable, and the underlying\ncryptographic primitives are as well.",[157,1153,1155],{"id":1154},"_43-encryption-with-post-quantum-hybrid-keys","4.3 Encryption with post-quantum hybrid keys",[10,1157,1158],{},"When quantum computers reach sufficient power, they will be able to break the conventional asymmetric algorithms (RSA,\nECC) currently used in most security solutions.",[10,1160,1161,1162,1164],{},"The ",[48,1163,235],{}," strategy is a concrete threat: malicious or state actors capture encrypted data today\nin anticipation of decrypting it in the future. For data with a long lifetime (contracts, medical files, financial\ndata), this risk is real.",[10,1166,1167,1168,1171],{},"Retyc uses by default a hybrid key scheme integrating mechanisms ",[36,1169,1170],{},"resistant to quantum threats",", within the age\nformat.",[10,1173,1174],{},"This hybrid approach aims to reduce the risk that a weakness affecting only one component could by itself compromise\ndata confidentiality.",[10,1176,1177,1178,124],{},"All keys are generated and encrypted exclusively on the user’s device.\n",[36,1179,1180],{},"Private keys are not accessible in plaintext to the Retyc infrastructure",[157,1182,1184],{"id":1183},"_44-key-management-and-rotation","4.4 Key management and rotation",[10,1186,1187],{},"Each Retyc user has an asymmetric key pair (public\u002Fprivate):",[168,1189,1190,1196,1202],{},[71,1191,1161,1192,1195],{},[36,1193,1194],{},"public key"," is stored on our servers and used by senders to encrypt files for that user.",[71,1197,1161,1198,1201],{},[36,1199,1200],{},"private key"," is encrypted with the user’s encryption password and stored on our servers in encrypted form. We\nnever have access to it in plaintext.",[71,1203,1204,1207],{},[36,1205,1206],{},"Key rotation"," is available on all plans, allowing new keys to be generated and existing data to be re-encrypted.",[10,1209,1210],{},[36,1211,1212],{},"No master key principle",[43,1214,1215],{},[10,1216,1217,1218,1221,1222,1225],{},"Unlike traditional \"cloud\" architectures, Retyc implements no master key (\"Master Key\") and no emergency recovery\nmechanism. ",[36,1219,1220],{},"This architecture provides no administrator access to plaintext content",".\nResponsibility for password retention ",[36,1223,1224],{},"lies exclusively with the user or their organization’s secret management\npolicy"," (password vault, IAM).",[157,1227,1229],{"id":1228},"_45-detailed-technical-implementation","4.5 Detailed technical implementation",[43,1231,1232],{},[10,1233,1234],{},[48,1235,1236],{},"This section is intended for technical teams and auditors who want to verify the platform’s cryptographic\nproperties.",[1238,1239,1241],"h4",{"id":1240},"cryptographic-primitives","Cryptographic primitives",[10,1243,1244,1245,1248,1249,1253],{},"Retyc relies on ",[1117,1246,1131],{"href":1129,"rel":1247},[1121],", the TypeScript implementation\nof the ",[1117,1250,1252],{"href":1135,"rel":1251},[1121],"age format"," for client-side encryption operations.",[10,1255,1256],{},"Depending on the mechanisms implemented by this library:",[168,1258,1259,1265,1279,1285,1297],{},[71,1260,1261,1264],{},[36,1262,1263],{},"X25519",": for key exchange.",[71,1266,1267,1270,1271,1274,1275,1278],{},[36,1268,1269],{},"ML-KEM-768",": as part of hybrid keys integrating mechanisms ",[36,1272,1273],{},"resistant to currently known quantum threats"," (\nMLKEM768-X25519 hybrid scheme). This scheme is implemented via an extension of the age format (key format\n",[437,1276,1277],{},"age1pq1...","), in addition to the standard age format (FIPS 203).",[71,1280,1281,1284],{},[36,1282,1283],{},"ChaCha20-Poly1305",": for authenticated data encryption.",[71,1286,1287,1290,1291,1293,1294,1296],{},[36,1288,1289],{},"scrypt"," (",[437,1292,638],{},"): derivation of the wrapping key during passphrase-based encryption (age ",[437,1295,1289],{}," stanza).",[71,1298,1299,1302],{},[36,1300,1301],{},"HKDF-SHA-256",": derivation of the payload encryption key from the file key (internal age mechanism).",[43,1304,1305],{},[10,1306,1307,1309,1310,1313],{},[36,1308,290],{}," — scrypt is used by age for private key protection, an operation executed ",[36,1311,1312],{},"client-side"," in the browser.\nArgon2id is used independently by Keycloak for hashing authentication passwords server-side. These are two separate\nsystems operating across two different scopes.",[1238,1315,1317],{"id":1316},"generation-of-user-key-pairs","Generation of user key pairs",[10,1319,1320,1321,1324],{},"Key pairs are generated via ",[437,1322,1323],{},"generateHybridIdentity()",", which produces a hybrid X25519 + ML-KEM-768 identity.\nThis hybrid scheme aims to reduce the risk that a weakness affecting only one component could by itself compromise data\nconfidentiality: a mathematical breakthrough against X25519 or a weakness discovered in ML-KEM-768.",[10,1326,1327],{},"Since all Retyc user identities are hybrid by default, there is no mix between post-quantum hybrid recipients and\nnon-post-quantum recipients (an explicit constraint of the age specification).",[10,1329,1330,1331,1334],{},"The raw private key is ",[36,1332,1333],{},"never transmitted or stored in plaintext"," on our servers. It is encrypted client-side with the\nuser’s encryption password via age in passphrase mode (scrypt), which makes brute-force attacks prohibitively expensive\nin terms of machine cost.",[1238,1336,1338],{"id":1337},"multi-recipient-encryption","Multi-recipient encryption",[43,1340,1341],{},[10,1342,1343],{},"The principle described below is the reference operation. Variants exist depending on the use case (recipient\nmanagement, access modality), while preserving the same security guarantees.",[10,1345,1346,1347,1350],{},"Transfers and datarooms rely on a ",[36,1348,1349],{},"shared cryptographic foundation",":",[68,1352,1353,1360,1371,1380],{},[71,1354,1355,1356,1359],{},"A hybrid X25519 + ML-KEM-768 key pair (the ",[36,1357,1358],{},"session key",") is generated client-side.",[71,1361,1362,1363,1366,1367,1370],{},"Files and ",[36,1364,1365],{},"sensitive metadata"," (file name, MIME type) are encrypted with the ",[437,1368,1369],{},"session_public_key",". For large files,\nencryption is applied by chunk to limit memory impact.",[71,1372,1161,1373,1376,1377,124],{},[437,1374,1375],{},"session_private_key"," is encrypted for each registered recipient via ",[437,1378,1379],{},"encryptStringWithRecipients()",[71,1381,1382,1383,1386,1387,124],{},"At download time, the recipient decrypts ",[437,1384,1385],{},"session_private_key_enc"," with their own age private key, then decrypts the\nfiles locally with the resulting ",[437,1388,1375],{},[10,1390,1391],{},"The server only receives encrypted elements: files, metadata, and the session key are inaccessible to it in plaintext.",[10,1393,1394],{},[13,1395],{"alt":1396,"className":1397,"src":1398,"width":1399},"Transfer multi recipient",[17,18,19,20],"\u002Fimg\u002Fwhitepaper\u002Fmulti_recipient_transfer_tech.png",400,[1238,1401,1403],{"id":1402},"isolation-of-cryptographic-operations-in-the-browser","Isolation of cryptographic operations in the browser",[10,1405,1406,1407,1410],{},"All cryptographic operations run inside a dedicated ",[36,1408,1409],{},"Web Worker",", isolated from the main UI thread. This architectural\nchoice has two consequences:",[168,1412,1413,1419],{},[71,1414,1415,1418],{},[36,1416,1417],{},"Performance",": encryption operations, which can be lengthy for large files, do not block the user interface.",[71,1420,1421,1424],{},[36,1422,1423],{},"Isolation",": the cryptographic context is separated from the rest of the application, reducing the attack surface\nfor malicious script injection into the main DOM.",[10,1426,1427],{},"Binary buffers are transferred between threads by ownership transfer rather than copying, limiting in-memory duplication\nof sensitive data.",[40,1429],{},[29,1431,1433],{"id":1432},"_5-zero-knowledge-architecture-confidentiality-by-design","5. Zero-knowledge architecture: confidentiality by design",[157,1435,1437],{"id":1436},"_51-definition","5.1 Definition",[43,1439,1440],{},[10,1441,1442,1445,1446,1449],{},[36,1443,1444],{},"Terminology note"," — The term \"zero-knowledge\" is used here in its common industry sense: the provider has no access\nto content in plaintext. In academic cryptography, the term refers to ",[48,1447,1448],{},"zero-knowledge proofs"," (\nGoldwasser-Micali-Rackoff), which is a distinct concept. Our usage is widespread in the industry but should be\ndistinguished from its strict academic meaning.",[10,1451,1452,1453,1456],{},"A zero-knowledge architecture means that the service provider has no knowledge (",[48,1454,1455],{},"zero knowledge",") of the content of the\ndata it processes. This property is guaranteed by cryptographic construction, not by an internal policy.",[10,1458,1459],{},"At Retyc, zero-knowledge means in concrete terms:",[168,1461,1462,1465,1468],{},[71,1463,1464],{},"We do not have the elements required to access in plaintext the contents of files, file names, associated messages, or\nusers’ private keys.",[71,1466,1467],{},"If a user forgets their encryption password, we can neither recover their private key nor decrypt the associated data.",[71,1469,1470],{},"Cryptographic isolation: each space is independent. Compromise of one account or one administrator workstation does\nnot provide any technical leverage to decrypt other collaborators’ data.",[157,1472,1474],{"id":1473},"_52-implications-for-compliance","5.2 Implications for compliance",[10,1476,1477],{},"The zero-knowledge architecture has direct implications for regulatory compliance:",[10,1479,1480,1483,1484,1487,1488,1491],{},[36,1481,1482],{},"For GDPR",": encrypted data for which we do not hold the keys is inaccessible to us in plaintext. We cannot exploit it\nfor unauthorized purposes and do not hold the elements needed to access it in plaintext. Retyc nevertheless remains *\n",[48,1485,1486],{},"data controller","* under the GDPR for account data (email, first name, last name) and ",[36,1489,1490],{},"processor"," for encrypted\ncontent. The zero-knowledge architecture reduces our exposure; it does not exempt us from our regulatory obligations.",[10,1493,1494,1497],{},[36,1495,1496],{},"For professional secrecy",": lawyers, chartered accountants, and healthcare professionals are subject to strict\nconfidentiality obligations regarding entrusted data.\nA purely contractual guarantee is not enough to address this technically. Retyc’s zero-knowledge architecture provides\ncryptographic reinforcement that we cannot bypass.",[10,1499,1500,1503],{},[36,1501,1502],{},"In response to judicial requests",": in the event of an access request from an authority, Retyc can only deliver\nunreadable encrypted data. We cannot decrypt what we have no means to decrypt.",[157,1505,1507],{"id":1506},"_53-deliberate-and-transparent-limits","5.3 Deliberate and transparent limits",[10,1509,1510],{},"Rigor requires being precise about what zero-knowledge does and does not cover in our architecture:",[168,1512,1513,1519,1525,1531,1537],{},[71,1514,1161,1515,1518],{},[36,1516,1517],{},"title of a transfer or dataroom"," is not E2EE-encrypted (this is a design choice to allow display in the\ninterface and notifications).",[71,1520,1521,1524],{},[36,1522,1523],{},"File size"," is not encrypted (necessary for storage management).",[71,1526,1161,1527,1530],{},[36,1528,1529],{},"member list"," of a transfer or dataroom is not E2EE-encrypted (necessary for access management).",[71,1532,1533,1536],{},[36,1534,1535],{},"Connection metadata"," (IP address, date\u002Ftime) is collected for security purposes in our authentication system (\nKeycloak).",[71,1538,1539,1540,1542],{},"In a dataroom, a ",[437,1541,439],{}," hash of the file name is computed with a 256-bit random salt (CSPRNG) encrypted E2EE with\nthe dataroom session key. Only this hash is transmitted to the server for version management. The file name and the\nsalt remain inaccessible to the server in plaintext.",[10,1544,1545],{},"These limits are publicly documented on our transparency page. We prefer total transparency about our actual\ncapabilities over unverifiable claims.",[43,1547,1548],{},[10,1549,1550],{},"Although Retyc cannot restore lost access to a private encryption key, we recommend the use of enterprise password\nmanagers when registering critical accounts.",[10,1552,1553],{},[36,1554,1555],{},"Structural limits of E2EE in a web browser",[10,1557,1558],{},"Two fundamental limits, common to any encryption solution operating in a browser, should be explicitly acknowledged:",[68,1560,1561,1567],{},[71,1562,1563,1566],{},[36,1564,1565],{},"Public key substitution."," Retyc distributes recipients’ public keys via its servers. A sender trusts that\ndistribution. In the event of server compromise or internal abuse, an attacker could theoretically substitute a\npublic key.",[71,1568,1569,1572,1573,1576],{},[36,1570,1571],{},"Integrity of JavaScript code."," In a web context, the browser executes the encryption code delivered by the server\neach time a page is loaded. A compromise of the frontend code distribution server could therefore potentially affect\ncryptographic operations before they are executed. To limit this risk, Retyc applies a strict CSP that ",[36,1574,1575],{},"forbids\nexecution of any external script",": only scripts served directly by the Retyc frontend may run in the browser. No\nthird-party, inline, or externally hosted scripts are allowed. This measure removes injection vectors (XSS,\nthird-party supply chain), but does not protect against compromise of the original server itself (a limit inherent to\nany web-based E2EE model).",[10,1578,1579],{},"These two vectors are inherent to the web E2EE model and are recognized as such across the industry. They do not\nundermine the strength of the cryptographic model, but they must be taken into account in any assessment of residual\nrisk.",[40,1581],{},[29,1583,1585],{"id":1584},"_6-european-technological-independence","6. European technological independence",[157,1587,1589],{"id":1588},"_61-100-european-hosting","6.1 100% European hosting",[10,1591,1592,1593,1596],{},"All data processed by Retyc is hosted ",[36,1594,1595],{},"exclusively within the European Union",", with French providers subject to\nEuropean law:",[361,1598,1599,1612],{},[364,1600,1601],{},[367,1602,1603,1606,1609],{},[370,1604,1605],{},"Provider",[370,1607,1608],{},"Role",[370,1610,1611],{},"Location",[380,1613,1614,1625,1635],{},[367,1615,1616,1619,1622],{},[385,1617,1618],{},"Scaleway SAS",[385,1620,1621],{},"Application hosting, storage",[385,1623,1624],{},"France (EU)",[367,1626,1627,1630,1633],{},[385,1628,1629],{},"Clever Cloud SAS",[385,1631,1632],{},"Application hosting (Keycloak)",[385,1634,1624],{},[367,1636,1637,1640,1643],{},[385,1638,1639],{},"Brevo SAS",[385,1641,1642],{},"Transactional emails",[385,1644,1624],{},[10,1646,1647],{},"Stripe Inc. is used only for payment processing. Data sent to Stripe is limited to the information strictly necessary\nfor the transaction (amount, currency, customer identifier). No user content, file, or transfer metadata is communicated\nto Stripe. As a U.S. company, Stripe remains subject to the Cloud Act for this payment data — a residual exposure that\nis acknowledged and limited to that scope.",[157,1649,1651],{"id":1650},"_62-hosting-certifications","6.2 Hosting certifications",[10,1653,1654,1655,1658],{},"Scaleway and Clever Cloud are ",[36,1656,1657],{},"HDS"," (French Health Data Hosting) certified by bodies accredited by COFRAC.",[10,1660,1661],{},"These certifications attest to a high level of maturity in security and compliance among our infrastructure providers.",[10,1663,1664,1667],{},[36,1665,1666],{},"Retyc itself is not HDS or ISO 27001 certified",". By choosing infrastructure providers subject to these demanding\nframeworks, we provide our customers with a high level of maturity across the hosting chain. Future evolutions of our\narchitecture and processes may lead us, where appropriate, to consider suitable certification initiatives.",[157,1669,1671],{"id":1670},"_63-replication-and-high-availability","6.3 Replication and high availability",[10,1673,1674,1675,1678],{},"Your data (sent files) is ",[36,1676,1677],{},"automatically replicated across three European availability zones"," (Scaleway).\nThis architecture ensures:",[168,1680,1681,1684,1687],{},[71,1682,1683],{},"High availability",[71,1685,1686],{},"Resilience against failure of a data center.",[71,1688,1689],{},"No single point of failure at the file storage level.",[157,1691,1693],{"id":1692},"_64-independence-from-big-tech","6.4 Independence from Big Tech",[43,1695,1696],{},[10,1697,1698,1699,1702,1703,1706],{},"Some solutions mistakenly equate data location with legal protection. Hosting data in a data center located in France\nor Europe through companies subject to ",[36,1700,1701],{},"extraterritorial legislation"," (notably U.S. legislation) does not guarantee\nthe absence of exposure to those jurisdictions.\nThis confusion can lead to ",[36,1704,1705],{},"overestimating the actual level of protection"," provided.",[10,1708,1709,1710,1713],{},"Retyc uses ",[36,1711,1712],{},"no hosting or infrastructure service from U.S. platforms"," (such as Google Cloud, Amazon Web Services, or\nMicrosoft Azure). All user data is hosted exclusively with European operators. Stripe Inc. (U.S.) is used only for\npayment processing (no content data is stored or hosted there).",[10,1715,1716,1717,1719],{},"This independence is not merely ideological: it significantly reduces exposure to extraterritorial risks.\nThe ",[36,1718,215],{}," (2018) compels U.S. companies to provide U.S. authorities with the data they host, including data\nbelonging to European customers, regardless of where it is stored. By choosing an exclusively European infrastructure,\nRetyc significantly reduces the risks linked to such extraterritorial legislation.",[10,1721,1722],{},"This distinction between physical location and applicable jurisdiction is often misunderstood,\nincluding in commercial communications.",[157,1724,1726],{"id":1725},"_65-decision-making-sovereignty","6.5 Decision-making sovereignty",[10,1728,1729],{},"TripleStack SAS is an independent French company, with no foreign shareholders and no dependence on international\ngroups. Decisions regarding architecture, security, and data management are made in France, under the exclusive\nframework of European law.",[40,1731],{},[29,1733,1735],{"id":1734},"_7-features-file-transfer-and-datarooms","7. Features: file transfer and datarooms",[157,1737,1739],{"id":1738},"_71-secure-file-transfer","7.1 Secure file transfer",[10,1741,1742],{},"Retyc’s file transfer is designed to combine ease of use with maximum security.",[10,1744,1745],{},[36,1746,1747],{},"Transfer process:",[68,1749,1750,1756,1762,1768],{},[71,1751,1752,1755],{},[36,1753,1754],{},"Automatic encryption",": the user drags and drops files into the interface. Upon confirmation, the files are\nencrypted locally in the browser with the public keys of the authorized recipients.",[71,1757,1758,1761],{},[36,1759,1760],{},"Generation of a secure link",": a unique link is generated instantly. Only the authorized recipient or recipients\ncan decrypt and access the encrypted content.",[71,1763,1764,1767],{},[36,1765,1766],{},"Secure download",": the recipient downloads and decrypts the file directly in their browser.\nNo software installation is required.",[71,1769,1770,1773],{},[36,1771,1772],{},"Automatic expiration",": the link expires automatically after the configured period. The files are permanently\ndeleted.",[10,1775,1776],{},[36,1777,1778],{},"Control features:",[168,1780,1781,1784,1787,1790,1793],{},[71,1782,1783],{},"Configurable transfer expiration",[71,1785,1786],{},"Optional password protection for recipients without an account",[71,1788,1789],{},"Access revocation at any time (link deactivation)",[71,1791,1792],{},"File reception: generation of links allowing third parties to send documents directly into your secure space",[71,1794,1795],{},"Ability to generate custom file collection forms",[10,1797,1798],{},[36,1799,1800],{},"Compatibility:",[168,1802,1803,1806,1809,1815],{},[71,1804,1805],{},"Works from any modern web browser",[71,1807,1808],{},"Support for all file types, including large files",[71,1810,1811,1814],{},[36,1812,1813],{},"No restriction on file type",": files are processed without filtering or format-based restrictions.",[71,1816,1817],{},"No installation required for recipients",[157,1819,1821],{"id":1820},"_72-encrypted-collaborative-datarooms","7.2 Encrypted collaborative datarooms",[10,1823,1824],{},"Retyc datarooms are secure collaborative spaces designed to centralize and manage confidential documents with teams or\nexternal partners. Unlike traditional shared storage solutions, security is not handled only through access control\nlists (ACLs) on a server,\nbut through encryption itself.",[10,1826,1827],{},[36,1828,1829],{},"Dataroom security architecture:",[168,1831,1832,1838,1844,1850,1856],{},[71,1833,1834,1837],{},[36,1835,1836],{},"Cryptographic isolation",": each dataroom is cryptographically isolated from the others",[71,1839,1840,1843],{},[36,1841,1842],{},"User-level cryptographic access management",": each dataroom relies on its own cryptographic isolation, and access to\nsession keys is managed individually for each authorized user.",[71,1845,1846,1849],{},[36,1847,1848],{},"Zero Retyc access",": we cannot read documents or file names stored in a dataroom.",[71,1851,1852,1855],{},[36,1853,1854],{},"Cryptographic rekey",": when a member is added or removed, an administrator can trigger re-encryption of the session\nkey for the exact list of authorized members. After this operation, a revoked member can no longer obtain the session\nkey from the server. This operation is at the administrator’s discretion and must be performed explicitly.",[71,1857,1858,1861],{},[36,1859,1860],{},"Access responsibility",": no \"break-glass\" access is maintained by Retyc. Data availability within a dataroom is\nensured by the multiplicity of authorized users: as long as one active member can access it, the data remains\navailable.",[10,1863,1864],{},[36,1865,1866],{},"Document management:",[168,1868,1869,1872,1878,1881],{},[71,1870,1871],{},"Centralized file organization and management",[71,1873,1874,1877],{},[36,1875,1876],{},"Automatic versioning",": each update creates a new version without overwriting previous ones. Full history and\nrestore capability",[71,1879,1880],{},"Version history management: view, restore, or delete",[71,1882,1883],{},"Integrated encrypted messaging",[10,1885,1886],{},[13,1887],{"alt":1888,"className":1889,"src":1890,"width":22},"Interface de gestion des versions dans une dataroom",[17,18,19,20],"\u002Fimg\u002Fwhitepaper\u002Fdataroom_versions.png",[10,1892,1893],{},[36,1894,1895],{},"Access management:",[168,1897,1898,1904,1907,1910],{},[71,1899,1900,1903],{},[36,1901,1902],{},"Granular role-based permissions",": read-only, document upload, full management per user",[71,1905,1906],{},"Invitation of internal collaborators (organization) and external users (guests)",[71,1908,1909],{},"Instant access revocation",[71,1911,1912],{},"Full activity log: all access, downloads, and modifications are tracked",[40,1914],{},[29,1916,1918],{"id":1917},"_8-operational-transparency","8. Operational transparency",[157,1920,1922],{"id":1921},"_81-open-source-cryptography","8.1 Open-source cryptography",[10,1924,1107,1925,1928,1929,1932],{},[1117,1926,1131],{"href":1129,"rel":1927},[1121],"\nlibrary for client-side encryption operations. This library is open source, and its source code is publicly available\nfor audit. The source code of the web application (frontend and backend) is not public, but the ",[36,1930,1931],{},"Retyc CLI is open\nsource"," and the underlying cryptographic primitives are as well.",[10,1934,1935],{},"This transparency regarding the cryptographic foundations makes independent verification possible: the library can be\ninspected and audited by third-party experts, which reinforces confidence in the claimed security properties.",[157,1937,1939],{"id":1938},"_82-public-transparency-page","8.2 Public transparency page",[10,1941,1942],{},"Retyc publishes a detailed transparency page on its website, accessible to everyone, which exhaustively documents:",[168,1944,1945,1948,1951],{},[71,1946,1947],{},"The complete list of cookies used and their purpose",[71,1949,1950],{},"The data stored in the user’s browser",[71,1952,1953],{},"Full details of all data stored in the database, its purpose, retention period, and level of encryption",[10,1955,1956],{},"This transparency about our practices is publicly accessible on our website.",[157,1958,1960],{"id":1959},"_83-zero-ai-policy","8.3 Zero AI policy",[10,1962,1709,1963,1966],{},[36,1964,1965],{},"no artificial intelligence in its product",": no generative AI, no AI-assisted features, and no content\nanalysis through machine-learning algorithms.",[10,1968,1969],{},"This deliberate choice responds to a demand from our professional users, for whom the use of their sensitive content to\ntrain AI models represents an unacceptable risk. At Retyc, your files are not used to train third-party models. This is\na product commitment that is further constrained by the very nature of our application: we cannot analyze content we\ncannot read.",[157,1971,1973],{"id":1972},"_84-external-security-audit","8.4 External security audit",[10,1975,1976],{},"Retyc integrates security audits carried out by independent third parties into its development process, covering in\nparticular cryptography, infrastructure, and penetration testing. Significant findings, as well as the fixes\nimplemented, are communicated transparently to our users.",[157,1978,1980],{"id":1979},"_85-vulnerability-disclosure","8.5 Vulnerability disclosure",[10,1982,1983,1984,1987,1988,1991,1992,1997],{},"Retyc takes security very seriously. Our ",[48,1985,1986],{},"responsible disclosure"," policy is accessible via the\n",[437,1989,1990],{},"\u002F.well-known\u002Fsecurity.txt"," file on our domain, in accordance with security community best practices\n(",[1117,1993,1996],{"href":1994,"rel":1995},"https:\u002F\u002Fdatatracker.ietf.org\u002Fdoc\u002Frfc9116\u002F",[1121],"RFC 9116",").\nAny discovered vulnerability must be reported according to the procedures described in that file.",[157,1999,2001],{"id":2000},"_86-open-source-tools-and-interoperability","8.6 Open-source tools and interoperability",[10,2003,2004],{},"Retyc also provides an open-source command-line interface (CLI), allowing interaction with the platform in an automated\nway or integrated into technical workflows.",[10,2006,2007,2008],{},"The CLI source code is available on our GitHub repository:\n",[1117,2009,2012],{"href":2010,"rel":2011},"https:\u002F\u002Fgithub.com\u002Fretyc\u002Fretyc-cli",[1121],"github.com\u002Fretyc\u002Fretyc-cli",[10,2014,2015],{},"This CLI is intended in particular for technical teams wishing to:",[168,2017,2018,2021,2024],{},[71,2019,2020],{},"automate file transfers",[71,2022,2023],{},"integrate Retyc into pipelines (CI\u002FCD, scripts, internal tools)",[71,2025,2026],{},"audit and control performed operations",[10,2028,2029],{},"The source code is public and auditable, as part of Retyc’s transparency and openness approach.",[40,2031],{},[29,2033,2035],{"id":2034},"_9-use-cases","9. Use cases",[157,2037,2039],{"id":2038},"_91-law-firms-and-legal-departments","9.1 Law firms and legal departments",[10,2041,2042],{},"Legal professionals are subject to professional secrecy obligations that cannot rely on simple contractual commitments.\nRetyc’s zero-knowledge architecture provides robust protection and reduces the risk of sensitive data leakage.",[10,2044,2045],{},[36,2046,2047],{},"Typical use cases:",[168,2049,2050,2053,2056,2059],{},[71,2051,2052],{},"Secure transmission of contracts, notarial deeds, and sensitive documents to clients.",[71,2054,2055],{},"Datarooms for M&A transactions, due diligence, and litigation management.",[71,2057,2058],{},"Secure collection of supporting documents without relying on unencrypted email.",[71,2060,2061],{},"Collaboration on cases with fellow counsel, experts, or external stakeholders.",[10,2063,2064,2067],{},[36,2065,2066],{},"Added value:"," the full activity log provides evidence of due diligence regarding confidentiality in the event of\nlitigation or regulatory review.",[157,2069,2071],{"id":2070},"_92-accounting-firms","9.2 Accounting firms",[10,2073,2074],{},"Financial data (financial statements, bank statements, payslips, tax filings) is among the most sensitive data\ncategories.\nSending it by email represents a major risk.",[10,2076,2077],{},[36,2078,2047],{},[168,2080,2081,2084,2087,2090],{},[71,2082,2083],{},"Secure collection of client accounting documents via a personalized unique link.",[71,2085,2086],{},"Encrypted sending of tax returns, payslips, and closing documents.",[71,2088,2089],{},"Datarooms for audits, due diligence, and firm transfers.",[71,2091,2092],{},"Collaboration with peers or experts on complex cases.",[10,2094,2095,2097],{},[36,2096,2066],{}," client document collection through a unique link replaces unsecured email\nfor day-to-day exchanges. Centralizing documents in secure datarooms facilitates document management and traceability.",[157,2099,2101],{"id":2100},"_93-technical-and-engineering-teams","9.3 Technical and engineering teams",[10,2103,2104],{},"Technical teams regularly handle highly sensitive information: API keys, database dumps, security reports, intellectual\nproperty.",[10,2106,2107],{},[36,2108,2047],{},[168,2110,2111,2114,2117],{},[71,2112,2113],{},"Secure sharing of penetration test reports and security audits.",[71,2115,2116],{},"Transmission of configuration files containing secrets.",[71,2118,2119],{},"Datarooms for confidential project documentation.",[10,2121,2122,2124],{},[36,2123,2066],{}," independence from Big Tech providers meets the security expectations of the most demanding\norganizations.",[157,2126,2128],{"id":2127},"_94-companies-and-regulated-sectors","9.4 Companies and regulated sectors",[10,2130,2131],{},"For organizations subject to NIS2, DORA, or sector-specific regulations, Retyc can help address certain security and\nconfidentiality requirements, particularly regarding encryption of data in transit and at rest, access traceability, and\nindependence from extraterritorial providers.",[43,2133,2134],{},[10,2135,2136,2138],{},[36,2137,375],{}," — Retyc is an encrypted transfer and collaboration tool. It does not cover all NIS2 or DORA requirements (\ngovernance, resilience testing, ICT provider register, etc.). Its adoption should form part of a broader compliance\neffort led by the organization.",[10,2140,2141],{},[36,2142,2047],{},[168,2144,2145,2148,2151],{},[71,2146,2147],{},"Exchange of confidential documents with partners, service providers, or regulators.",[71,2149,2150],{},"Datarooms for sensitive HR processes (contracts, evaluations).",[71,2152,2153],{},"Secure transmission of data in due diligence processes or calls for tender.",[10,2155,2156,2158],{},[36,2157,2066],{}," depending on the selected plan, Retyc can integrate SSO (SAML\u002FOIDC), custom branding, and on-premises\ndeployment for organizations with specific integration requirements.",[40,2160],{},[29,2162,2164],{"id":2163},"_10-plans-and-deployment","10. Plans and deployment",[157,2166,2168],{"id":2167},"_101-freemium-model-with-progressive-plans","10.1 Freemium model with progressive plans",[10,2170,2171],{},"Retyc offers four plan levels allowing every organization to start for free and scale according to its needs:",[361,2173,2174,2192],{},[364,2175,2176],{},[367,2177,2178,2180,2183,2186,2189],{},[370,2179],{},[370,2181,2182],{},"Free",[370,2184,2185],{},"Solo",[370,2187,2188],{},"Business",[370,2190,2191],{},"Enterprise",[380,2193,2194,2210,2223,2236,2251,2272,2284,2298,2311,2324],{},[367,2195,2196,2199,2202,2205,2207],{},[385,2197,2198],{},"Outbound transfers",[385,2200,2201],{},"Limited",[385,2203,2204],{},"Extended",[385,2206,2204],{},[385,2208,2209],{},"Customized",[367,2211,2212,2215,2217,2219,2221],{},[385,2213,2214],{},"File reception",[385,2216,395],{},[385,2218,395],{},[385,2220,395],{},[385,2222,395],{},[367,2224,2225,2228,2230,2232,2234],{},[385,2226,2227],{},"Datarooms",[385,2229,395],{},[385,2231,395],{},[385,2233,395],{},[385,2235,2209],{},[367,2237,2238,2241,2244,2246,2249],{},[385,2239,2240],{},"Internal members per dataroom",[385,2242,2243],{},"—",[385,2245,2243],{},[385,2247,2248],{},"Unlimited",[385,2250,2248],{},[367,2252,2253,2256,2260,2264,2268],{},[385,2254,2255],{},"E2EE encryption",[385,2257,2258],{},[36,2259,395],{},[385,2261,2262],{},[36,2263,395],{},[385,2265,2266],{},[36,2267,395],{},[385,2269,2270],{},[36,2271,395],{},[367,2273,2274,2276,2278,2280,2282],{},[385,2275,1206],{},[385,2277,395],{},[385,2279,395],{},[385,2281,395],{},[385,2283,395],{},[367,2285,2286,2289,2291,2293,2296],{},[385,2287,2288],{},"SSO (SAML\u002FOIDC)",[385,2290,409],{},[385,2292,409],{},[385,2294,2295],{},"On request",[385,2297,395],{},[367,2299,2300,2303,2305,2307,2309],{},[385,2301,2302],{},"Premium support",[385,2304,409],{},[385,2306,409],{},[385,2308,409],{},[385,2310,395],{},[367,2312,2313,2316,2318,2320,2322],{},[385,2314,2315],{},"Custom domain",[385,2317,409],{},[385,2319,409],{},[385,2321,409],{},[385,2323,395],{},[367,2325,2326,2329,2331,2333,2335],{},[385,2327,2328],{},"On-premises deployment",[385,2330,409],{},[385,2332,409],{},[385,2334,409],{},[385,2336,395],{},[10,2338,2339,2340,124],{},"Details of each plan are available on our website: ",[1117,2341,2344],{"href":2342,"rel":2343},"https:\u002F\u002Fretyc.com\u002Ffr\u002Fpricing",[1121],"retyc.com\u002Ffr\u002Fpricing",[43,2346,2347],{},[10,2348,2349,2350,124],{},"End-to-end encryption and key rotation are available on ",[36,2351,2352],{},"all plans, including Free",[157,2354,2356],{"id":2355},"_102-saas-deployment","10.2 SaaS deployment",[10,2358,2359],{},"The standard Retyc deployment model is SaaS (Software as a Service): no client-side installation, accessible from any\nmodern browser. The entire infrastructure is managed by Retyc and hosted by European providers.",[157,2361,2363],{"id":2362},"_103-on-premises-deployment-enterprise","10.3 On-premises deployment (Enterprise)",[10,2365,2366,2367,2370],{},"For organizations with regulatory or security constraints requiring data to remain within their own infrastructure,\nRetyc offers ",[36,2368,2369],{},"on-premises deployment"," as part of the Enterprise plan.",[10,2372,2373],{},"This deployment model allows the customer organization to run the entire Retyc platform on its own infrastructure while\nmaintaining full control over its data.",[157,2375,2377],{"id":2376},"_104-advanced-integrations","10.4 Advanced integrations",[10,2379,2380],{},"The Enterprise plan includes the possibility of custom integrations, including:",[168,2382,2383,2389,2395],{},[71,2384,2385,2388],{},[36,2386,2387],{},"SAML\u002FOIDC SSO",": integration with the existing enterprise directory (Active Directory, Okta, etc.).",[71,2390,2391,2394],{},[36,2392,2393],{},"Custom branding",": adapting the interface to the organization’s colors and logo.",[71,2396,2397,2399],{},[36,2398,2315],{},": access through your own domain name.",[40,2401],{},[29,2403,2405],{"id":2404},"_11-conclusion","11. Conclusion",[10,2407,2408],{},"Faced with growing cybersecurity, independence, and regulatory compliance challenges, European organizations need file\ntransfer solutions that provide stronger security and do not rely solely on contractual commitments.",[10,2410,2411],{},"Retyc provides that guarantee by combining:",[168,2413,2414,2420,2426,2432],{},[71,2415,2416,2419],{},[36,2417,2418],{},"End-to-end encryption",": your files are unreadable on our servers, today and against future threats (hybrid scheme\nintegrating mechanisms resistant to currently known quantum threats).",[71,2421,2422,2425],{},[36,2423,2424],{},"Zero-knowledge architecture",": without decryption keys, we cannot access your content in plaintext.",[71,2427,2428,2431],{},[36,2429,2430],{},"Exclusively European infrastructure",": hosting in France on European infrastructure, with very limited direct\nexposure to extraterritorial legislation.",[71,2433,2434,2437],{},[36,2435,2436],{},"Full transparency",": auditable open-source cryptography, public documentation of our practices, and honesty about\nthe limits of our architecture.",[10,2439,2440],{},"Retyc is developed and operated by TripleStack SAS, an independent French company. Our mission is to provide\norganizations and professionals with a European, transparent, and technically rigorous alternative for handling\nsensitive content.",[40,2442],{},[29,2444,2446],{"id":2445},"contact","Contact",[10,2448,2449],{},[36,2450,2451],{},"TripleStack SAS - Retyc",[168,2453,2454,2462,2467,2474],{},[71,2455,2456,2457],{},"Website: ",[1117,2458,2461],{"href":2459,"rel":2460},"https:\u002F\u002Fretyc.com\u002Ffr",[1121],"retyc.com",[71,2463,2464,2465],{},"Security contact: see ",[437,2466,1990],{},[71,2468,2469,2470],{},"GDPR \u002F DPO contact: ",[1117,2471,2473],{"href":2472},"mailto:privacy@retyc.net","privacy@retyc.net",[71,2475,2476,2477],{},"Sales contact: via ",[1117,2478,2481],{"href":2479,"rel":2480},"https:\u002F\u002Fretyc.com\u002Ffr\u002Fabout\u002Fcontact-us",[1121],"retyc.com\u002Fabout\u002Fcontact-us",[40,2483],{},[10,2485,2486],{},[48,2487,2488],{},"This document is provided for informational purposes only. The information it contains reflects the state of the\nplatform at the time of writing. Retyc reserves the right to evolve its architecture and features. The current version\nof the privacy policies and terms of use is the one published on retyc.com.",[10,2490,2491],{},[48,2492,2493],{},"— TripleStack SAS, April 2026",{"title":2495,"searchDepth":2496,"depth":2496,"links":2497},"",2,[2498,2499,2500,2501,2507,2515,2522,2527,2534,2538,2546,2552,2558,2559],{"id":31,"depth":2496,"text":32},{"id":65,"depth":2496,"text":66},{"id":108,"depth":2496,"text":109},{"id":154,"depth":2496,"text":155,"children":2502},[2503,2505,2506],{"id":159,"depth":2504,"text":160},3,{"id":190,"depth":2504,"text":191},{"id":239,"depth":2504,"text":240},{"id":282,"depth":2496,"text":283,"children":2508},[2509,2510,2511,2512,2513,2514],{"id":294,"depth":2504,"text":295},{"id":311,"depth":2504,"text":312},{"id":355,"depth":2504,"text":356},{"id":555,"depth":2504,"text":556},{"id":858,"depth":2504,"text":859},{"id":973,"depth":2504,"text":974},{"id":1049,"depth":2496,"text":1050,"children":2516},[2517,2518,2519,2520,2521],{"id":1053,"depth":2504,"text":1054},{"id":1103,"depth":2504,"text":1104},{"id":1154,"depth":2504,"text":1155},{"id":1183,"depth":2504,"text":1184},{"id":1228,"depth":2504,"text":1229},{"id":1432,"depth":2496,"text":1433,"children":2523},[2524,2525,2526],{"id":1436,"depth":2504,"text":1437},{"id":1473,"depth":2504,"text":1474},{"id":1506,"depth":2504,"text":1507},{"id":1584,"depth":2496,"text":1585,"children":2528},[2529,2530,2531,2532,2533],{"id":1588,"depth":2504,"text":1589},{"id":1650,"depth":2504,"text":1651},{"id":1670,"depth":2504,"text":1671},{"id":1692,"depth":2504,"text":1693},{"id":1725,"depth":2504,"text":1726},{"id":1734,"depth":2496,"text":1735,"children":2535},[2536,2537],{"id":1738,"depth":2504,"text":1739},{"id":1820,"depth":2504,"text":1821},{"id":1917,"depth":2496,"text":1918,"children":2539},[2540,2541,2542,2543,2544,2545],{"id":1921,"depth":2504,"text":1922},{"id":1938,"depth":2504,"text":1939},{"id":1959,"depth":2504,"text":1960},{"id":1972,"depth":2504,"text":1973},{"id":1979,"depth":2504,"text":1980},{"id":2000,"depth":2504,"text":2001},{"id":2034,"depth":2496,"text":2035,"children":2547},[2548,2549,2550,2551],{"id":2038,"depth":2504,"text":2039},{"id":2070,"depth":2504,"text":2071},{"id":2100,"depth":2504,"text":2101},{"id":2127,"depth":2504,"text":2128},{"id":2163,"depth":2496,"text":2164,"children":2553},[2554,2555,2556,2557],{"id":2167,"depth":2504,"text":2168},{"id":2355,"depth":2504,"text":2356},{"id":2362,"depth":2504,"text":2363},{"id":2376,"depth":2504,"text":2377},{"id":2404,"depth":2496,"text":2405},{"id":2445,"depth":2496,"text":2446},"The Retyc white paper provides an in-depth analysis of its technical architecture and security model in the context of European regulatory requirements.","md",{},true,"\u002Fen\u002Fresources\u002Fwhite-paper",{"ogTitle":2566,"ogDescription":2567,"title":5,"description":2560},"Retyc White Paper","An in-depth analysis of Retyc's technical architecture and security model in the context of European regulatory requirements.","en\u002Fresources\u002Fwhite-paper","MNg_DpcGhQl6MshiS3kioNsGZDHWxeTGF737iiLvzL0",1776849616328]