An email encryption method supporting anti-quantum cryptography migration

Abstract

The application discloses an email encryption method supporting anti-quantum password migration, and relates to the technical field of network space security and application cryptography, wherein the method comprises the following steps: selecting an encryption granularity according to the certificate state of a receiver and the sensitivity of an email, and generating a session key; then, based on the anti-quantum public key of the receiver, the session key is independently encapsulated and assembled into the email load; at the same time, the public key signature authentication and the certificate expiration prompt are completed through a domestic public key cryptography algorithm, and the feedback state is fed back to the encapsulation link; the session key is extracted by using the anti-quantum private key, the email body and the attachment are decrypted, and the whole process closed loop of sending and receiving is realized. Through the cooperation of hierarchical encryption, key encapsulation, certificate control and front-end operation, the application realizes end-to-end anti-quantum email encryption, and solves the risks of certificate invalidation and plaintext leakage.

Description

Technical Field

[0001] This invention relates to the fields of cyberspace security and applied cryptography, and in particular to an email encryption method that supports quantum-resistant cryptographic migration. Background Technology

[0002] Cryptography is a core foundational technology for building network information security protection systems, and it is now widely used in various information exchange scenarios such as email encryption, network identity authentication, electronic digital signatures, and data integrity verification. With the continuous development and gradual practical application of quantum computing technology, the security foundation of traditional public-key cryptography is severely impacted. The risk of quantum-based cracking is gradually infiltrating various network communication services, leading to a continuous increase in demand across industries for quantum-resistant email transmission systems and encrypted interaction platforms.

[0003] Against the backdrop of the deepening national strategy for cryptographic application security, end-to-end encryption technology has become a crucial infrastructure for ensuring the stable operation of the digital economy and supporting the secure conduct of core businesses such as government offices and commercial transactions. Currently, the global cybersecurity situation is becoming increasingly complex and severe, with frequent cybersecurity incidents such as data breaches, man-in-the-middle attacks, and illegal eavesdropping. Email, as a high-frequency communication medium, faces multiple threats to data security during transmission. Existing mainstream commercial email systems and traditional email clients have many inherent defects. Most products have failed to implement quantum-resistant encryption capabilities on the browser front end, making it difficult to effectively resist new security threats brought about by quantum computing. Furthermore, existing devices generally lack functions such as encryption parameter debugging and visualization of the computation process. The encryption operation logic is relatively abstract, making it difficult for users to intuitively understand the encryption principles and execution process, which reduces product usability and hinders the widespread adoption of quantum-resistant encryption technology.

[0004] Existing email encryption technologies still suffer from incomplete architecture and insufficient process integration. Firstly, current systems only monitor basic sending data such as delivery rate and transmission failure rate, without feeding back the monitoring results to the encryption hierarchy control logic. This prevents the formation of a data-driven, dynamic encryption loop and makes it difficult to adaptively adjust encryption strategies based on the recipient's certificate status in real time. This can lead to email delivery failures due to recipient certificate anomalies or security vulnerabilities caused by ignoring certificate risks and transmitting emails in plaintext. Secondly, while some existing solutions can dynamically adjust key length, they rely on static certificates to build a trust system, which cannot meet the quantum cryptography upgrade requirements of enterprise-level email systems. This can lead users to adopt a single-algorithm mindset and hinder the establishment of a systematic, full-lifecycle key governance capability. Thirdly, traditional email services primarily focus on transport layer security, failing to achieve true end-to-end encrypted processing and lacking independent encryption capabilities for email attachments. Mainstream encrypted email plugins on the market have limited functionality and cannot simultaneously cover diverse business scenarios such as email body encryption, attachment encryption, and secure key distribution, making it difficult to meet the complex application needs of government and finance sectors. At the same time, existing encrypted email platforms tend to be simplified, mostly used only as basic algorithm demonstration tools or simple encryption components. They cannot simulate real and complex business scenarios such as government cloud deployment and financial approval data protection. Users find it difficult to build a complete communication trust system on existing platforms, and they also cannot meet the practical application requirements of various enterprises and institutions to counter quantum email encryption capabilities.

[0005] From the perspective of operational mechanisms and user experience, traditional encryption architectures lack independent isolated computation paths designed for browser runtime environments. Functional designs such as key reuse and local encryption / decryption are flawed, and they generally lack robust access control systems, making it difficult to achieve multi-role hierarchical management and operational behavior isolation. Furthermore, email attachments lack standardized ciphertext marking and traceability mechanisms after decryption, failing to guarantee auditability and traceability throughout the entire ciphertext lifecycle. In addition, existing technologies lack visual interactive design, failing to introduce interactive mechanisms such as certificate status indicators, encapsulation efficiency statistics, and quick switching between encryption modes. This hinders the effective improvement of user willingness to perform encryption operations and overall ciphertext coverage. Enterprises often need to invest significant manpower and time in training personnel, thus restricting the overall operational efficiency of the industry.

[0006] With the continuous improvement of high-performance computing capabilities on browsers and the ongoing optimization and iteration of quantum-resistant cryptographic algorithms, it is now technically feasible to build a highly realistic, end-to-end quantum-resistant encrypted email runtime environment within the browser. While some fragmented functionalities such as encryption mode guidance, certificate status monitoring, and multi-dimensional data dashboards have emerged in the industry, they have not integrated various technical capabilities, nor have they constructed a complete technical architecture that integrates encryption strategy selection, key encapsulation and distribution, certificate trusted authentication, and front-end encryption / decryption execution. This fails to address the multiple usage requirements, including communication security, dynamic policy adjustment, trust chain verification, and visual interaction.

[0007] In summary, existing email encryption technologies have significant shortcomings in areas such as quantum-resistant security, dynamic encryption loop construction, certificate trust system governance, front-end visual interaction, and multi-scenario business adaptation. There is an urgent need to build an integrated quantum-resistant email encryption transmission system. Summary of the Invention

[0008] The main objective of this invention is to provide an email encryption method that supports quantum cryptographic migration resistance.

[0009] Another object of the present invention is to provide an electronic device.

[0010] A third objective of this invention is to provide a non-transitory computer-readable storage medium.

[0011] To achieve the above objectives, a first aspect of the present invention provides an email encryption method supporting quantum-resistant cryptographic transfer, comprising:

[0012] Based on the recipient's certificate status and email sensitivity, select the encryption granularity from a variety of preset encryption modes and generate a session key; Based on the recipient's quantum-resistant public key, the session key is encapsulated in a quantum-resistant manner, generating an independent encapsulation segment for each recipient, and assembling all encapsulation segments into the email payload; Based on domestic public-key cryptography algorithms, the system performs signature authentication using quantum-resistant public keys, monitors certificate expiration status, generates renewal reminders before certificate expiration, and feeds back authentication results and reminder information to the quantum-resistant encapsulation step. By using a quantum-resistant private key to decapsulate the encapsulated segment within the email payload, extract the session key, and decrypt the email body and attachments based on the session key, a closed loop for the entire process of local storage and sending / receiving of encrypted emails is achieved.

[0013] Optionally, based on the recipient's certificate status and email sensitivity, the encryption granularity can be selected from a variety of preset encryption modes, and a session key can be generated, including: Read the user's encryption preferences and combine them with four preset modes to determine the encryption granularity: no encryption, encryption of only the body text, encryption of only the attachments, and encryption of both the body text and attachments. By combining the recipient's certificate status, historical encryption preference data, and keywords in the email subject, the sensitivity level is calculated. When the email is determined to be highly sensitive, it is automatically locked to the encryption mode of both the body and attachments. When there is uncertainty in the determination, the user can manually confirm the encryption mode in the preview interface. Based on the final determined encryption granularity, a session key is generated in accordance with the specifications of domestic block cipher algorithms.

[0014] Optionally, after generating the session key, perform the encryption preview and context fixation steps, specifically including: The system retrieves the determined encryption mode and session key, displays information including ciphertext fragments, encapsulation length, and the size of the encrypted attachment in the encryption preview interface, and supports online switching of encryption modes and real-time updates of preview content. After the user confirms the encryption configuration, an encryption context containing the encryption mode, session key identifier, recipient certificate information, sensitivity marker and timestamp is generated and cached locally in the browser; It monitors the browser's running status in real time, and automatically retrieves the local cached encryption context when an unexpected page refresh is detected, restoring email editing and encryption configuration; The system responds to user commands by uploading the encrypted text and encryption context digest to the server. The server stores the emails and updates the ledger, synchronously refreshing the encrypted statistics dashboard. It also supports users in exporting the encryption context for subsequent auditing.

[0015] Optionally, based on the recipient's quantum-resistant public key, the session key is quantum-resistant encapsulated, generating an independent encapsulation segment for each recipient, and assembling all encapsulation segments into the email payload, including: Read the generated session key and certificate information of all recipients to obtain the valid quantum-resistant public key for each recipient; The recipient list is sorted based on three weighting factors: protocol correctness, encapsulation latency, and concurrency efficiency. The encapsulation priority is dynamically adjusted based on the certificate expiration time, prioritizing recipients whose certificates are about to expire. Using each recipient's quantum-resistant public key, quantum-resistant encapsulation is performed on the same session key separately, generating an independent encapsulation segment for each recipient, and recording the encapsulation time and running status; Perform integrity checks on each encapsulated segment, verifying whether the format, length, and algorithm identifier conform to the specifications. If the check fails, trigger re-encapsulation or generate an error report. All verified encapsulation segments are integrated and written into the email payload according to the standard format. At the same time, the encapsulation time data is sent back to the management and monitoring dashboard.

[0016] Optionally, after assembling all encapsulation segments into the email payload, perform encapsulation payload verification and anomaly warning steps, specifically including: Parse the encapsulation segment set in the email payload, extract information including algorithm parameters, ciphertext length, and encapsulation metadata, and verify the matching of the encapsulation segment structure with the algorithm item by item; A corresponding report is generated based on the verification results. When the verification fails, the abnormal recipient, error type, and repair suggestions are marked and pushed to the front-end interface and the administrator review queue. Real-time monitoring of metrics including attachment size and encapsulation operation status; when attachments exceed limits or encapsulation fails, logs containing email information, exception type, recipient list, and an alert are issued. All encapsulation segment metadata and verification reports are persistently stored in the encapsulation segment metadata table in the device storage layer.

[0017] Optionally, based on domestically developed public-key cryptography algorithms, signature authentication is performed using quantum-resistant public keys, and the certificate expiration status is monitored. A renewal reminder is generated before the certificate expires, and the authentication result and reminder information are fed back to the quantum-resistant encapsulation step, including: When a user login or active key pair update is detected, the user’s latest quantum-resistant public key is retrieved, the domestic public key cryptography algorithm completes the digital signature, generates a standard digital certificate and enters it into the certificate ledger. The system periodically checks existing certificates through scheduled tasks, identifies certificates nearing their expiration date, and pushes renewal notifications at dynamically adjusted reminder intervals. Multiple channels are used to display expiration reminders to users until they complete key renewal and certificate re-signing. It provides a visual interface for certificate verification, supporting manual comparison and verification of public keys, signature values, and public key fingerprints.

[0018] Optionally, the authentication results and reminder information can be fed back to the quantum-resistant encapsulation step, which is achieved through certificate state-driven encapsulation scheduling optimization, specifically including: Summarize certificate signature authentication results and expiration reminder status to construct a certificate profile that includes public key fingerprint, serial number, validity period, and running status; A visual heatmap is used to distinguish between three categories of certificates: revoked, about to expire, and in normal status, providing an intuitive display of the distribution status of certificates across the entire network. Real-time monitoring of status change events, including certificate issuance, revocation, expiration, and renewal, and synchronization of change information to the key encapsulation stage; Adjust the encapsulation and distribution queue according to the latest certificate status, remove recipients whose certificates have expired and trigger alarms, and increase the encapsulation priority of recipients with near-expiration certificates. Before each encapsulation process, the latest certificate status data is retrieved to ensure that the key encapsulation process is executed based on a trusted certificate link.

[0019] Optionally, the encapsulated segment within the email payload is decapsulated using a quantum-resistant private key to extract the session key, and the email body and attachments are decrypted based on the session key, including: The recipient's quantum-resistant private key is loaded in the browser and cached in the current session's memory after being protected by the user's login password; Parse the encapsulation segment within the email payload, perform the decapsulation operation using the local private key, extract the session key if decapsulation is successful, and push an error message if decapsulation fails. The domestically developed block cipher algorithm was invoked, and the extracted session key was used to decrypt the email body and attachments respectively, restoring the plaintext data. Before and after decryption, the ciphertext boundaries, encoding format and data length are checked. If the check is abnormal, the decryption is terminated and an integrity alarm is issued. The session key is cached within the current browser session. When decrypting multiple attachments of the same email, the key is automatically reused, and the key usage trajectory and lifecycle are recorded. The decrypted email data is stored locally, linking the entire process of encryption, encapsulation, transmission, decapsulation, and decryption to form a complete closed loop for sending and receiving emails.

[0020] To achieve the above objectives, a second aspect of this application provides an electronic device, including a processor and a memory; wherein the processor runs a program corresponding to the executable program code stored in the memory, for implementing an email encryption method supporting quantum-resistant cryptographic migration as described in the first aspect embodiment.

[0021] To achieve the above objectives, a third aspect of this application provides a non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements an email encryption method supporting quantum-resistant cryptographic migration as described in the first aspect embodiment.

[0022] The embodiments of the present invention have the following beneficial effects: 1. This invention constructs a four-level collaborative business architecture of hierarchical encryption, key encapsulation, certificate authentication, and front-end execution, breaking the existing one-way fixed "switch-type" encryption mode. It supports users to configure the encryption granularity, generates standardized encryption contexts by combining encryption matrix algorithms, and optimizes the interactive experience based on certificate status feedback and quantum-resistant encapsulation segment real-time splicing mechanism. It effectively adapts to complex email encryption scenarios such as government cloud and improves the end-to-end encrypted transmission closed loop.

[0023] 2. This invention optimizes the key distribution logic for multiple recipients, and completes the entire process of key derivation, quantum-resistant encapsulation, and encapsulation segment assembly in parallel based on a concurrent processing mechanism. While ensuring the encryption security of multi-recipient mass distribution scenarios, it intuitively presents the correlation between the number of recipients and the encryption time, helping users to establish a systematic cryptographic engineering mindset.

[0024] 3. This invention adds a full-cycle certificate management mechanism, which routinely checks the certificate ledger through scheduled tasks and pushes structured renewal reminders for certificates nearing expiration, effectively improving the certificate renewal reach rate and avoiding email communication security vulnerabilities caused by certificate expiration; at the same time, it realizes full-domain monitoring of certificate status based on a visualized heat map, supports administrators to dynamically adjust key rotation strategies, and forms a complete trust management closed loop of certificate issuance, status monitoring, and expiration renewal.

[0025] 4. This invention completes all encryption and decryption operations on the browser side, and with the ciphertext attachment marking and metadata management mechanism, it achieves accurate identification and full-link traceability of ciphertext attachments. Combined with domestic public key cryptography algorithms, it completes trusted signature verification. The modular functions work together to build a solid communication security defense line, avoid the risk of plaintext email exposure from the business architecture level, and build a sustainable quantum-resistant email encryption ecosystem. Attached Figure Description

[0026] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating an email encryption method supporting quantum-resistant cryptographic migration, provided as an embodiment of the present invention; Figure 2 A schematic diagram of the overall architecture of an email encryption system supporting quantum-resistant cryptographic migration is provided for an embodiment of the present invention; Figure 3 This is a schematic diagram of the internal structure of the hierarchical encryption strategy module provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the hierarchical structure and governance process of the certificate authentication and issuance module provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the browser-side computing architecture of the client-side encryption / decryption execution module provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of an electronic device structure for performing an email encryption method, provided as an embodiment of the present invention. Detailed Implementation

[0027] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] The following describes an email encryption method supporting quantum-resistant cryptographic migration according to an embodiment of the present invention, with reference to the accompanying drawings.

[0030] Example 1 This invention provides an email encryption method that supports quantum cryptographic migration resistance. Figure 1 This is a schematic flowchart illustrating an email encryption method supporting quantum-resistant cryptographic transfer, provided as an embodiment of the present invention. Figure 1 As shown, the method includes the following steps: Step S1: Based on the recipient's certificate status and email sensitivity, select the encryption granularity from a variety of preset encryption modes and generate a session key.

[0031] In actual operation, the system will prioritize retrieving user operation logs and configuration files stored in the background over a long period of time, and read and parse the encryption preference records kept by users daily, using these as a basic reference. Combined with the four pre-configured encryption methods—no encryption, encryption of the body only, encryption of attachments only, and encryption of both the body and attachments—the system will initially define the appropriate encryption granularity for the email to be sent, ensuring that the encryption rules align with users' long-term usage habits.

[0032] To determine the email protection level, this application introduces an email sensitivity calculation model, integrating multiple types of related data to perform comprehensive calculations, ultimately yielding a quantifiable sensitivity value. The corresponding calculation expression is as follows:

[0033] in, This represents the overall sensitivity score of the email. The weighting coefficient for keywords in the email subject line; Assess the risk level of the topic keywords; The recipient's certificate status weighting coefficient; Score the validity status of the recipient's certificate; This is a weighting coefficient for historical encryption behavior; Rate users' historical encryption preferences. The values ​​range from 0 to 1, and the sum of the three is 1, thus ensuring that the weight allocation is reasonable and the calculation results are objective and valid.

[0034] Based on the calculated sensitivity level, differentiated encryption strategies are implemented to form a tiered protection mechanism. If an email is determined to be highly sensitive, indicating that the email content contains important information, the system will automatically lock the mode that encrypts both the body and attachments simultaneously, comprehensively ensuring data transmission security. If the sensitivity determination result is ambiguous or uncertain, and the optimal encryption scheme cannot be directly determined by the algorithm, an interactive prompt will pop up on the front-end encryption preview interface, allowing the user to manually confirm the encryption mode, thus balancing the flexibility of algorithmic judgment and human decision-making.

[0035] Once the encryption granularity is finalized, the encryption parameter generator strictly adheres to domestic block cipher algorithm specifications, automatically generating a unique session key according to predetermined algorithm logic and security standards. This key is the core key for this encrypted email transmission, possessing uniqueness and security. After determining the encryption configuration and session key, encryption preview and context fixation operations are initiated simultaneously. The front-end preview interface renders and generates the corresponding ciphertext fragments in real time, while also intuitively displaying reference information such as key encapsulation length and encrypted attachment size. Users can also switch between different encryption modes online according to their actual needs, and the interface display will refresh in real time, allowing users to intuitively compare different encryption effects.

[0036] After the user verifies all content and confirms all encryption configurations, the system integrates multiple key data types, including the currently selected encryption mode, unique session key identifier, certificate information for all recipients, email sensitivity markers, and operation timestamps, to generate a complete encryption context. This file is then cached in the browser's local storage to prevent temporary loss of configuration data. Throughout the email editing process, the system continuously monitors the browser's operation. If any anomalies are detected, such as unexpected page refreshes, page redirects, or process freezes / exits, the system automatically retrieves the locally cached encryption context, quickly restoring the email editing state and all previously set encryption parameters. This eliminates the need for users to reconfigure, improving operational convenience.

[0037] Once the user verifies the data and triggers the email send command, the front-end program uploads the processed ciphertext and encryption context digest to the corresponding server interface. Upon receiving the transmitted data, the back-end stores the entire email as is, simultaneously updating the email log to retain basic email data. Based on this, the platform continuously compiles and updates the site-wide encryption coverage data in real time. Using aggregation calculations, various statistical data are sorted in descending order from high to low, generating a management dashboard that supports multi-condition filtering and categorized viewing, facilitating overall control of encryption usage by administrators. The platform also provides users with an encryption context download channel; the encryption context file stored in the browser can be exported and saved locally for subsequent behavior tracing and security auditing. Furthermore, standardized encryption usage records are generated item by item from three core dimensions: encryption mode, number of recipients, and number of attachments, completely retaining the full-process operation log for each encrypted email, ensuring traceable and verifiable operation behavior.

[0038] Step S2: Based on the recipient's quantum-resistant public key, the session key is quantum-resistant encapsulated, generating an independent encapsulation segment for each recipient, and assembling all encapsulation segments into the email payload.

[0039] Before officially commencing key encapsulation, the generated session key is proactively retrieved and used as the core object for this encapsulation process. Simultaneously, digital certificate files for all recipients of this email are loaded in batches, initiating a certificate validity verification process to determine the status of each certificate individually. Certificates with a status indicating revocation or impending expiration are handled according to pre-defined security strategies. This can either remove the corresponding recipient from the key distribution queue to mitigate subsequent transmission risks, or push prominent risk alerts to the front-end interface, allowing users to promptly identify certificate anomalies.

[0040] This application employs a weighted sorting model to scientifically plan the processing order of recipients. It comprehensively considers three core weighting factors: protocol correctness, encapsulation latency, and concurrency efficiency. Simultaneously, it dynamically adjusts the encapsulation priority based on the remaining expiration time of each certificate. In batch processing tasks, encapsulation operations are prioritized for recipients whose certificates are about to expire, ensuring the overall reliability of the key distribution process. The weighted sorting calculation expression is as follows:

[0041] in, The overall processing priority score for the i-th recipient; Weights for protocol correctness; Assess the compliance score of the agreement for the i-th recipient; Weighting for encapsulation latency; To score the estimated packaging latency; Weighted for concurrency efficiency; The system scores the runtime efficiency in concurrent scenarios. This is a certificate validity adjustment factor; Scoring is based on the remaining validity period of the certificate. All are preset fixed coefficients.

[0042] Tasks are executed sequentially according to the calculated priority ranking. Based on the device's internal multi-dimensional encapsulation engine and concurrent encapsulation model, the valid quantum-resistant public key held by each recipient is retrieved. For the same session key, quantum-resistant encapsulation operations are performed separately for different recipients, ultimately generating independent encapsulation segments for each recipient. Throughout the encapsulation operation, the time consumed for each encapsulation and the current running status of the program are collected and recorded in real time, providing data support for subsequent operation and maintenance statistics and performance optimization.

[0043] Once a single encapsulation segment is generated, the encapsulation segment assembler immediately initiates integrity verification, checking data encoding format, overall byte length, cryptographic algorithm identifiers, and other parameters to determine if they strictly conform to the established technical specifications. If any data anomalies or format errors are detected during verification, a secondary encapsulation process is automatically triggered to regenerate the encapsulation segment. If the problem persists after multiple retries, a standardized error report with specified content is automatically generated, and the fault information is stored. All encapsulation segments that successfully pass integrity verification are centrally integrated and organized, strictly adhering to the format requirements of the established communication protocol, and uniformly written into the email payload. The time consumption statistics for each encapsulation segment are also transmitted back to the backend management monitoring dashboard in real time, enabling a visual display of encapsulation performance data.

[0044] After completing the assembly and writing of all encapsulation segments, the encapsulation payload verification and anomaly warning process is initiated. First, all encapsulation segments within the email payload are comprehensively analyzed, extracting key information such as algorithm configuration parameters, actual ciphertext length, and encapsulation metadata. Each segment's overall structure is compared and verified against the compatibility with the currently used cryptographic algorithm, identifying potential issues such as structural mismatches and parameter anomalies. A specialized detection report is generated based on the verification results. If the overall verification fails, the report precisely identifies the problematic recipient, the specific error category, and actionable remediation suggestions. This report is simultaneously pushed to the front-end user interface and the back-end administrator review queue, facilitating timely problem resolution by all parties.

[0045] Throughout the entire encapsulation and load testing phase, key operational indicators such as attachment size and encapsulation operation status are continuously monitored. When abnormal situations occur, such as attachment size exceeding the limit threshold or encapsulation process interruption and failure, an operational log is automatically generated. The log fully records basic email information, the type of abnormality, and a list of all recipients. Simultaneously, an early warning signal is issued to alert relevant personnel for timely intervention. After all testing and handling work is completed, all encapsulation segment metadata and verification reports generated at each stage are persistently saved and uniformly entered into the encapsulation segment metadata table within the device's storage layer. This completes the entire process of this step.

[0046] Step S3: Based on the domestic public-key cryptography algorithm, perform signature authentication using the quantum-resistant public key, monitor the certificate expiration status, generate a renewal reminder before the certificate expires, and feed back the authentication result and reminder information to the quantum-resistant encapsulation step.

[0047] In this embodiment of the invention, this step is a crucial part of ensuring the trustworthiness of the public key in the entire encryption system. Its core function is to continuously maintain a trusted transmission link for the quantum-resistant public key across the entire network, while simultaneously standardizing the governance of the entire lifecycle of digital certificates, from issuance and use to expiration and renewal. When preset triggering behaviors such as user account login or manual key pair regeneration are detected, the system automatically reads the user's latest quantum-resistant public key data, and a domestic public-key cryptography algorithm performs standard digital signature operations. After the signature is completed, a series of supporting processes, such as public key serialization and certificate information entry, are executed sequentially. The entire process is seamlessly connected, ultimately resulting in the formal issuance of a compliant standard digital certificate.

[0048] This application incorporates a built-in certificate expiration reminder system that integrates with scheduled tasks. It initiates inspection tasks at predetermined intervals, systematically reviewing all existing digital certificates on the platform and accurately identifying those nearing expiration. Combined with pre-defined management rules, the system dynamically adjusts the reminder push intervals and simultaneously records the reminder content into the platform's notification database, sending targeted certificate renewal notifications to relevant users. To ensure effective delivery of reminders, the platform employs a multi-channel push notification approach to continuously distribute notifications until the user completes all key updates and certificate re-issuance operations, completely avoiding security issues caused by unattended expired certificates. Furthermore, a dedicated visual certificate verification interface is provided. Operations and maintenance personnel can use this interface to manually verify core fields such as the public key text, digital signature value, and public key fingerprint, fully guaranteeing the authenticity and validity of each issued certificate.

[0049] To achieve coordinated management of certificate status and key encapsulation processes, the system aggregates real-time status data for each certificate, including signature authentication results and expiration reminders. Based on this data, a detailed certificate profile is constructed, encompassing key information such as public key fingerprints, unique certificate serial numbers, validity periods, and real-time operational status. The management platform uses a visual heatmap to display the data, clearly distinguishing between three operational states: certificate revocation, impending expiration, and normal status. This allows administrators to intuitively grasp the overall distribution and operational status of certificates across the network. The system continuously monitors for status change events such as certificate issuance, revocation, expiration, and renewal. Once a status change is detected, the latest information is immediately synchronized to the front-end key encapsulation stage.

[0050] During the subsequent key encapsulation and distribution queue setup, the queue content is flexibly adjusted based on the latest synchronized certificate status. Recipients whose certificates have expired are directly removed from the queue, triggering security alerts simultaneously. For recipients whose certificates are nearing expiration, their encapsulation processing priority is proactively increased, ensuring the encapsulation and distribution of their corresponding session keys is completed first. Before each key encapsulation process is initiated, the program proactively retrieves the latest certificate status data as the basis for execution, ensuring that the entire key encapsulation and distribution process always runs on a trusted certificate link, mitigating various security risks from the source. This mechanism effectively compensates for the vulnerability of email communication interruption and inability to decrypt content due to certificate expiration during long-term use of encrypted emails, gradually building an immersive trust closed loop from certificate issuance, real-time status monitoring, expiration reminders, to coordinated scheduling.

[0051] Step S4: Use the quantum-resistant private key to deseal the encapsulated segment in the email payload, extract the session key, and decrypt the email body and attachments based on the session key, thereby realizing a closed loop for the local storage and sending / receiving of encrypted emails.

[0052] In this embodiment of the invention, all calculations and interactions in this step are completed within the user's local browser. A dedicated cryptographic engine is built into the browser's underlying runtime environment, and a fully functional encryption / decryption unit is constructed based on this engine. All components work collaboratively to form an integrated encrypted email sending and receiving service platform. When a user receives an encrypted email, the front-end program first retrieves and loads the recipient's locally stored quantum-resistant private key. This private key is protected by the user's personal login password. After loading, it is temporarily stored in the current browser's session memory, ensuring both efficient key retrieval and reducing the risk of key leakage.

[0053] The program then fully parses the multiple encapsulation segments within the email payload and uses the locally stored quantum-resistant private key to perform decapsulation operations. If the decapsulation process proceeds smoothly, the program extracts the session key generated during the encryption phase from the encapsulation segments. If an anomaly occurs during the decapsulation process, the front-end interface immediately pushes the corresponding error message to the user, indicating the type of failure. After successfully obtaining the session key, the program calls various pre-built functional modules, such as domestic block cipher algorithms and quantum-resistant cryptographic algorithms, and uses the extracted session key to perform decryption operations on the email body and various attachments, gradually restoring the original plaintext data of the email.

[0054] Before and after the decryption process officially begins, integrity checks are performed on ciphertext boundaries, data encoding formats, and overall data length. If any anomalies are detected during the checks, the current decryption process is immediately terminated, and a data integrity alert is sent to the user. During the decryption phase, the session key is temporarily cached in the current browser session space. When an email has multiple attachments, the cached session key can be automatically reused, eliminating the need to repeatedly perform decryption and key retrieval operations, significantly improving decryption efficiency. Simultaneously, the entire key usage trajectory and complete lifecycle information are recorded, ensuring traceability of key usage.

[0055] Once decrypted, the email data is directly stored locally in the browser. If the user chooses to download the decrypted file, an attachment with a unique ciphertext marker is automatically generated for the user to save and view. All operational logs and records generated in this process are synchronously aggregated into the decryption trajectory statistics system, connecting the various stages of front-end email encryption, remote key encapsulation, network data transmission, local encapsulation and decapsulation, and file decryption to ultimately construct a complete closed-loop process for encrypted email sending and receiving, from encryption initiated at the browser end to local file storage.

[0056] Example 2 This application provides an email encryption system that supports quantum-resistant cryptographic migration. Through the coordinated operation of four modules—hierarchical encryption, key encapsulation, certificate authentication, and client execution—a trusted closed loop covering the entire email sending and receiving process is constructed.

[0057] The overall system architecture is as follows Figure 2 As shown, the architecture consists of a hierarchical encryption strategy module, a key encapsulation and distribution module, a certificate authentication and issuance module, and a client encryption and decryption execution module. Each module relies on the email encryption device to achieve the coordinated operation of hardware and software, providing full-link support for the generation, distribution, authentication, and decryption of encrypted emails.

[0058] In this embodiment, the hierarchical encryption strategy module is the system's entry module, used by the user to select the encryption granularity and generate the session key before sending the email. Its internal structure is as follows: Figure 3 As shown, the system includes an encryption mode selector, a sensitivity alert engine, and an encryption parameter generator. The encryption mode selector offers dynamic switching between four modes: "No Encryption," "Encrypt Body Only," "Encrypt Attachments Only," and "Encrypt Body and Attachments Simultaneously." Users can flexibly choose based on the importance of the email content and the recipient's situation. The sensitivity alert engine identifies the email's sensitivity level by analyzing the recipient's certificate status, historical encryption preferences, and email subject keywords. When the system determines an email to be highly sensitive, it automatically locks it into the mode of encrypting both the body and attachments. When the determination result is uncertain, a prompt pops up on the front-end encryption preview interface, allowing the user to manually confirm the encryption mode. The encryption parameter generator automatically generates a dedicated session key based on the final determined encryption granularity, strictly adhering to domestic block cipher algorithm specifications, and also supports dynamic adaptation of encryption strategies through algorithm models.

[0059] In this embodiment, the encryption parameter generator uses a dynamic encryption difficulty coefficient. The encryption granularity is adjusted according to the following rule: if the user's historical encryption rate for the recipient is lower than the threshold T, then the encryption level is reduced. Prioritize the use of the lighter "encrypt body only" mode; if the user's historical encryption rate for this recipient is higher than the threshold T, then increase the encryption rate. It also forces the use of "simultaneous encryption of the email body and attachments". When a user sends an encrypted email for the first time, the system uses a layered initialization strategy, encrypting all recipients' emails simultaneously. The initial value is set to 1.0, and a pre-evaluation and correction are performed based on the recipient's certificate status. Emails with valid recipient certificates are included. Set to 1.2 to enable full encryption; emails with partially expired recipient certificates. Set to 0.7, reverting to encrypting only the text; otherwise, keep it unchanged. =1.0. The threshold T is set by combining cryptographic engineering experience with compliance requirements. It is initially set to 75% for ordinary users and 65% for administrator accounts. The appropriate encryption pressure is maintained through quarterly dynamic calibration and scenario-based adaptation to ensure that the encryption policy is always in the user's "usable trust zone".

[0060] Meanwhile, the module integrates a multi-dimensional encrypted preview interface, providing senders with a convenient confirmation tool. This includes a ciphertext fragment display window, an encryption mode switch, and a packaged segment preview area. Users can switch encryption modes online, with the interface content updating in real-time, and confirmation results synchronized to the composing editor. After the user confirms the encryption configuration, the system generates an encryption context containing the encryption mode, session key identifier, recipient certificate information, sensitivity marker, and timestamp, and caches it locally in the browser. When an unexpected page refresh is detected, the locally cached encryption context is automatically retrieved to restore the email editing state. After the user triggers the send command, the front-end uploads the ciphertext and encryption context digest to the server, the back-end stores the email and updates the ledger, and the system simultaneously calculates encryption coverage in real-time, generating a management dashboard that supports multi-condition filtering. Users can independently export the encryption context for subsequent security audits.

[0061] In this embodiment, the key encapsulation and distribution module is used to securely distribute session keys in multi-recipient scenarios. This module includes a quantum-resistant public key pair management system, a multi-dimensional encapsulation engine, and an encapsulation segment assembler. The quantum-resistant public key pair management system generates key pairs based on a quantum-resistant cryptographic algorithm upon a user's first login, and batch loads recipient certificate files, verifying the validity of each certificate. For revoked or soon-to-expire certificates, it removes them from the distribution queue or sends a risk alert according to a preset strategy. The multi-dimensional encapsulation engine performs comprehensive scheduling based on the weights of protocol correctness, encapsulation latency, and concurrency efficiency, using a weighted sorting model to plan the recipient processing order, prioritizing encapsulation operations for recipients whose certificates are about to expire.

[0062] In this embodiment, the multi-dimensional encapsulation engine provides multiple preset parameter sets for quantum-resistant cryptographic algorithms, allowing users to freely choose security levels. It also records the encapsulation process and generates encapsulation segment metadata for later auditing. The encapsulation segment assembler automatically checks whether the integrity of each recipient's encapsulation segment conforms to the quantum-resistant cryptographic algorithm encapsulation specifications. After a single encapsulation segment is generated, it sequentially checks the data format, byte length, algorithm identifier, etc. If a verification error occurs, a secondary encapsulation is triggered or an error report is generated. All verified encapsulation segments are uniformly integrated and written into the email payload, and encapsulation time data is transmitted back to the management monitoring dashboard in real time.

[0063] After the encapsulation segment is assembled, the system executes the encapsulation payload verification and anomaly warning process. It parses the encapsulation segment within the email payload, extracting information such as algorithm parameters, ciphertext length, and encapsulation metadata. It verifies the matching between the encapsulation segment structure and the algorithm item by item, generating a dedicated verification report and pushing it to the front-end interface and the administrator review queue. The system continuously monitors indicators such as attachment size and encapsulation operation status. When attachments exceed limits or encapsulation fails, it records logs containing email information, anomaly type, and recipient list, and issues an alert. Finally, it persistently stores the encapsulation segment metadata and verification report in the encapsulation segment metadata table. Simultaneously, the module supports encapsulation order optimization suggestions, providing users with suggestions for improving recipient sorting and concurrency based on a library of historical successful sending cases. The concurrent encapsulation simulator provides a batch recipient environment for typical scenarios such as government cloud and financial approval, supporting users to test the feasibility of multi-recipient quantum-resistant encapsulation.

[0064] In this embodiment, the certificate authentication and issuance module is used to prevent the server's public key from being maliciously replaced and to maintain a trusted transmission link for quantum-resistant public keys across the entire network. Its internal structure is as follows: Figure 4 As shown, the system includes an automatic certificate issuance mechanism, an intelligent expiration reminder algorithm, and a certificate verification sandbox. The automatic certificate issuance mechanism uses a domestically developed public-key cryptography algorithm to calculate the signature of the standard payload. When a user login or active key pair update is detected, the system retrieves the user's latest quantum-resistant public key, completes the digital signature calculation, and writes it to the certificate ledger, generating a standard digital certificate. The intelligent expiration reminder algorithm pushes system notifications based on the remaining days of the certificate. It uses a scheduled task to scan all valid certificates, and when the remaining days are below a threshold, it writes a reminder to the notification queue. The reminder mechanism generates an interval reminder path based on a decay curve. The reminder is automatically removed from the reminder queue only after the user completes "regenerating a quantum-resistant key pair" and writes the new public key, forming an adaptive certificate governance system. The certificate verification sandbox supports visual comparison of the CA public key, signature value, and quantum-resistant public key fingerprint. Operation and maintenance personnel can manually verify core fields such as public key content, signature value, and public key fingerprint to ensure the authenticity and validity of the certificate issuance results.

[0065] In this embodiment, the module also includes a certificate profile generator, which can link with data from various modules to visually display the certificate issuance structure of the email system, annotate the public key fingerprints and associated validity periods of each user, and provide detailed analysis of the revocation reasons in the revocation audit report, recommending relevant re-signing strategies and user communication templates. The system constructs a certificate profile containing public key fingerprints, serial numbers, validity periods, and operational status by summarizing certificate signature authentication results and expiration reminder status. A visual heatmap distinguishes between three scenarios: certificate revocation, impending expiration, and normal status, intuitively displaying the distribution status of certificates across the entire network. The system monitors certificate issuance, revocation, expiration, and renewal status change events in real time and synchronizes the change information to the key encapsulation stage, adjusting the encapsulation and distribution queue, removing recipients with expired certificates and triggering alarms, and increasing the encapsulation processing priority for recipients with expiring certificates. This ensures that the key encapsulation process is always executed based on a trusted certificate link, forming an immersive trust closed loop from certificate issuance, status monitoring, expiration reminders to coordinated scheduling.

[0066] In this embodiment, the client-side encryption / decryption execution module is used to complete all operations on the encrypted email on the browser side, and its internal structure is as follows: Figure 5 As shown, it includes a text / attachment encryption / decryption execution console, a package key decryption module, and a ciphertext consistency verification system. The text / attachment encryption / decryption execution console performs text and attachment encryption based on domestic block cipher algorithms, as well as package key decryption based on quantum-resistant cryptography algorithms, locally. It supports parameter modification and real-time display of the running effects of various domestic block cipher algorithm working modes. Users can observe changes in ciphertext structure by adjusting the encryption mode, deepening their understanding of hybrid encryption principles.

[0067] When a user receives an encrypted email, the front end loads the recipient's locally stored quantum-resistant private key. This private key is protected by the user's login password and cached in the current session's memory. The encapsulation segment key decapsulation module parses the encapsulation segment within the email payload, calls the local private key to perform the decapsulation operation, and after successfully extracting the session key, the system calls the built-in domestic block cipher algorithm to decrypt the email body and attachments using the session key, restoring the plaintext data. The ciphertext consistency verification system verifies the ciphertext boundaries and encoding structure, checking the data length, encoding format, and integrity before and after decryption. If the verification fails, decryption is terminated and an alarm is issued. During decryption, the session key is temporarily cached within the browser session and can be automatically reused when decrypting multiple attachments of the same email. The system also records the key usage trajectory and lifecycle information. After decryption, the email data is locally stored on the browser. When the user downloads the decrypted file, the system automatically generates an attachment with ciphertext markings for the user to access. Operation data is synchronously fed back to the decryption trajectory statistics system, generating personalized operation time curves and improvement suggestions.

[0068] In this embodiment, the module also includes an encryption / decryption sandbox platform that periodically triggers text / attachment encryption / decryption self-tests, sets self-test cases of different sizes and mode levels, and the key caching and sharing system supports automatic reuse of the session key obtained from text decryption for attachment decryption. It provides decryption consistency verification and key lifecycle monitoring functions, and builds a closed-loop sending and receiving process from browser encryption to local storage.

[0069] In this embodiment, the system also includes a management and monitoring dashboard, a multi-role collaboration platform, and a real-time key status synchronization system. The management and monitoring dashboard displays the encryption status in real time, including a user certificate coverage heatmap, an encryption mode percentage graph, a quantum-resistant encapsulation time distribution graph, and an attachment encryption volume radar graph. The heatmap uses a red, yellow, and green gradient to represent certificate status: red indicates revoked or expired, yellow indicates expiration within 7 days, and green indicates sufficient validity. Administrators can adjust key rotation strategies based on the heatmap distribution. The multi-role collaboration platform supports collaborative operations for three roles: super administrator, expert, and ordinary user. Super administrators have CA revocation and re-signing permissions, experts are responsible for maintaining the quantum-resistant parameter library and setting encryption strength ratios, and ordinary users can independently manage their address books and encryption preferences. The platform implements interface-level access control through an identity authentication component to ensure the secure isolation of high-risk operations. The real-time key status synchronization system is used to realize the real-time update of certificate and key status. The key status panel is categorized into three types: valid, about to expire, and revoked. It supports sorting by multiple dimensions such as expiration date and revocation reason. The system has three display modes: in-site notification, management console, and expiration badge, and is equipped with a certificate serial number prefix display mechanism to encourage users to complete key rotation in a timely manner.

[0070] In this embodiment, four modules—tiered encryption strategy, key encapsulation and distribution, certificate authentication and issuance, and client-side encryption / decryption execution—form a closed-loop data transmission mechanism. User encryption mode records, recipient certificate status, and decryption operation time are fed back to the recommendation model, constructing a comprehensive quantum-resistant email communication ecosystem. The system innovatively builds a secure browser-side sandbox environment, supporting parameterized debugging and visualization of mainstream cryptographic algorithms. It provides core functions such as animated demonstrations of the encryption process, real-time parameter modification, isolated computation, and encryption / decryption data recording. A tiered usage support system is formed through step-by-step encryption / decryption prompts, similar email templates, and encryption knowledge review materials. Simultaneously, the system deeply integrates intelligent error pattern recognition, automatically detecting common errors such as pattern obfuscation, unencrypted attachments, and missing quantum-resistant encapsulation segments, generating targeted error correction prompts. Performance optimization employs session key caching and pre-encapsulation mechanisms to improve response speed, and supports concurrency acceleration functions to adjust the execution speed of time-consuming operations such as multi-recipient encapsulation, achieving a highly efficient encryption experience. Through the above technical solution, this application effectively solves the problem of communication unreachability caused by certificate expiration during the long-term operation of encrypted email, and realizes the whole process of trusted sending and receiving of email in quantum cryptography migration scenario, taking into account security, availability and traceability.

[0071] Example 3 This invention also relates to an email encryption software device that supports quantum-resistant cryptographic migration. This device is delivered as a standalone software module and can be embedded into existing email clients and email servers for functional integration. The device as a whole consists of a four-level device kernel, a device access layer, a device interface layer, and a device event bus, forming a complete system. The four-level device kernel specifically includes a hierarchical encryption strategy unit, a key encapsulation and distribution unit, a certificate authentication and issuance unit, and a client encryption / decryption execution unit.

[0072] The hierarchical encryption strategy unit configures encryption mode selection subunits, sensitivity prompt subunits, and encryption parameter generation subunits. This unit exposes a unified encryption strategy call interface, providing encryption granularity determination services to the email composition and editing component, email sending channel component, and system management and monitoring component within the device. It automatically matches encryption levels with execution rules based on email content attributes and user-preset rules, ensuring the standardization and adaptability of encryption strategy output. The key encapsulation and distribution unit integrates a quantum-resistant public key pair management subunit, a multi-dimensional encapsulation subunit, and an encapsulation segment assembly subunit. This unit exposes key encapsulation interfaces and multi-recipient distribution interfaces, employing a configurable scheduling strategy for business scheduling. The scheduling process dynamically adjusts the data based on three weighted indicators: protocol compliance, encapsulation processing latency, and multi-task concurrent operation efficiency. This ensures stable session key distribution services to other functional units within the device, balancing key transmission security and distribution efficiency.

[0073] The certificate authentication and issuance unit comprises an automatic certificate issuance subunit, an intelligent expiration reminder subunit, and a certificate verification sandbox unit. This unit provides five functional interfaces: certificate issuance, information query, certificate revocation, certificate re-signing, and reminder subscription. During operation, the unit monitors the certificate's entire lifecycle status in real time. If a certificate status changes, it immediately broadcasts the status event to other functional units within the device via the device event bus, achieving synchronization of certificate information across the entire device. The client-side encryption / decryption execution unit is divided into a text and attachment encryption / decryption execution subunit and a ciphertext consistency verification subunit. This unit deploys a browser-side encryption / decryption interface, which can be shared and called by the inbox component, attachment download component, and email composition / preview component. It uniformly performs encryption and decryption operations on email text and attachments and performs integrity verification on the processed ciphertext to avoid anomalies such as ciphertext tampering and data loss.

[0074] The device access layer and device interface layer work together as supporting structures for the Level 4 device kernel. The device access layer encapsulates capabilities related to multi-role collaborative management, user authentication, and communication session management, and sets up access-controlled call entry points for the Level 4 device kernel, standardizing internal function call logic. The device interface layer outputs standardized integration interfaces to external email platforms, enabling this software device to be embedded as an independent functional component into various existing email systems, achieving rapid deployment of quantum cryptography-resistant migration and email encryption capabilities, and achieving a plug-and-play integration effect.

[0075] The overall architecture of this device is divided into three layers: the front-end device layer, the device service layer, and the device storage layer. Each layer relies on the device event bus to achieve data interaction and business linkage. The functional boundaries between layers are clear, and their operational logic is decoupled. The front-end device layer is deployed in the user terminal browser environment. This layer carries the interactive components corresponding to the hierarchical encryption strategy unit, the browser-side cryptographic operation components corresponding to the client encryption and decryption execution unit, and the encryption preview component. All cryptographic operations and session key processing operations performed by the front-end device layer are completed within an independent browser process. Plaintext data and key data are not leaked, ensuring the security of email data and key information at the operational environment level.

[0076] The device service layer is deployed on the backend server equipment. This layer carries the concurrent scheduling component corresponding to the key encapsulation and distribution unit, the certificate issuance and revocation component corresponding to the certificate authentication and issuance unit, and also carries the management and monitoring dashboard component. Throughout the device's entire operational process, the server does not handle plaintext email data or session key data; it only handles encrypted forwarding, certificate lifecycle management, and encryption policy distribution and push, further reducing the risk of leakage of core sensitive data. The device storage layer is responsible for the persistent storage of various types of data within the device. Its main storage contents include certificate management ledgers, encapsulation segment metadata, encryption context records, and user-personalized encryption preference data. This layer provides data query interfaces and operation audit interfaces to the certificate authentication and issuance unit and the management and monitoring dashboard component, supporting certificate verification, behavior tracing, data statistics, and other related business operations.

[0077] The front-end device layer, device service layer, and device storage layer achieve decoupled operation through the device event bus. Various business events, such as certificate status changes, encapsulation segment generation, and encryption context updates, are synchronously transmitted throughout the entire device via event broadcasting. This constructs a complete operational loop encompassing local front-end computation, server-side collaborative scheduling, and storage layer data auditing. This device architecture is adaptable to various deployment modes, including containerized deployment, virtualized deployment, and local deployment. It enables isomorphic migration across different operating environments and smoothly completes iterative upgrades to quantum-resistant cryptographic systems, demonstrating excellent environmental adaptability and functional scalability.

[0078] Example 4 To implement the methods of the above embodiments, the present invention also provides an electronic device, such as... Figure 6 As shown. The electronic device includes a processor 510, a hybrid storage architecture 520, a communication interface 530, and a system bus connecting the above components; the processor 510, the hybrid storage architecture 520, and the communication interface 530 complete high-speed data interaction through the system bus; the communication interface 530 is used to realize encrypted data transmission between the terminal browser, the email server, and the CA key directory, supporting cross-module encrypted email collaboration.

[0079] The processor 510 is used to call the computer program stored in the hybrid storage architecture 520 and execute the following four-level collaborative process: generating encryption context and session key via the hierarchical encryption strategy module; driving the key encapsulation and distribution module to complete the concurrent distribution of multi-recipient quantum-resistant encapsulation segments; controlling the certificate authentication and issuance module to perform trusted issuance and expiration management based on domestic public key cryptography algorithms and quantum-resistant public keys; and scheduling the client encryption and decryption execution module to complete the ciphertext sending and receiving and local storage on the browser side.

[0080] The hybrid storage architecture 520 employs a multi-level storage media combination, including: static storage for storing the domestic block cipher algorithm library and the basic operation program of the quantum-resistant cryptography algorithm; dynamic storage for caching session key data and real-time encryption status; and non-volatile storage for persistent storage of user certificate ledgers, encapsulation segment logs, and encryption context records.

[0081] The processor 510 is a dedicated chip integrating a multi-core computing unit, supporting parallel execution of four-level module tasks. Its hardware instruction set includes a cryptographic operation acceleration module, ensuring efficient execution of encryption and decryption operations of domestic block cipher algorithms and quantum-resistant cryptographic algorithms.

[0082] Example 5 To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.

[0083] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0084] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0085] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. An email encryption method supporting quantum-resistant migration, characterized by, include: Based on the recipient's certificate status and email sensitivity, select the encryption granularity from a variety of preset encryption modes and generate a session key; Based on the recipient's quantum-resistant public key, the session key is encapsulated in a quantum-resistant manner, generating an independent encapsulation segment for each recipient, and assembling all encapsulation segments into the email payload; Based on domestic public-key cryptography algorithms, the system performs signature authentication using quantum-resistant public keys, monitors certificate expiration status, generates renewal reminders before certificate expiration, and feeds back authentication results and reminder information to the quantum-resistant encapsulation step. By using a quantum-resistant private key to decapsulate the encapsulated segment within the email payload, extract the session key, and decrypt the email body and attachments based on the session key, a closed loop for the entire process of local storage and sending / receiving of encrypted emails is achieved.

2. The method of claim 1, wherein, Based on the recipient's certificate status and email sensitivity, select the encryption granularity from a variety of preset encryption modes and generate a session key, including: Read the user's encryption preferences and combine them with four preset modes to determine the encryption granularity: no encryption, encryption of only the body text, encryption of only the attachments, and encryption of both the body text and attachments. By combining the recipient's certificate status, historical encryption preference data, and keywords in the email subject, the sensitivity level is calculated. When the email is determined to be highly sensitive, it is automatically locked to the encryption mode of both the body and attachments. When there is uncertainty in the determination, the user can manually confirm the encryption mode in the preview interface. Based on the final determined encryption granularity, a session key is generated in accordance with the specifications of domestic block cipher algorithms.

3. The method according to claim 2, characterized in that, After generating the session key, perform the encryption preview and context fixation steps, which include: The system retrieves the determined encryption mode and session key, displays information including ciphertext fragments, encapsulation length, and the size of the encrypted attachment in the encryption preview interface, and supports online switching of encryption modes and real-time updates of preview content. After the user confirms the encryption configuration, an encryption context containing the encryption mode, session key identifier, recipient certificate information, sensitivity marker and timestamp is generated and cached locally in the browser; It monitors the browser's running status in real time, and automatically retrieves the local cached encryption context when an unexpected page refresh is detected, restoring email editing and encryption configuration; The system responds to user commands by uploading the encrypted text and encryption context digest to the server. The server stores the emails and updates the ledger, synchronously refreshing the encrypted statistics dashboard. It also supports users in exporting the encryption context for subsequent auditing.

4. The method according to claim 3, characterized in that, Based on the recipient's quantum-resistant public key, the session key is quantum-resistant encapsulated, generating an independent encapsulation segment for each recipient, and assembling all encapsulation segments into the email payload, including: Read the generated session key and certificate information of all recipients to obtain the valid quantum-resistant public key for each recipient; The recipient list is sorted based on three weighting factors: protocol correctness, encapsulation latency, and concurrency efficiency. The encapsulation priority is dynamically adjusted based on the certificate expiration time, prioritizing recipients whose certificates are about to expire. Using each recipient's quantum-resistant public key, quantum-resistant encapsulation is performed on the same session key separately, generating an independent encapsulation segment for each recipient, and recording the encapsulation time and running status; Perform integrity checks on each encapsulated segment, verifying whether the format, length, and algorithm identifier conform to the specifications. If the check fails, trigger re-encapsulation or generate an error report. All verified encapsulation segments are integrated and written into the email payload according to the standard format. At the same time, the encapsulation time data is sent back to the management and monitoring dashboard.

5. The method according to claim 4, characterized in that, After assembling all encapsulation segments into the email payload, perform encapsulation payload verification and anomaly warning steps, specifically including: Parse the encapsulation segment set in the email payload, extract information including algorithm parameters, ciphertext length, and encapsulation metadata, and verify the matching of the encapsulation segment structure with the algorithm item by item; A corresponding report is generated based on the verification results. When the verification fails, the abnormal recipient, error type, and repair suggestions are marked and pushed to the front-end interface and the administrator review queue. Real-time monitoring of metrics including attachment size and encapsulation operation status; when attachments exceed limits or encapsulation fails, logs containing email information, exception type, recipient list, and an alert are issued. All encapsulation segment metadata and verification reports are persistently stored in the encapsulation segment metadata table in the device storage layer.

6. The method according to claim 5, characterized in that, Based on a domestically developed public-key cryptography algorithm, this system performs signature authentication using a quantum-resistant public key and monitors certificate expiration status. It generates renewal reminders before certificate expiration and feeds back the authentication results and reminder information to the quantum-resistant encapsulation step, including: When a user login or active key pair update is detected, the user’s latest quantum-resistant public key is retrieved, the domestic public key cryptography algorithm completes the digital signature, generates a standard digital certificate and enters it into the certificate ledger. The system periodically checks existing certificates through scheduled tasks, identifies certificates nearing their expiration date, and pushes renewal notifications at dynamically adjusted reminder intervals. Multiple channels are used to display expiration reminders to users until they complete key renewal and certificate re-signing. It provides a visual interface for certificate verification, supporting manual comparison and verification of public keys, signature values, and public key fingerprints.

7. The method according to claim 6, characterized in that, The authentication results and alerts are fed back to the quantum-resistant encapsulation step, which is achieved through certificate state-driven encapsulation scheduling optimization, specifically including: Summarize certificate signature authentication results and expiration reminder status to construct a certificate profile that includes public key fingerprint, serial number, validity period, and running status; A visual heatmap is used to distinguish between three categories of certificates: revoked, about to expire, and in normal status, providing an intuitive display of the distribution status of certificates across the entire network. Real-time monitoring of status change events, including certificate issuance, revocation, expiration, and renewal, and synchronization of change information to the key encapsulation stage; Adjust the encapsulation and distribution queue according to the latest certificate status, remove recipients whose certificates have expired and trigger alarms, and increase the encapsulation priority of recipients with near-expiration certificates. Before each encapsulation process, the latest certificate status data is retrieved to ensure that the key encapsulation process is executed based on a trusted certificate link.

8. The method according to claim 7, characterized in that, The process involves using a quantum-resistant private key to decapsulate the encapsulated segment within the email payload, extracting the session key, and then decrypting the email body and attachments based on the session key, including: The recipient's quantum-resistant private key is loaded in the browser and cached in the current session's memory after being protected by the user's login password; Parse the encapsulation segment within the email payload, perform the decapsulation operation using the local private key, extract the session key if decapsulation is successful, and push an error message if decapsulation fails. The domestically developed block cipher algorithm was invoked, and the extracted session key was used to decrypt the email body and attachments respectively, restoring the plaintext data. Before and after decryption, the ciphertext boundaries, encoding format and data length are checked. If the check is abnormal, the decryption is terminated and an integrity alarm is issued. The session key is cached within the current browser session. When decrypting multiple attachments of the same email, the key is automatically reused, and the key usage trajectory and lifecycle are recorded. The decrypted email data is stored locally, linking the entire process of encryption, encapsulation, transmission, decapsulation, and decryption to form a complete closed loop for sending and receiving emails.

9. An electronic device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the method as described in any one of claims 1-8.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-8.

Images