# Block-R

**Repository Path**: zjxtim/Block-R

## Basic Information

- **Project Name**: Block-R
- **Description**: Block-R加密算法的实现程序
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 1
- **Created**: 2018-03-23
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

2018年5月30日14:57:07
发现的问题有：
1、第0片经过计算G的过程后仍然当做其他普通片一样进行加密？
2、更换块时新的块基础秘钥是和之前的BR算法一样计算吗？
3、解密时发现计算出来的G和加密时计算的G不一样，在人为地使得加解密时的G相同时能正确解密，因此认为不同的G会导致解密后仍为乱码，解密时的G计算方式有误。
4、解密时会有不可控制的逻辑
a情况：原文最后一片长度∈(0,125)，正常填充。解密时分别对最后一片，倒数第二片解密。分别在两片中搜索icCode，在最后一片中找到，正确完成解密操作。
b情况：原文最后一片长度等于125。该片被icCode直接填充至128字节，还需要添加新片吗？添加新片的话该片由128个字节的随机数构成。解密时判断previous是否有icCode，如果有那就舍去最后一片。
c情况：原文最后一片长度∈[125,128)，添加新片，分别填充。解密时分别对最后一片，倒数第二片解密。分别在两片中搜索icCode，在两片中都找不到完整的icCode，
在前一片（previous）片中对第125，126和127个字节进行最大公共子串判断，找出icCode的填充起点。起点之后包括最后一片全部舍去不输出。（previous片中的置0，最后一片直接放弃不输出）
b、c情况时就会出现问题，previous早在这之前就已经输出了，末尾的[1,3]个字节的icCode已经输出了。