در عمل، Tink اشیای Key را برای نمایش
کلیدها و اشیای Parameters را برای نمایش Parameters ارائه میدهد.
برای مثال، در Java، ما اشیاء AesGcmKey را داریم که
کلیدهای AES GCM را نشان میدهند.
در این بخش، توضیح میدهیم که این اشیاء چگونه در Java طراحی شدهاند و چگونه با یکدیگر تعامل دارند.
Parameters شیء
AES GCM را درنظر بگیرید که یک طرح رمزگذاری AEAD پرکاربرد است.
Tink یک شیء AesGcmParameters با اطلاعات لازم برای ایجاد AesGcmKey ارائه میدهد که بعداً توضیح میدهیم.
سلسلهمراتب پارامترها در Java بهصورت زیر است:
public abstract class Parameters {
public abstract boolean hasIdRequirement();
}
public abstract class AeadParameters extends Parameters {}
public final class AesGcmParameters extends AeadParameters {
/**
* The Variant specified how ciphertexts are [tagged](/tink/design/keysets#tagging_ciphertexts).
*/
public static final class Variant {...}
/** A helper object to create new AesGcmParameters. */
public static final class Builder {...}
public int getKeySizeBytes() {...}
public int getIvSizeBytes() {...}
public int getTagSizeBytes() {...}
public Variant getVariant() {...}
public boolean equals(Object object) {...}
public int hashCode() {...}
}
همانطور که در بخش
مجموعهکلیدها، برچسبگذاری متنهای رمزی توضیح داده شد،
برخیاز کلیدها وقتی در مجموعهکلید قرار دارند، برای شناسه خود الزامی دارند. هر
شیء Parameters دارای روش hasIdRequirement است که مشخص میکند آیا
کلید ایجادشده توسط این شیء Parameters چنین شناسه الزامیای خواهد داشت یا نه.
شیء AesGcmParameters سپس روشهای getKeySizeBytes()،
getIvSizeBytes()، و getTagSizeBytes() را ارائه میدهد. اینها طول کلید استفادهشده، طول IV استفادهشده، و طول برچسب تولیدشده را برحسب بایت برمیگردانند. اگرچه Tink برخیاز این توابع را برای کامل بودن ارائه میدهد،
همیشه اجازه ایجاد Aead برای هر انتخاب را نمیدهد. برای مثال، درحالحاضر
فقط IVهای ۱۲ بایتی برای AES GCM پشتیبانی میشود.
شیء AesGcmParameters همچنین جایگزینهایی برای روشهای تعریفشده قبلی (و روشهای استاندارد جاوا equals و hashCode که بهعنوان روش خوب درنظر گرفته میشود) ارائه میدهد.
درنهایت، روشهای ثابتی برای ایجاد اشیاء AeadParameters جدید ارائه میدهد.
اینها ورودیها را اعتبارسنجی میکنند، یعنی بررسی میکنند که اندازه یکی از مقادیر ۱۶، ۲۴، یا ۳۲ باشد.
اشیای کلیدی
Tink همچنین دارای سلسلهمراتب کلید است. با ادامه دادن مثال AES GCM، اینگونه بهنظر میرسد:
public abstract class Key {
public abstract Parameters getParameters();
public abstract @Nullable Integer getIdRequirementOrNull();
public abstract boolean equalsKey(Key other);
}
public abstract class AeadKey extends Key {
public abstract AeadParameters getParameters();
public abstract Bytes getOutputPrefix();
}
public final class AesGcmKey extends AeadKey {
public SecretBytes getKeyBytes();
public Bytes getOutputPrefix();
public AesGcmParameters getParameters();
public @Nullable Integer getIdRequirementOrNull();
public boolean equalsKey(Key object);
}
روش getIdRequirementOrNull شناسهای را که این کلید باید داشته باشد برمیگرداند،
یا اگر الزامی وجود نداشته باشد، null را برمیگرداند.
(چنین الزامی برای کلید از این واقعیت ناشی میشود که Tink در برخی موارد
پیشوند رمزنگاری یا امضاها را با رشته 0x01<id> اضافه میکند، به بخش
برچسبگذاری رمزنگاری مراجعه کنید).
این همیشه با نتیجه
getParameters().hasIdRequirement() سازگار خواهد بود و پیادهسازان کلاسهای کلید جدید باید این را تضمین کنند.
پیادهسازیهای Key همچنین باید روشی equalsKey برای مقایسه کلیدهای مختلف ارائه دهند. چنین
روشی اغلب مفید است: برای مثال هنگام آزمایش اشتقاق کلید، فرد
علاقهمند است اطمینان حاصل کند که اعمال مکرر اشتقاق همان شیء کلید را
تولید میکند. همچنین، ممکن است یک KMS بخواهد بررسی کند که آیا کلیدهایی که به کاربران مختلف ارائه میدهد یکسان هستند یا نه (این اتفاق گاهی اوقات زمانی رخ میدهد که کاربران کلیدها را همرسانی میکنند و آنها را چندین بار در یک KMS بارگذاری میکنند). قابلتوجه است که ما
روش Java equals را لغو نمیکنیم، زیرا این کار مستلزم آن است که
hashCode را لغو کنیم، و هیچ راهی برای پیادهسازی hashCode بهصورت ایمن
و سازگار با equals بدون ایجاد فرضهای اثباتنشده وجود ندارد.
سپس، به روش getParameters() نیاز داریم. این کار به کاربران امکان میدهد اطلاعات اصلی درباره «پارامترهای» استفادهشده برای ایجاد کلید را دریافت کنند.
درنهایت، AesGcmKey دارای روش getKeyBytes است که مواد کلید خام را برمیگرداند.
این روشها برای کلاسهای کلید بسیار معمول هستند: آنها مختص نوع هستند،
و دسترسی به مواد کلید اصلی را فراهم میکنند. بااستفاده از آنها، کاربران
میتوانند در اصل مثلاً دستور اولیه نشاندادهشده توسط کلید را اجرا کنند،
یا کلید را سریالسازی کنند تا آن را در دیسک ذخیره کنند یا آن را ازطریق
شبکه ارسال کنند. خود کلید مسئول محافظت از مواد کلید دربرابر دسترسی غیرمجاز است. برای مثال، SecretBytes برای ارائه واقعی مطالب به کد دسترسی نیاز دارد (کنترل دسترسی را ببینید).
کلیدهای نامتقارن
برای اولیههای نامتقارن، Tink از دو کلاس Key استفاده میکند، یکی برای کلیدهای خصوصی و دیگری برای کلیدهای عمومی. برای «پارامترها»، راحتتر است که از همان کلاس استفاده شود (چون فقط یک کلاس وجود دارد که میتوان از آن برای تولید کلیدها استفاده کرد).
Tink همچنین دارای میانای PrivateKey با عملکرد اضافی getPublicKey() است.