EncryptByPassPhrase()
を使用して、主にVARCHAR
値で暗号化プロジェクトを開始しています。当然、暗号化された値は元の値よりも長くなります。元のVARBINARY
フィールドの可能な値を保持するために、新しいVARCHAR
フィールドを作成するのに必要な時間を計算するために使用できる式はありますか?
たとえば、最初に調べたフィールドには最大37文字の値があり、暗号化された値は最大100バイトです。もう1つは最大50文字の値で、暗号化された値は最大124バイトです。ただし、2〜3文字の短い値では、76バイトに暗号化できます。新しいフィールドのサイズを75 + Xバイトにした場合、長さX以下の可能なテキスト値の暗号化バージョンを保存する余裕がありますか?
私のテストに関する限り(SQL Server Express 2014、SP1およびSQL Server Developer 2012 SP2を使用し、どちらも64ビット)、式whennotオーセンティケーターの使用戻り値(VARBINARY
)の長さ:
_ENCRYPTBYPASSPHRASE('_My_PassPhr@zE_yo_', {anything})
_
です:
_28 + (8 * (DATALENGTH(@ClearText) / 8))
_
以下を試してください:
_DECLARE @ClearText VARCHAR(8000);
SET @ClearText = 'testdfdf gkdj flkgjdlfkgjdlf gjlf gklf TE%$%^&^%HFGHFhg fkgh jfgkhæ';
SELECT LEN(ENCRYPTBYPASSPHRASE('_My_PassPhr@zE_yo_', @ClearText)) AS [ActualLength],
28 + (8 * (DATALENGTH(@ClearText) / 8)) AS [EstimatedLength];
_
戻り値:
_ActualLength EstimatedLength
92 92
_
また、_@ClearText
_のデータ型をNVARCHAR(4000)
に変更して再度実行すると、次のように返されます。
_ActualLength EstimatedLength
156 156
_
注:式looksのように、_8
_ sをキャンセルすることで削減できます。ただし、「バケット」に収まるデータ長のバンド範囲であるため、正しく機能しません。
_input bytes result length
----------- -------------
1 - 7 28
8 - 15 36
16 - 23 44
24 - 31 52
_
したがって、数式の_(DATALENGTH(@ClearText) / 8)
_の部分では、値が丸められるのではなく、10進数の値が無視されるようになっています。そして、それは2つのINT値を分割するというデフォルトの動作によって達成されます;-)。
UPDATE:
上記で行ったテストでは、 [〜#〜] encryptbypassphrase [〜#〜] に使用できるオプションを使用していません。「認証者」を指定しています。そうすることで、最小長に16バイトが追加され、増分は依然として8バイトステップであり、バンド範囲はそれぞれ8バイトですが、初期範囲は4バイトのみなので、範囲は4だけオフセットされます。オーセンティケーターを使用しない場合の範囲の境界と比較。わかりやすくするために、次のグラフは範囲とそれに対応する結果の長さを示しています。
_input bytes result length
----------- -------------
0 - 3 44
4 - 11 52
12 - 19 60
20 - 27 68
_
式認証子を使用する場合の戻り値(VARBINARY
)の長さ:
_ENCRYPTBYPASSPHRASE('_My_PassPhr@zE_yo_', {anything}, 1, {anything_1-128_bytes})
_
です:
_44 + (8 * ((DATALENGTH(@ClearText) + 4) / 8))
_
ノート:
PassPhrase
の長さは結果の長さに影響しませんPassPhrase
の空の文字列は結果の長さに影響しませんAuthenticator
値を有効にするには、_Add_Authenticator
_(3番目の入力パラメーター)の値を_1
_に設定する必要がありますAuthenticator
の長さは、結果の長さに影響しません少なくとも1である限り。Authenticator
の空の文字列は結果の長さに影響し、その影響は_Add_Authenticator
_を_0
_に設定することと同じです。Add_Authenticator
_が_0
_に設定されている場合、またはAuthenticator
が空の文字列またはNULL
である場合、式は「認証子」がない場合と同じです。以下は、「オーセンティケーター」がある場合とない場合の両方を示し、_@PassPhrase
_値を簡単に変更できるようにする拡張および改善されたテストです。
_DECLARE @ClearText NVARCHAR(4000),
@Authenticator sysname,
@PassPhrase VARCHAR(100);
SET @PassPhrase = '_My_PassPhr@zE_yo_';
SET @ClearText = 'testdfdf gkdj flkgjdlfkgjdlf gjlf gklf TE%$%^&^%HFGHFhg fkgh jfgkhæ';
SET @Authenticator = REPLICATE(N' ', 128);
SELECT LEN(ENCRYPTBYPASSPHRASE(@PassPhrase, @ClearText))
AS [ActualLengthSansAuthenticator],
28 + (8 * (DATALENGTH(@ClearText) / 8)) AS [EstimatedLengthSansAuthenticator];
SELECT LEN(ENCRYPTBYPASSPHRASE(@PassPhrase, @ClearText, 1, @Authenticator))
AS [ActualLengthWithAuthenticator],
44 + (8 * ((DATALENGTH(@ClearText) + 4) / 8)) AS [EstimatedLengthWithAuthenticator];
_
Enryptbypassphraseで暗号化した後、varbinaryデータの長さを決定するためにこれに遭遇しました
CEILING((CAST(DATALENGTH(@cleartext) as float) + 1) / 8) * 8 + 20
これは科学的ではありません。科学的な答えを得る唯一の方法は、SQL Server開発者が3DES 128アルゴリズムの実装に使用したコードを調べることです。
そうは言っても、暗号化されたテキストの実際の長さを決定しようとする簡単なテストリグを構築しました。
_;WITH Num1
AS
(
SELECT TOP(4000) rn = ROW_NUMBER() OVER (ORDER BY o.object_id, o1.object_id)
, pwd = REPLICATE('x', ROW_NUMBER() OVER (ORDER BY o.object_id, o1.object_id))
FROM sys.objects o, sys.objects o1
)
, Num2
AS
(
SELECT TOP(4000) rn = ROW_NUMBER() OVER (ORDER BY o.object_id, o1.object_id)
, dat = REPLICATE('x', ROW_NUMBER() OVER (ORDER BY o.object_id, o1.object_id))
FROM sys.objects o, sys.objects o1
)
SELECT Encrypted = ENCRYPTBYPASSPHRASE(pwd,dat,1,CONVERT(VARBINARY(20), ROW_NUMBER() OVER (ORDER BY num1.rn, num2.rn)))
, EncryptedLength = LEN(ENCRYPTBYPASSPHRASE(pwd,dat,1,CONVERT(VARBINARY(20), ROW_NUMBER() OVER (ORDER BY num1.rn, num2.rn))))
, RowNum = ROW_NUMBER() OVER (ORDER BY num1.rn, num2.rn)
, DatLen = LEN(dat)
, Diff = LEN(ENCRYPTBYPASSPHRASE(pwd,dat,1,CONVERT(VARBINARY(20), ROW_NUMBER() OVER (ORDER BY num1.rn, num2.rn)))) - LEN(dat)
FROM Num1, Num2;
_
これにより、1〜4000バイトのさまざまな長さのパスフレーズとデータが生成され、ENCRYPTBYPASSPHRASE
関数の出力と入力データの長さが比較されます。私のコンピューターでは、出力に41〜48バイトの「余分な」バイトがあることがわかりました。
そうは言っても、フィールドサイズとしてVARBINARY(8000)
を使用することをお勧めします。これは、関数に対して定義された最大出力であるためです。