在Presto查询中加密/混淆结果的想法?

时间:2018-01-23 04:58:56

标签: sql encryption obfuscation presto

情景:

  1. 我有一个Presto表,我将查询和发送 结果给各个半信任方。
  2. 这些半信任方将分析数据并返回结果 回到我身边。
  3. 此表中的某些数据是"半私有" - 没有任何可能 如果它被发现会造成真正的伤害,但仍然是私人的(如设备的名称)。
  4. 这个"半私人"的签名数据对GROUP BY子句很重要,但实际数据本身对半信任方并不重要。
  5. 当这个分析的数据返回给我时,我需要能够解密/去混淆这个"半私有"数据以便采取行动。
  6. 问题:

    是否有人熟悉一种纯粹在Presto SQL查询中加密/混淆数据列的方法,以后可以以确定的方式对其进行解密/反模糊处理?

    我知道我可以轻松地对查询结果进行后期处理并自行加密/混淆,但我想尽可能利用Presto的分布式执行模型。

    加密/混淆的级别不需要是不可穿透的 - 只是比base64编码它复杂一点(最好是用一个简单的秘密)。

3 个答案:

答案 0 :(得分:0)

我认为您可以提供自己的UDF(用户定义函数),它可以进行一些对称加密。在这里,您有文档如何实现这样的功能:https://prestosql.io/docs/current/develop/functions.html,这里有一些Presto UDF的示例项目。

然后在Presto你可以:

SELECT decrypt_your_udf_function(private_column_encrypted, 'your password')FROM table;
INSERT INTO table (private_column_encrypted) SELECT encrypt_your_udf_function(private_column, 'your password') FROM ...

答案 1 :(得分:0)

经过一番研究后,我偶然发现了XOR cipher,这似乎完全可以在Presto数据库查询中实现。

我已经能够通过以下概念验证对其进行简要测试:

WITH

private_data AS (
  SELECT 'some private string' as private
),

encrypted_data AS (
  SELECT
  zip_with(
    regexp_extract_all(private, '.'),
    regexp_extract_all(substr('a27e6f329c03461688d6866203aasdljfasaslksa7982k3lkjsd987fok2jlkj0sdf9c59c', 1, length(private)), '.'),
    (x, y) -> 
      bitwise_xor(codepoint(cast(x as varchar(1))), codepoint(cast(y as varchar(1))))
  ) as encrypted_data
  FROM private_data
),

decrypted_data AS (
  SELECT
  array_join(
    zip_with(
      encrypted_data,
      regexp_extract_all(substr('a27e6f329c03461688d6866203aasdljfasaslksa7982k3lkjsd987fok2jlkj0sdf9c59c', 1, cardinality(encrypted_data)), '.'),
      (x, y) -> 
        chr(bitwise_xor(x, codepoint(cast(y as varchar(1)))))
    ),
    ''
  ) as decrypted_string
  FROM encrypted_data
)

SELECT
*
FROM private_data, encrypted_data, decrypted_data

它似乎有效,尽管我希望更多地简化它。任何人都可以看到优化它的方法吗? (例如:从长度为1的varchar投射到varchar(1)似乎很荒谬,但如果我不这样做就会抱怨。regexp_extract_all是我能找到的唯一方法将varchar转换为数组。)

答案 2 :(得分:0)

我创建了一个示例项目,该项目具有用于基本加密和解密的UDF,您可以找到它here。 以下是一些想法:

  1. 使用AWS KMS加密和解密数据。对于加密,如果我们可以动态获取KMS密钥ID,而不是将其作为输入或存储在jar本身中,则更好。
  2. 如果那太昂贵了,那么替代方法是开发自定义加密逻辑并将其用于presto UDF代码中。