در عمل، Tink اشیاء Key
را برای نمایش کلیدها و اشیاء Parameters
را برای نمایش Parameters
فراهم می کند. به عنوان مثال، در جاوا، ما اشیاء AesGcmKey
برای نمایش کلیدهای AES GCM داریم.
در این قسمت نحوه طراحی این اشیاء در جاوا و نحوه تعامل آنها را توضیح می دهیم.
Parameters
اشیاء
AES GCM را در نظر بگیرید، یک طرح رمزگذاری AEAD که به طور گسترده مورد استفاده قرار می گیرد. Tink یک شی AesGcmParameters
را با اطلاعات لازم برای ایجاد یک AesGcmKey
فراهم می کند که در ادامه توضیح خواهیم داد. سلسله مراتب پارامترها در جاوا به صورت زیر است:
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 OutputPrefixType getOutputPrefixType() {...}
public boolean equals(Object object) {...}
public int hashCode() {...}
}
همانطور که در بخش Keysets، Tagging Ciphertexts توضیح داده شد، برخی از کلیدها زمانی که در یک مجموعه کلید قرار دارند، یک الزام در شناسه خود دارند. هر شیء Parameters
دارای یک متد hasIdRequirement
است که مشخص می کند آیا کلید ایجاد شده توسط این شیء Parameters
چنین id مورد نیازی خواهد داشت یا خیر.
شیء AesGcmParameters
متدهای getKeySizeBytes()
، getIvSizeBytes()
و getTagSizeBytes()
را ارائه می دهد. اینها طول کلید استفاده شده، طول IV استفاده شده و طول تگ تولید شده را بر حسب بایت برمی گرداند. در حالی که Tink برخی از این توابع را برای کامل بودن فراهم می کند، همیشه اجازه ایجاد Aead
را برای هر انتخابی نمی دهد. به عنوان مثال، در حال حاضر تنها 12 بایت IV برای AES GCM پشتیبانی می شود.
شیء AesGcmParameters
همچنین برای روشهای تعریفشده قبلی (و روشهای استاندارد جاوا equals
و hashCode
که عمل خوبی در نظر گرفته میشود) لغو میکند.
در نهایت، متدهای ایستا را برای ایجاد اشیاء جدید AeadParameters
فراهم می کند. اینها ورودی ها را تأیید می کنند، یعنی بررسی می کنند که اندازه یکی از 16، 24 یا 32 باشد.
اشیاء کلیدی
تینک همچنین یک سلسله مراتب کلیدی دارد. با وجود مثال ما از 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 implements AeadKey {
public SecretBytes getKeyBytes();
public abstract 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 آپلود کنند اتفاق می افتد). قابل توجه است که ما متد جاوا equals
را نادیده نمی گیریم، زیرا این امر مستلزم نادیده گرفتن hashCode
است و هیچ راهی برای پیاده سازی hashCode
به روشی ایمن و سازگار با equals
بدون ایجاد فرضیات اثبات نشده وجود ندارد.
در مرحله بعد، به یک متد getParameters()
نیاز داریم. این به کاربران اجازه می دهد تا اطلاعات اصلی در مورد پارامترهای مورد استفاده برای ایجاد کلید را دریافت کنند.
در نهایت، AesGcmKey
یک متد getKeyBytes
دارد که مواد کلید خام را برمی گرداند. چنین روشهایی برای کلاسهای کلیدی بسیار معمولی هستند: آنها مختص نوع هستند و دسترسی به مواد کلیدی زیرین را فراهم میکنند. با استفاده از آن ها، کاربران می توانند اصولاً به عنوان مثال، کلید اولیه را که توسط کلید نشان داده شده است، پیاده سازی کنند، یا کلید را سریالی کنند تا آن را روی دیسک ذخیره کنند یا از طریق شبکه ارسال کنند. خود کلید مسئول محافظت از مواد کلیدی در برابر دسترسی غیرمجاز است. به عنوان مثال، SecretBytes
به یک نشانه دسترسی برای ارائه واقعی مطالب نیاز دارد (به کنترل دسترسی مراجعه کنید).
کلیدهای نامتقارن
برای موارد اولیه نامتقارن، Tink از دو کلاس کلید، یکی برای خصوصی و دیگری برای کلیدهای عمومی استفاده می کند. برای پارامترها، استفاده از یک کلاس راحت تر است (زیرا فقط یک کلاس وجود دارد که می تواند برای تولید کلیدها استفاده شود).
Tink همچنین دارای یک رابط PrivateKey
با تابع اضافی getPublicKey()
است.