西西河

主题:【原创】云里雾里的云计算 [1] -- 邓侃

共:💬620 🌺1262
分页树展主题 · 全看首页 上页
/ 42
下页 末页
                  • 家园 了解了,多谢。 另:我早就不是技术人士了。呵呵
                  • 家园 在基础架构层加密和不加密没什么区别

                    1、加密的目的是要保密,这必须在信息生成的时候就加密,并且不能在最终用户读取前进行解密,这在原理上决定了,加密和检索是不相容的(也许可有单独的非加密关键字,但是对正文的全文检索肯定不行的)

                    2、如果在Google的在基础架构层加密和不加密没什么区别。因为从技术上看,只要Google能解密就是不安全的。如果Google不能解密,那么也就不能检索。


                    本帖一共被 1 帖 引用 (帖内工具实现)
              • 家园 加密与检索解决方案四:安全托管法。

                实际是“加密与检索解决方案二:分段解决方案”的一个修正:

                将方案二中放在公司端的加解密、检索机器,托管到google,此机器安全级别设到军方的B2级别,保证google打不开。

                就是不知道google怕不怕来的是个内鬼、倒偷它的东西。 呵呵

              • 家园 加密与检索解决方案三:结合加密算法(可能根本行不通)

                前言:本人对加密算法不甚了解,可能有错误理解,望专业人士予以指正。

                思路来源第一部分:

                当登录UNIX系统时,个人设定自己的口令,系统将口令予以加密,保存在\etc\password文件下,此文件对系统管理员可见,但不知道口令明文。

                举例说明:

                某用户:user,设置口令明文:password,口令经系统加密后为some_char_string_1. 在\etc\password文件内可见:

                user some_char_string_1,

                而系统管理员无从知道用户user的口令明文就是password。

                当用户user登录时,系统自动按算法对输入的口令进行加密处理,得到some_char_string_2. 系统读取\etc\password,进行比对判断,如果some_char_string_2 = some_char_string_1,则系统认为口令合法,准许用户user登录。

                思路来源第二部分:

                系统的加密机制就是RSA加密算法,加密系统是公开的,但密钥分两部分:密钥1、密钥2。密钥1加密钥2才是全部密钥,才能解出明文。

                所以,当UNIX对用户口令加密时,实际是用用户user的口令password做密钥1,再加上系统内置的密钥2组成完成的密钥,处理后得到加密后的口令user some_char_string_1保存在\etc\password。

                注:这部分主要是说加密的内容,google在不知道全部密钥的情况下,对密文不可解。

                基于以上,还是分三个层面:个人端、公司端、google端。

                个人端执行文件编辑,保存有密钥1,公司端保存密钥1、密钥2,google端负责建立检索、保存索引、执行索引或全文索引,并且执行文件分布式管理。

                流程:

                1. 个人A,用office编辑了一份文件a,透明加密保存在google。 此文件是经密码1、密码2共同处理的密文。

                2. 个人B,要求检索,公司端截获检索内容,用密钥1、密钥2对进行处理,得到char_string_2,有公司端发送给google进行检索。 并将结果返回个人B。 或者

                3. 个人B,要求检索,将检索内容发送公司端,获得char_sting_2,发送给google进行检索。 并将结果返回个人B。

                核心:google保存加密后的密文,检索内容在google外加密处理,将处理结果交google对保存的密文进行匹配、检索。

                疑问:

                明文实际是有规律可循的,如通常英语句子中字母出现的频率是不同的,而密文实际上是消除了这种规律。 所以将加了密的检索内容交google对加了密的内容检索,是否还能成功呢?

                或者结合密钥1、密钥2的设置,是否可以在google端既能加密、而又能检索呢?

                结论:

                不知,这要靠了解加密的朋友给予解答了。 呵呵

                • 家园 对加了密的文档,搜索引擎内部的倒排索引目前无法建

                  搜索引擎之所以能搜索关键词,是因为其内部建了一个倒排索引(inverted index)。

                  譬如在一堆文档中,有一个编号为101的文档。某个关键词“西西河”,在它的第230字节处,第339字节处等等位置出现过。

                  当用户搜索“西西河”,搜索引擎在倒排索引中一查,发现在101文档中,出现过“西西河”这个词,于是返回给用户101文档的URL。

                  假设,我们预先对101文档加了密,那么建倒排索引的时候,怎样才能知道第230字节处,第339字节处等等位置出现过“西西河”这个词呢?

                  现在没有办法解决这个问题。

                  进一步讲,除非对倒排索引的数据结构,以及搜索引擎查询的算法做大手术,否则,即便有办法解决上述问题,也是不能用的。为什么呢?

                  如果倒排索引能够知道在加了密的101文档中,每个字节处是什么单词,那么就不难复原,加了密的101文档的原始内容。换句话说,对101文档加密,就变得毫无意义了。

              • 家园 加密与检索解决方案二:分段解决方案

                分三个层面:个人端、公司端、google端。

                个人端执行文件编辑,公司端建立检索、保存索引、执行检索或全文检索,google端执行文件分布式管理。

                流程:

                1. 个人A,用office编辑了一份文件a,透明加密保存在google。

                2. 同时此文件为公司端获取,建立索引。

                3. 个人B,要求检索,公司端直接检索,将结果返回个人B。 或者

                4. 个人B,要求全文检索,公司端获取从google获取所有指定搜索范围内文件,在公司端解密、检索,将结果返回个人B。

                核心: 加密策略是公司制定的,所以个人加密的部分,公司是完全可解的。

                优点:没有解密内容透露给google。

                缺点:公司端另安装有google search全索引引擎,全文检索时公司、google间网络开销巨大,IT投入、维护依然是公司的一项管理内容。

                结论:这是个半完美的解决方案。 问题在于本应有google做的检索工作,因为保密要求,移到了设在公司内的搜索引擎。

              • 家园 加密与检索解决方案一:市场定位,先取无加密需求的。

                如我在前端提到:

                1. 市场定位做区分:普通用户,价格敏感用户,好新鲜用户。普通办公文档,其实docs就ok了,没必要用到office顶级功能。

                邓太提到的:

                当时,Google把Apps转向这些中小企业用户之后,注册率疯狂上升

      • 家园 没想到华人有这样的大才,还是一代的。 呵呵

        新的两位掌门人中,有一位是我们中国人,毕业于复旦大学的陆奇。从复旦毕业后,陆奇留学美国CMU,攻读博士学位。博士学位拿到后,经历了短暂的动荡,1998年陆奇加盟Yahoo。他从工程师干起,扎扎实实,一路升到副总裁。2009年1月,陆奇学长离开Yahoo,出任微软Online Services Group的president。他的职责是,领导微软对抗Google。

      • 家园

        学习

      • 家园 SF 花

分页树展主题 · 全看首页 上页
/ 42
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河