Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3649A10A25 for ; Mon, 2 Dec 2013 09:07:45 +0000 (UTC) Received: (qmail 85858 invoked by uid 500); 2 Dec 2013 09:07:38 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 85780 invoked by uid 500); 2 Dec 2013 09:07:35 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 85749 invoked by uid 99); 2 Dec 2013 09:07:35 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Dec 2013 09:07:35 +0000 Date: Mon, 2 Dec 2013 09:07:35 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-10065) Stronger validation of key unwrapping MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Andrew Purtell created HBASE-10065: -------------------------------------- Summary: Stronger validation of key unwrapping Key: HBASE-10065 URL: https://issues.apache.org/jira/browse/HBASE-10065 Project: HBase Issue Type: Improvement Reporter: Andrew Purtell Assignee: Andrew Purtell Priority: Minor Fix For: 0.98.0 In EncryptionUtil#unwrapKey we use a CRC32 to validate the successful unwrapping of a data key. I chose a CRC32 to limit overhead. There is only a 1 in 2^32 chance of a random collision, low enough to be extremely unlikely. However, I was talking with my colleague Jerry Chen today about this. A cryptographic hash would lower the probability to essentially zero and we are only wrapping data keys once per HColumnDescriptor and once per HFile, saving a few bytes here and there only really. Might as well use the SHA of the data key and in addition consider running AES in GCM mode to cover that hash as additional authenticated data. -- This message was sent by Atlassian JIRA (v6.1#6144)