Century's Blog

前言文章动机 纯密码方案（CryptDB、Arx）开销大，功能少 TEE方案： EnclaveDB、ObliDB安全性高但效率相对差 Always-encrypted、StealthDB这类non-intrusive方案泄露的信息使其容易遭受攻击 贡献 提出多种在存储引擎上优化的设计，进而在安全、效率和功能性上做trade-off以达到enclave-native 将多种不同存储引擎设计融合一起（即本文的Enclage），可以缓解ciphertext amplification 设计合适的page size、用delta encryption来减少开销 巧妙设计index和table的执行逻辑以减少上下文切换 TEE-SGX 由于AMD SEV不支持remote attestation，因此选择更为成熟的SGX SGX面临的挑战 enclave中有限的内存空间 enclave与non-enclave之间的切换开销 TCB(trusted computing base)的大小选择 侧信道攻击等（不属于做encrypted database人的范畴里，忽略） Enclabve- ...

写在前面对于还未完全实现的同学们，切忌直接面向测试编程！在着手实现前，一定要想好需要实现的函数的框架，以及其需要满足的功能。有一些功能的实现是需要对buffer pool有一定的理解，而不是简单地根据注释中的guideline就上手做，对于需要实现的功能有一定的理解再去实现能大大减少debug的时间。（说来都是泪呀…）此外，Project 1需要实现下面三个task： Extendible Hash Table：可扩展哈希表 LRU-K Replacement Policy：基于LRU-K的页替换策略 Buffer Pool Manager Instance：管理上面所实现的1、2，实现buffer pool的基础操作 Extendible Hash Table定义先明确可扩展哈希表的定义，首先它是一个可以存储key-value键值对的数据结构，由一个可延长的链表加上对应的Bucket实现。可见Extendible Hashing (Dynamic approach to DBMS) - GeeksforGeeks中的详细解释。 为什么用？了解了可扩展哈希表的定义后，知道为什么使用 ...

写在前面：最近写代码的过程中发现自己对Git的使用仅限于clone、add、commit之流，对于需要重构或者需要修改BUG的部分没有很好地用到Git的分支进行管理，故在之前学习git分支中学了一下，在此记录一下。<由于时间有限还没学完，这里仅解释其中一部分内容，后续补充> 基础篇Commit根据当前目录中的文件内容与上一个版本中的文件内容进行对比，差异化地添加文件。当执行此命令时HEAD会跟随当前分支追加节点，使其指向其父节点。git commit xxx：提交暂存区中的内容 Branch分支即指向某个提交的记录，多分支协同工作在实际开发中是十分有用的（圣经：早用分支，多用分支）。对于分支，可以将其理解为在当前节点及其父节点的基础上更改。git checkout <name>：切换到名为name的分支上git checkout -b <new-branch-name>：创建新分支并切换过去 Merge对于多个分支负责不同功能，应有支持将多个分支合并在一起的操作，merge便可完成这种事。git merge <branch-name>：将 ...

前言为什么提出？解决在加密数据库上的高效检索（要practical，不能只停留在学术层面）。 解决了什么问题？本篇文章定义了两种威胁： 第一种是内部攻击，比如对于不可信的DBA/管理员用户，其偷偷窃取/窃听数据所存在的威胁 第二种是敌手通过某种手段拿下整个application以及DBMS的控制权，保证目前状态下的数据隐私问题 怎么做的？通过SQL查询，在用户和DBMS中间加了一层proxy server来对用户查询的SQL进行一定的处理，最终将需要查询的数据透明返回给查询用户，其系统架构如下： 为解决以上两种问题，本文提出三种解决措施： SQL-aware encryption strategy 根据SQL语句有清晰结构的特点，让CryptDB能够对加密数据库执行简单的SQL操作 adjustable query-based encryption 避免信息泄露，对于不同的查询，CryptDB在运行态对其分析处理，并提出了洋葱加密 chain encryption keys to user passwords 访问控制，在威胁二下将密钥成串连接起来 ...