# ManManger
###### tags: `文件` `2019` `密碼學`
<p>
<a href="">
<img src="https://img.shields.io/badge/go-1.13.5-blue" />
</a>
<a href="https://github.com/dennySORA/mansecret">
<img src="https://img.shields.io/badge/ManSecret-v0.5-brightgreen" />
</a>
</p>
###### Topic : File Management Software Programming Project
###### Project Name : ManManager
---
## Introduction
從『勒索軟體』來的一個發想，如果說『勒索軟體』的本質其實是『加密軟體』。
那針對需要的話，能將資料加密儲存防止被偷竊或者防止被『勒索軟體』加密（PS.勒索軟體會針對已知的副檔名加密。），並分散切個的儲存。
並且能將其服務化，成為離線、線上都能使用的一套檔案管理裝置。
擴大功能用還能做到『自動備份』、『檔案管理』、『分類標籤』、『重副檔案管理』、『自動分類』等。
## Methods
- 加密資料：利用加密來達到防止被竊取或偷看。
- 資料分割：將其分割後能做無法移動單一檔案。
- 資料管理：能管理這些加密後的資料，有能力做即時檔案名稱預覽（必須要有解密文件）。
- 伺服器化：將提供不同介面與連往取得功能。
---
## Develop OverView
- Langange : Golange
- Software Architecture : microservice
- Data exchange:
- System Inside:
- MQ
- RESTful
- gRPC
- Open:
- RESTful
- WebSocket
- Server :
- TLS 1.3
- Diffie–Hellman key exchange
- X25519
- P-512
- P-384
- P-256
- Header Add
- HSTS Preload List
- OAuth 2.0
- JWT(one time password)
- Use cipher
- AES128
- AES192
- AES256
- CTR
- Generat VI
- Use Hash
- SHA2_512
- SHA2_256
- HMAC_512
---
## 設計架構
##### 設計理念：
為何要將檔案分成兩大部分（Pageman 與 Dataman）。
1. 可以看到檔案目錄，同時減少一次過多檔案的解碼問題。
2. 方便擴充資料。
3. 檔案的部分能隨意切割管理。
4. 防止當目錄被人知道卻也無法得到檔案。
5. 可以減少專門解開檔案的 Key 頻繁傳送。
結論就是『為了方便管理檔案。』
### File Pageman
再將檔案名稱加密與登入機制分開。
#### File Name part:
##### 設計理念：
File Page 可擴充其他資訊（如：圖片、擁有者等等的。）
可以增加"資料夾結構"的資訊。
檔案統一由 FileLink 來連結。
```
File Name -> File Page {
FileName : (string) [File Name]
FileData : (string) [File Date]{Can use utc int.}
FileLink : (string) [Is First File Pack Path.]
} -> ConvertToJSON ->
AES256(FilePageJSON,PrivateKey) -> {Page File Contents.}
HMAC512( SHA512(FilePageJSON), (ServerKey||UseID) ) -> {Page File Name.}
```
##### 設計理念：
利用 PrivateKey 來加密 PageFile 的檔案。
檔案名字的部分由"ServerKey"（由伺服器的安全 Key，以認證伺服器）與 UseID 合成。
然後對 Hash 的檔案在使用 Key 雜湊訊息鑑別碼生成出不可逆的檔名。
解開時可以再次驗證檔案完整性，以防止串改。
---
#### File Page Key part:
#### 設計理念：
系統的密碼與使用ID跟自己的密碼與帳號毫無相關。
可以達到無法得知此ID跟人的關連性。
而且內部使用的PrivateKey（256bit）與UseID（256bit以上）長度與混亂度安全性才夠高。
而且密碼可直接Hash完之後傳過來。
附帶的PageKeyFile也保證了其長度安全性。
而且這樣也能使『改密碼』、『改PageKeyFile』、『改ID』變得可行且快速。
三大保護機制：
1. 密碼可直接Hash傳至Serevr。
2. Server所使用的密碼與ID都是系統生成的，使用者也拿不到，長度也很安心。
3. 三樣資料缺一不可（ID、密碼、文件）。
```
ID,Password,PageKeyFile -> AES256(PageKeyFile, SAH256(ServerKey) ) ->
PageKeyFile {
ID : (string) [ID] {Need match input ID.}
EncryptKey : (string) [Is Page Key Struct Daat]{Need Decrypt Data.}
}(EncryptKey)->
AES256(EncryptKey, SHA256(ID||SHA512(Password)||ServerKey) ) ->
PageKey {
UseID : (string) [Server create]{default length 256 bit,Can set length.}
PrivateKey : (string) [Server create]{length 256 bit}
}
```
---
### File Dataman
資料加密解密可是精華的部分了。
分為『資料加密』、『資料切割』、『資料連結加密』。
但必須先將前置作業完成。
#### 前置作業
必須準備：
1. Data （廢話……）
2. UesID （必須由Pageman提供。）
3. LinkKey （必須由Pageman與Server提供。）
4. LinkCode （如果沒有提供則為"0000"主要是為了個別檔案的提取碼。）
5. HFileDataKey （必須由Pageman跟Client提供。）
**Link Key** 製作方式：
```
SHA512(ServerKey||UseID||SHA512(File Name)||LinkCode)
```
目的是為了確保『使用者』與『檔案目標（Page必須要跟Data有連結性）』。
**HFileDataKey** 製作方式：
```
SHA256(LinkKey||FileDataKey)
```
目的除的跟檔案確保之外，每個檔案的密碼都會不同。
##### 議題：
1. 如果同檔名同使用者不同資料會怎樣？
2. 如果同檔名同使用者同資料會怎樣？
#### Data Split part
```
SHA512(File Data) -> {Hash File Data}
AES256(File Data,HFileDataKey) -> EncryptedFileData
SHA512(EncryptedFileData) -> {Hash Encrypted File Data}
EncryptedFileData -> Split(EncryptedFileData) -> EncryptedFileData{Pack1,Pack2,Pack3....,PackN}
SHA512(EncryptedFileData{PackN}) -> EncryptedFileDataHash{PackN} ->
```
#### Data Pack Link part
```
SplitEData {
FileLink : (string) [必須演算]
PackData : (string) [EncryptedFileData{PackN}]
} ->
AES256(SplitEData{PackN},PackKey) -> {Data File Pack Contents.}
FileLink{上一筆} -> {Data File Pack Name.}
```
##### 目的：
每個檔案的名字都是連結，而連結的方式都長在了File Link內部。
而第一筆的File Link會回傳給File Page作為檔案第一個Pack的連結入口。
而解開第一個Pack後才可得到下一個PackLink。
**FileLink** 製作方式：
```
SHA256(LinkKey||EncryptedFileDataHash{自己}||EncryptedFileDataHash{下一筆}||Count{第幾包})
```
PS. **第一筆的FileLink** 製作方式：
```
SHA256(LinkKey||{Hash File Data}||EncryptedFileDataHash{自己}||Count{0})
```
PS. **最後一筆**不需要FileLink 因此不會超過Pack的數量。
議題： 為何第一筆需要？且特別製作？
答：為了將File Data的驗證Hash藏在第一筆資料中。
**PackKey** 製作方式：
```
SHA256(ServerKey||EncryptedFileDataHash{上兩筆})
```
PS. **第一筆的PackKey** 製作方式：
```
SHA256(ServerKey||{Hash Encrypted File Data}||SHA512(FileName))
```
PS. **第二筆的PackKey** 製作方式：
```
SHA256(ServerKey||{Hash Encrypted File Data})
```
##### 議題： 為何要設定成上兩筆？
答：
當惡意者隨機取得一個包，然後就真的被他解開了。
這時雖然知道了下一筆的位子，但要解開這個包需要上一筆的Hash的資料。
因此無法往下解。
## 安全相關
- [X25519](https://security.stackexchange.com/questions/50878/ecdsa-vs-ecdh-vs-ed25519-vs-curve25519)
- [SSL Server Rating Guide](https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide)
- [SSL and TLS Deployment Best Practices](https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices)
## Contributors
* [DennySORA](https://github.com/dennySORA)
Sign in with Wallet
Connect another wallet