Java分块上传与加密存储实战：AES/CTR模式与密钥管理详解

1. 为什么“分块上传”必须和“加密存储”绑在一起

做Java后端的人迟早要碰大文件上传。早些年大家习惯直接multipart/form-data一把梭，文件稍微大点就超时、内存爆掉、连接断开重来。后来分块上传成了标配，把一个大文件切成若干块，前端一块一块传，后端一块一块收，最后再合并。但搞定“能传”只是第一步，真正让项目上线后睡不着觉的，往往是一句话：文件落盘之后，别人能不能直接拿走用？

这个标题提的是“加密存储在JAVA分块上传中的技术探讨”，说白了就是解决两件事：第一，分块上传这块骨头怎么啃；第二，啃下来的肉（文件数据）怎么安全地存下来。二者一旦结合，就不是简单的“传完再加密”这么直白。分块意味着文件在网络上被拆散传输，在服务器上是分片落盘，每一片都可能被单独读取；存储加密意味着要保证每个分片、以及最终合并出来的完整文件，都不能被未授权的人解密。这里涉及到传输通道、分片落盘、密钥管理、解密合并四个环节，任何一个环节漏了，前面做得再好也是白搭。

这篇文章面向的读者，我默认是已经在用Spring Boot做接口对接、已经在处理文件上传但还没系统考虑过安全的Java开发者。全文会围绕“加解密如何嵌入分块生命周期”这条主线展开，从方案选型、代码实现到常用踩坑排查，给出一套能直接复用的工程实践。

先说结论：分块上传 + 加密存储的组合，真正要命的不是算法本身，而是分块的边界和加密的粒度之间的关系。选错加密模式，合并出来的文件可能只有第一块能解开，后面全是乱码。这个坑我见过不止一次。

2. 方案选型：加密算法和分块流程怎么匹配

2.1 三层加密设计，别只盯着算法

很多人的第一反应是“用AES加密一下不就完了”。没错，AES肯定是要用的，但放在分块上传的语境里，光选AES还不够，你得想清楚加密发生在哪一层。

我习惯把加密拆成三层来看：

第一层是传输层加密，也就是HTTPS。这一层保护的是数据在网络上传输时不被窃听，但注意，它保护不到服务器端的落盘文件。你总不能指望TLS在上传结束后还帮你守文件。

第二层是应用层分块加密，也就是在Java后端收到每一个分块后，对它单独做加密再落盘。这一层是本文讨论的重点，因为它决定了每个分片在服务器上是不是“密文形态”。

第三层是静态存储加密，比如把整个磁盘或对象存储桶做透明加密。这一层通常是基础设施的事，但如果你用的是自建服务器，千万别指望系统自带的透明加密能覆盖所有场景。

真正需要你亲手写的，是第二层。但在写第二层之前，必须先设计好分块和加密的对应关系。

2.2 分组模式选型：CBC、GCM还是CTR

我这里直接给结论：分块上传场景，不推荐用CBC模式做分块独立的加密。

原因很简单：CBC模式是链式的，前一个密文块会作为下一个明文块的加密输入。如果按分块独立加密，每一块都需要随机IV，那合并后的文件其实是一个个“独立加密单元”拼起来的。解密的时候，每一块必须用当时加密用的IV才能解开；而且CBC的padding处理在流式场景非常容易踩坑，一旦某一块长度不对，解密直接失败。

GCM模式是AEAD加密，自带认证和完整性校验，听起来很适合。但它的坑在于：GCM的认证标签（tag）是针对整个密文串计算的，如果你对每个分块单独做GCM，那么合并后的文件没法直接整体验签，只能分块验。如果前端传过来的分块顺序是乱的，合并时对不上tag，解密直接炸。

真正适合分块上传+合并场景的，是CTR模式或着CTR模式的可认证变体。CTR模式本质是把AES变成一个流密码，加密和解密都是对计数器值做加密，再跟明文异或。它的最大好处有两个：一是密文长度和明文长度完全一致，不需要处理padding；二是每个分块的加密位置可以通过计数器精确控制，合并的时候只要保证计数器连续，整个文件能无缝解出来。

我用的是AES/CTR/NoPadding，配合一个全局唯一的初始向量（IV）和递增的计数器来划分每个分块的加密位置。这样，分块上传和加密存储就真正变成了同一件事：每个分块就是一个“计数器区间”的异或结果。

2.3 完整性校验：不能只靠加密算法的tag

有人会问：GCM有认证功能，用了CTR之后完整性怎么办？答案是用HMAC-SHA256对整个合并后的文件（或对密文整体）再做一次签名校验。

我实际项目的做法是：分块上传阶段，每一块计算一个SHA-256摘要，记录在分块元数据里，用来保证分块在网络传输中没有损坏；全部上传完成后，服务端合并出完整密文，再用主密钥派生出一个HMAC密钥，对整个密文算一个HMAC-SHA256，存到元数据里。解密时先校验HMAC，再开始解密。这样既享受了CTR模式在分块场景下的灵活性，又弥补了CTR不提供认证的缺陷。

不要觉得多算一次HMAC是浪费。线上环境里，文件被篡改、分块顺序被重放、存储介质静默损坏，这些都是真实会发生的。有HMAC在，至少能在解密之前发现异常，而不是等解密出一堆乱码再去猜原因。

3. 分块上传中的加密流程设计

先不谈具体代码，把完整流程捋一遍。这个流程我直接在项目里落地过，核心原则是：上传会话启动时生成密钥材料，每个分块都基于同一个主密钥+全局IV+计数器偏移来加密，服务器永远不落明文。

3.1 上传会话初始化

前端在开始上传之前，先调一个初始化接口，例如POST /upload/init。这个接口做什么事？

服务端生成一个uploadId，作为整个上传会话的标识；生成一个16字节的随机IV（实际可用8字节随机数+8字节计数器空间，但你用满16字节也安全）；同时生成一个随机的数据加密密钥（DEK），注意不要直接用主密钥去加密文件，而是生成一个临时DEK，再用主密钥去加密DEK（也就是常说的信封加密）。

这个DEK可以放在缓存里（Redis），key就是uploadId，value是DEK密文；也可以序列化到数据库字段里。总之，要保证整个上传会话期间，服务端有办法随时拿到能解出DEK的材料，但明文DEK不要落库，只在内存里短暂存在。

初始化接口返回给前端：uploadId、每块的建议大小、IV值、以及总块数的计算方法。

3.2 分块编号与计数器偏移的计算

这一节是整个方案的技术核心。我先给参数，再解释为什么这么算。

我定的分块大小是5MB（当然你可以调成1MB、10MB，逻辑不变）。AES分组的块大小是16字节，CTR模式的计数器也按16字节来算。

设文件总长度为fileLength，分块大小为chunkSize，第i个分块（从0开始）在文件中的起始明文偏移量为offset = i * chunkSize。

CTR模式下，计数器值由IV和块计数器组成。我用的计数器策略是：

• 将16字节IV视作一个128位的大整数：高64位是随机数，低64位是计数器，初始值为0。
• 对文件中的一个分组（16字节）加密时，使用的计数器值 = IV的低64位 + 该分组在明文中的分组序号。
• 分组序号 = floor(globalOffset / 16)，其中globalOffset是该分组在整个文件中的绝对偏移量。

那么，第i个分块在整个文件中的起始分组序号是：

text复制startBlockIndex = offset / 16 = (i * chunkSize) / 16

因为chunkSize我固定为5MB，而5MB = 5 * 1024 * 1024 = 5242880字节，正好能被16整除（5242880 / 16 = 327680）。如果分块大小不能被16整除，你就必须单独处理边界，麻烦很多。这是很多人会忽略的细节：分块大小最好设计成16的整数倍，否则每个分块的尾部都要特殊处理。

有了起始分组序号，加密第i个分块时，代码里的IV+计数器就是：

java复制BigInteger ivNum = new BigInteger(1, ivBytes); // 128位大整数
BigInteger counterStart = ivNum.add(BigInteger.valueOf(startBlockIndex * 16L));

等等，这里有个细节：计数器自增的单位是“分组”，不是“字节”。如果你用startBlockIndex * 16来计算增量，实际上是把分组序号转成了字节偏移量再塞进计数器里。换算方式要统一，否则解出来的中间部分是乱的。

我这里推荐一种更稳妥的写法：把16字节IV拆成前12字节随机数（nonce）和后4字节计数器。计数器只针对分块内部的分组自增，而每个分块的起始计数器 = 分块序号 * 每块分组数。这样更直观，也更容易排查。

java复制// IV前12字节为随机数，后4字节为计数器
byte[] nonce = new byte[12];
byte[] counter = new byte[4];

对每个分块加密时，将counter初始化为该分块的起始计数器值（4字节int），然后每加密一个16字节分组，对counter做整数加1。因为前面已经保证chunkSize / 16 = 327680，计数器在单个分块内从i * 327680递增到(i+1) * 327680 - 1，相邻分块的计数器区间刚好无缝衔接。

3.3 分块上传时的加密与落盘

前端拿到uploadId后，用类似POST /upload/chunk的接口逐块上传，参数至少包括：uploadId、chunkIndex、fileHash、chunkData。

服务端收到分块数据后，按上面的方法计算当前块的起始计数器，然后执行：

java复制Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
SecretKeySpec keySpec = new SecretKeySpec(dek, "AES");
IvParameterSpec ivSpec = new IvParameterSpec(buildCounterIV(nonce, startCounter));
cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);
byte[] encryptedChunk = cipher.doFinal(chunkData);

然后把这个encryptedChunk以临时文件或对象存储分片的形式保存，文件名里带上uploadId和chunkIndex，同时记录该分块的SHA-256摘要。

这里有一个重要的性能考量：Cipher对象的初始化开销不小，如果每个分块都从头初始化，性能会下降，但换来的是每个分块可以独立存储、独立校验，这个代价是值得的。如果文件很大、分块很小（比如1MB一块），初始化开销占比会更高，这时候建议把分块大小调到5MB~10MB。

3.4 合并与整体校验

所有分块上传完成后，前端调POST /upload/complete接口带上uploadId。

服务端按chunkIndex顺序读取所有分块密文，直接按字节拼接成完整的密文文件。注意，这里不是解密后再拼接，而是密文之间按位置拼接。因为前面加密时，每个分块的密文就是最终完整密文文件的一个连续切片，顺序拼起来就是完整密文。任何一块顺序错乱或缺失，直接导致最终文件解密错位甚至失败。

合并出完整密文之后，做三件事：

1. 对完整密文计算SHA-256，与各分块摘要做比对（其实分块已经校验过，这一步可做冗余校验）。
2. 计算完整密文的HMAC-SHA256，存入元数据。
3. 持久化元数据（uploadId、文件大小、IV、HMAC、DEK密文等），将密文正式归档。

合并过程中不要一次性把整个文件load进内存。用BufferedInputStream、BufferedOutputStream逐步读写，或者直接调用系统cat命令合并都行，但Java侧尽量用流式。

3.5 解密的对称流程

解密文件的流程是把上面倒过来：先通过元数据拿到IV、HMAC、DEK密文；用主密钥解开DEK；校验完整密文的HMAC；然后按字节流用AES/CTR/NoPadding解密。因为CTR模式的加解密代码完全一致，你可以复用同一套加解密方法，只要把ENCRYPT_MODE改成DECRYPT_MODE，其他逻辑几乎不动。

解密时如果遇到乱码，十有八九是计数器计算不对。这个在后面排查章节会细讲。

4. 核心代码实现：分块加密的完整闭环

4.1 依赖与基础配置

我用的是JDK 1.8+，加密这块不需要额外的第三方库，javax.crypto就够。但如果你想偷懒处理base64、Hex编码，可以引入commons-codec或hutool工具包。这里我尽量用原生JDK。

xml复制<dependency>
    <groupId>commons-codec</groupId>
    <artifactId>commons-codec</artifactId>
    <version>1.15</version>
</dependency>

其实byte[]和Hex转换我习惯自己写，就几十行，不额外引入包也行。看你自己习惯。

4.2 密钥派生与IV构建

先定义好工具方法。

主密钥（Master Key）可以配置在环境变量或KMS里，应用启动时加载一次。每次上传会话生成一个随机的DEK。

java复制public static SecretKey generateDEK() {
    byte[] keyBytes = new byte[32]; // AES-256
    SecureRandom random = new SecureRandom();
    random.nextBytes(keyBytes);
    return new SecretKeySpec(keyBytes, "AES");
}

IV我这里用12字节nonce + 4字节计数器的方案。初始化时随机生成12字节nonce，保存在元数据里。计数器在加密时按分块计算。

java复制public static IvParameterSpec buildIV(byte[] nonce, long counter) {
    ByteBuffer buffer = ByteBuffer.allocate(16);
    buffer.put(nonce); // 12字节
    buffer.putInt((int) counter); // 4字节
    byte[] iv = buffer.array();
    return new IvParameterSpec(iv);
}

注意counter是分块在加密时的起始计数器，它等于chunkIndex * blocksPerChunk。每个分块加密过程中，每次处理16字节的分组后，计数器要加1。

4.3 单分块加密的封装

核心方法是加密一个分块。这个方法接收原始分块字节、chunkIndex、DEK和nonce，返回密文和该分块摘要。

java复制public class ChunkCipher {
    private static final int BLOCK_SIZE = 16;
    private static final int CHUNK_SIZE = 5 * 1024 * 1024; // 5MB
    private static final int BLOCKS_PER_CHUNK = CHUNK_SIZE / BLOCK_SIZE;

    public ChunkEncryptResult encryptChunk(byte[] plainChunk, int chunkIndex,
                                           SecretKey dek, byte[] nonce) throws Exception {
        long startCounter = (long) chunkIndex * BLOCKS_PER_CHUNK;
        IvParameterSpec ivSpec = buildIV(nonce, startCounter);

        Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
        cipher.init(Cipher.ENCRYPT_MODE, dek, ivSpec);
        byte[] encrypted = cipher.doFinal(plainChunk);

        String chunkHash = DigestUtils.sha256Hex(plainChunk);
        return new ChunkEncryptResult(encrypted, chunkHash, startCounter);
    }

    public byte[] decryptChunk(byte[] encryptedChunk, int chunkIndex,
                               SecretKey dek, byte[] nonce) throws Exception {
        long startCounter = (long) chunkIndex * BLOCKS_PER_CHUNK;
        IvParameterSpec ivSpec = buildIV(nonce, startCounter);

        Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
        cipher.init(Cipher.DECRYPT_MODE, dek, ivSpec);
        return cipher.doFinal(encryptedChunk);
    }
}

注意两点：

第一，startCounter我用了long，因为单文件超过4GB时，块序号*每块分组数可能超过int范围。别贪省事用int，等到线上大文件出问题再改就晚了。

第二，chunkIndex从0开始。前端和这里要严格对齐，如果前端是从1开始的，所有计算全部错位，解密必然乱码。这个坑我踩过一次，后来在接口文档里直接标注：分块序号从0开始。

4.4 加密整个文件的服务端流程

下面给出一个相对完整的服务端流程，从init到complete用伪代码+Java混合的方式展示。

初始化接口：

java复制@PostMapping("/upload/init")
public InitUploadResponse initUpload(@RequestBody InitUploadRequest req) {
    String uploadId = UUID.randomUUID().toString().replace("-", "");

    // 1. 生成数据加密密钥
    SecretKey dek = generateDEK();

    // 2. 生成12字节随机nonce
    byte[] nonce = new byte[12];
    SecureRandom random = new SecureRandom();
    random.nextBytes(nonce);

    // 3. 用主密钥加密DEK，保存DEK密文
    byte[] encryptedDek = encryptDekWithMasterKey(dek);

    // 4. 保存到数据库/Redis：uploadId -> {encryptedDek, nonce, chunkSize, totalChunks等}
    uploadSessionStore.save(uploadId, new UploadSession(
        encryptedDek, nonce, req.getFileSize(), CHUNK_SIZE));

    return new InitUploadResponse(uploadId, CHUNK_SIZE, 
        computeTotalChunks(req.getFileSize(), CHUNK_SIZE), Hex.encodeHexString(nonce));
}

分块上传接口：

java复制@PostMapping("/upload/chunk")
public void uploadChunk(@RequestParam("uploadId") String uploadId,
                        @RequestParam("chunkIndex") int index,
                        @RequestParam("fileHash") String fileHash,
                        @RequestParam("chunkData") MultipartFile chunkData) throws Exception {

    // 1. 校验分块摘要
    String actualHash = DigestUtils.sha256Hex(chunkData.getBytes());
    if (!actualHash.equals(fileHash)) {
        throw new BusinessException("分块摘要不一致，请重传");
    }

    // 2. 获取上传会话里的DEK（内存中解密得到明文DEK）
    SecretKey dek = uploadSessionStore.getDek(uploadId);

    // 3. 加密分块
    byte[] encrypted = chunkCipher.encryptChunk(chunkData.getBytes(), index, dek, nonce);

    // 4. 追加落盘
    chunkStore.save(uploadId, index, encrypted);

    // 5. 记录分块元数据
    chunkStore.recordMeta(uploadId, index, actualHash, encrypted.length);
}

合并接口：

java复制@PostMapping("/upload/complete")
public CompleteResponse completeUpload(@RequestParam("uploadId") String uploadId) throws Exception {
    ChunkStore.Result result = chunkStore.merge(uploadId);
    
    // 1. 对完整密文计算HMAC
    byte[] wholeCipherBytes = result.getCipherBytes();
    byte[] hmac = HmacUtils.hmacSha256(dek, wholeCipherBytes);

    // 2. 保存最终元数据
    uploadMetaStore.save(uploadId, new FileMeta(
        result.getFileSize(), nonce, hmac, encryptedDek
    ));

    // 3. 清理临时分块
    chunkStore.cleanup(uploadId);

    return new CompleteResponse(uploadId, result.getFileSize(), Hex.encodeHexString(hmac));
}

合并部分我比较推荐流式拼接，不要为了省事把整个密文读进内存。

java复制public void merge(String uploadId, Path outputPath) throws IOException {
    try (FileOutputStream fos = new FileOutputStream(outputPath.toFile());
         BufferedOutputStream bos = new BufferedOutputStream(fos, 8 * 1024)) {
        for (int i = 0; ; i++) {
            byte[] chunk = readChunk(uploadId, i);
            if (chunk == null || chunk.length == 0) {
                break;
            }
            bos.write(chunk);
        }
        bos.flush();
    }
}

拼接完成后，如果你想对完整密文再算一次哈希做双保险，可以流式计算SHA-256，避免一次性读入内存。

4.5 加解密状态管理：为什么不能用“一把梭”的Cipher

这里补充一个实战中容易踩的坑：不要在一个Cipher实例上做增量update来加密多个分块。

CTR模式下，很多人为了省事，会初始化一次Cipher，然后每个分块来了就cipher.update(chunk)。这样虽然能正确加密第一个分块，但第二个分块的计数器是从第一个分块结束的地方继续的，一旦某个分块上传失败需要重传，或者分块顺序乱掉，加密位置就全错乱了。

正确做法必须是：每个分块独立初始化Cipher，指定它对应的计数器起点。这样每个分块加密只依赖(chunkIndex, nonce, dek)三个参数，天然支持乱序上传和重传。这也是块级加密相比整体流式加密最大的优势。

5. 性能、并发与异常排查实录

5.1 加密带来的体积和性能开销

CTR/NoPadding模式下，密文长度等于明文长度，没有padding膨胀，这是相比CBC模式的一个隐形福利。CBC用PKCS5Padding的话，每个分块都可能额外多出1~16字节，多块累积下来也不小。

性能方面，AES-256在支持AES-NI指令集的CPU上非常快。我实测过：用5MB分块，单线程加密速度大概在150~300MB/s（取决于CPU和JDK版本）。如果你用的是JDK 8u161+，默认已经开启AES-NI加速，不用额外配置。

真正的性能瓶颈通常不在加密，而在IO。如果密文直接写本地磁盘，建议分块数据先用ByteArrayOutputStream收集，加密完再一次性写入，避免多次小IO。如果要写对象存储（S3、OSS），每块一次PUT请求就好了，天然匹配分块上传模型。

5.2 分块上传的并发控制

分块上传天然适合并发。前端可以同时并发上传多个分块，那么后端最好有幂等控制。最朴素的做法是：每个分块落盘前检查该分块是否已经存在，如果存在且摘要一致，直接返回成功，不重复保存。

如果并发量很大，建议用ConcurrentHashMap维护一个uploadId -> ConcurrentSkipListSet<chunkIndex>的已上传集合，合并时从集合里拿全部分块索引。这个状态还可以配合Redis做分布式锁，避免多实例部署时重复合并。

5.3 内存溢出与缓冲区设置

用Java处理大文件，最容易撞上的就是OutOfMemoryError: Insufficient memory。分块上传虽然规避了“一次性读整个文件”，但如果你在代码里习惯性地把整个MultipartFile转成byte[]再处理，对于一块5MB问题不大，但如果分块设置成50MB，高并发下内存还是分分钟爆表。

正确做法是：能流式处理就流式处理，分块的最小单位是输入流。MultipartFile.getInputStream()拿到输入流，按缓冲区（例如64KB）循环读取并加密，再写出到临时文件。这样即使分块很大，内存占用也固定在缓冲区大小级别。

java复制try (InputStream in = chunkData.getInputStream()) {
    byte[] buffer = new byte[64 * 1024];
    int len;
    while ((len = in.read(buffer)) != -1) {
        byte[] encryptedPart = cipher.update(buffer, 0, len);
        bos.write(encryptedPart);
    }
    byte[] finalPart = cipher.doFinal();
    if (finalPart != null && finalPart.length > 0) {
        bos.write(finalPart);
    }
}

但是注意，流式加密时计数器同样要按“分块起始计数器 + 读取的分组数”计算，不能沿用我前面给的简单doFinal写法。如果直接对整块做doFinal，反而没有内存问题，因为它一次只塞一个分块（5MB）进内存，这个量级对现代服务端来说可以接受。

5.4 乱码、解密失败、分块顺序错乱排查清单

我遇到过最离谱的一个线上问题：前端框架把分块index从1开始传，后端按0开始加密，前99块都正常，第100块因为前端文件名排序错误，导致合并后文件从中间某处开始全乱。排查了几个小时，最后发现是分块序号对齐的问题，而不是加密算法出了问题。

所以强烈建议：在初始化接口返回totalChunks，让前端严格按0~totalChunks-1的序号来传，后端对超出范围的index直接拒绝。

5.5 密钥管理：比加密算法本身更重要的工程问题

AES算法本身很稳，出问题的地方几乎都在密钥管理。

所有分块共用一个DEK，DEK被主密钥加密保存。主密钥不能出现在代码仓库、配置文件或日志里，最好放在环境变量、KMS或者专门的密钥管理服务里。密钥轮换时，只需要重新加密DEK，不需要重新加密文件本身，这是信封加密最香的地方。

分块数据的明文DEK在服务端内存中保存的时间要尽可能短。每次上传分块时，从Redis或数据库中取出DEK密文，解密到内存，用完立刻置空引用，避免大量明文密钥滞留在JVM堆里。JVM堆转储（heap dump）时，要保证抓不到明文DEK。

另外一个安全细节：前端在生成fileHash时，用原始分块数据计算；后端在校验摘要时，必须在加密之前计算，否则一旦对密文算摘要，前端根本算不出来。

6. 分块上传框架的横向扩展思路

如果你的项目不是从零开发，而是想基于现成的框架做改造，可以参考下面这些思路。

6.1 基于MinIO/S3的多段上传模型

MinIO和AWS S3都内置了multipart upload API，它们本身把分块存储和合并做得很好。你要做的加密工作，主要是把“分块加密”这一层写在客户端或代理层，然后再把密文分块交给S3。

MinIO的Java SDK支持initiateMultipartUpload、uploadPart、completeMultipartUpload三个核心接口。你可以把每个分片在内存/临时磁盘上加密成密文，再通过uploadPart上传到MinIO，最终合并时所有分片依然是密文状态。这里要注意：S3的分片偏移是基于你上传的字节流的，所以计数器计算方式和我前面说的一致。分片大小建议使用5MB以上（S3最小分片为5MB），并且是16的整数倍。

6.2 本地临时文件分块模式

如果你没有对象存储，文件最终要存到本地磁盘，有一个折中方案：先接受明文分块，写入临时目录，合并完成后再对整个文件做一次加密。这个方案的优点是实现简单，缺点也很明显：临时目录里存在明文文件，一旦服务器被攻破或被运维误读，数据就泄露了。安全性要求高的场景不推荐。

如果临时明文无法避免，至少要做到：临时目录分配独立权限、定时清理、写入后立即chmod 600，以及给临时目录挂加密文件系统。

6.3 端到端加密与后端加密的取舍

严格意义上的端到端加密要求密钥在前端生成，服务端永远不接触明文，也永远不接触DEK。这样即使服务器被拖库、被代码审计，攻击者也拿不到能解密文件的密钥。但代价是：服务端无法对文件内容做任何处理（如分类、查重、压缩），用户在换设备时会遇到密钥丢失问题。

如果你做的是网盘类应用，端到端加密是加分项；如果做的是企业内部文件系统，服务端需要做内容过滤和审计，那多半会选择“后端持有DEK”的模式。我文章里给的方案是后者——服务端在主密钥保护下保管DEK。中间安全妥协点在于：主密钥必须守好，其他都好说。

7. 几个实际项目的经验笔记

最后整理几条专门给Java开发者的经验笔记，都是我实际跑过线上流量之后才体会到的。

• 分块大小不是越大越好，5MB是我试过比较均衡的值。太小（比如512KB）会导致分块数量巨大，HTTP请求数爆炸，接口吞吐反而下降；太大（比如50MB）会让重传成本变高，内存压力也大。
• 分块上传的鉴权与加密会话绑定。每个uploadId对应一个临时权限凭证，前端每次上传分块都带上这个凭证，后端验过凭证才允许读写。这样即使别人拿到分块下载地址，没有凭证也拿不到密文和解密密钥。
• 校验HMAC的时机要放在解密之前。解密本身是确定性的，但如果你先解密再看数据，遇到篡改文件时可能已经消耗了大量CPU，甚至抛出异常。先用HMAC验一遍再解密，更稳妥。
• 不要用String去接文件内容。不管是加密前还是加密后，文件内容都是字节流，用byte[]或InputStream处理。用String会涉及编码转换，可能在不知不觉中改变字节内容。
• 日志里别打印文件内容、DEK、IV。打印分块大小、uploadId、耗时这些都是安全的，但千万别把byte[]转Hex后打日志，线上日志泄露密钥的事我见过不只一次。
• 分块上传时的异常要分类处理。网络中断导致的IOException可以提示重试；摘要不匹配必须重传；密钥相关异常直接报错终止，不重试。把异常分类做好，前端就不用猜服务端到底哪里出了问题。

分块上传 + 加密存储，说到底不是某个算法炫技，而是把文件生命周期里的传输、存储、读取每一个环节都考虑进来，然后选择一个匹配业务场景的组合方案。AES/CTR + HMAC + 信封加密这套组合，是我目前觉得在Java技术栈里最省心、也最经得起推敲的做法。如果你在实际落地中遇到别的有意思的坑，欢迎带着场景来交流。