.TH ddr_crypt 1 "2015-04-15" "Kurt Garloff" "افزونه رمزگذاری/رمزگشایی برای dd_rescue"
.
.SH "نام (NAME)"
ddr_crypt \- افزونه رمزگذاری و رمزگشایی داده‌ها برای dd_rescue
.
.SH "خلاصه دستور (SYNOPSIS)"
.na
.nh
.B -L crypt[=option[:option[:...]]]
.br
یا
.br
.B -L /path/to/libddr_crypt.so[=option[:option[:...]]]
.
.SH "توضیحات (DESCRIPTION)"
.SS "درباره (About)"
این افزونه امکان رمزگذاری و رمزگشایی داده‌ها را به‌صورت بلادرنگ و همگام با نوشته‌شدن توسط
.B dd_rescue
فراهم می‌کند.
این افزونه از انواع گوناگون رمزهای AES پشتیبانی کرده و در صورت وجود، از شتاب‌دهنده سخت‌افزاری در معماری‌های x86 (شامل AESNI) و ARMv8 برای دستیابی به کارایی بالا بهره می‌برد.
.PP
این افزونه برای
.B dd_rescue
نوشته شده و از رابط افزونه آن استفاده می‌کند. برای اطلاعات بیشتر درباره
.B dd_rescue
صفحه راهنمای
.BR dd_rescue (1)
را ببینید.
.
.SH "گزینه‌ها (OPTIONS)"
گزینه‌ها با قواعد استاندارد ارسال گزینه در
.B dd_rescue
ارسال می‌شوند: نام افزونه (crypt) با یک علامت مساوی (=) همراه شده و گزینه‌ها با دونقطه (:) از یکدیگر جدا می‌شوند.
افزونه
.B crypt
امکان خلاصه کردن برخی گزینه‌ها را نیز می‌دهد. حداقل باید حالت رمزگذاری یا رمزگشایی و روشی برای تعیین کلید (و IV) مشخص شود.
.
.SS "راهنما (Help)"
گزینه
.B help
را ارسال کنید تا ddr_crypt فهرست کوتاهی از گزینه‌ها را نمایش دهد.
.
.SS "رمزگذاری یا رمزگشایی (Encryption or Decryption)"
باید به افزونه crypt در dd_rescue (که زین‌پس به‌اختصار ddr_crypt نامیده می‌شود و بازتاب‌دهنده بخش متغیر نام فایل libddr_crypt.so است) مشخص شود که قصد رمزگذاری دارد یا رمزگشایی. این کار با مشخص کردن پارامترهای
.B enc[rypt]
یا
.B dec[rypt]
در خط فرمان انجام می‌گیرد.
.
.SS "الگوریتم رمزگذاری/رمزگشایی (De/encryption algorithm)"
افزونه crypt از چندین گونه مختلف رمزگذاری/رمزگشایی AES پشتیبانی می‌کند. می‌توانید با ارسال گزینه زیر گونه مورد نظر را تعیین کنید:
.TP 4
.BR algo=AESxxx-yyy
که در آن xxx می‌تواند 128، 192، 256، +128، +192، +256، 128x2، 192x2 یا 256x2 باشد،
و yyy می‌تواند ECB، CBC یا CTR باشد.
برای دریافت فهرست الگوریتم‌های در دسترس،
.B algo=help
را ارسال کنید.
برای بررسی تفصیلی گزینه‌ها، بخش «الگوریتم‌ها و حالت‌های جریانی» را ببینید.
توجه داشته باشید که رمزگشایی یک فایل تنها در صورتی موفقیت‌آمیز خواهد بود که دقیقاً همان الگوریتمی انتخاب شود که هنگام رمزگذاری استفاده شده است. از روی فایل رمزگذاری‌شده به هیچ عنوان نمی‌توان فهمید چه الگوریتمی انتخاب شده بود.
.br
حالت پیش‌فرض (AES192-CTR) انتخابی مناسب است به شرط آن‌که اطمینان حاصل کنید ترکیب کلید/IV هرگز مجدداً استفاده نمی‌شود.
.
.SS "موتور رمزنگاری (Crypto engine)"
در حال حاضر پیاده‌سازی‌های متعددی از الگوریتم‌های AES وجود دارد که این افزونه می‌تواند از آن‌ها استفاده کند:
.TP 4
.BR engine=aesni
از پیاده‌سازی اختصاصی AES با دستورالعمل‌های سخت‌افزاری AESNI پردازنده‌های x86 اینتل (از معماری Westmere به بعد) استفاده می‌کند. در صورت امکان بهتر است از این گزینه استفاده شود، زیرا علاوه بر کارایی بسیار بالاتر، از برخی حملات زمانی حافظه موقت (cache timing attacks) که پیاده‌سازی‌های مبتنی بر جدول جستجو ممکن است در معرض آن باشند جلوگیری می‌کند. این موتور از تمام الگوریتم‌ها پشتیبانی می‌کند.
.TP 4
.BR engine=aesarm64
از پیاده‌سازی اختصاصی AES با افزونه‌های رمزنگاری AESv8 معماری ARMv8 (معماری AArch64 یا 64 بیتی ARM) استفاده می‌کند (در پردازنده‌ها/تراشه‌های مبتنی بر Cortex A53، A57، A72 آرم یا Kryo کوالکام یا A7x اپل و طرح‌های جدیدتر در دسترس است).
در صورت امکان بهتر است از این موتور استفاده شود، زیرا علاوه بر کارایی عالی، از حملات زمانی حافظه موقت جدول‌های جستجو جلوگیری می‌کند. این موتور از تمام الگوریتم‌ها پشتیبانی می‌کند.
.TP 4
.BR engine=aes_c
از پیاده‌سازی AES به زبان C که بر پایه کد مرجع rijndael است استفاده می‌کند. روی تمام پردازنده‌ها در دسترس است و از همه الگوریتم‌ها پشتیبانی می‌کند.
عملیات واکشی اولیه (prefetching) روی جدول‌ها انجام می‌شود تا حملات زمانی حافظه موقت سخت‌تر شوند، اما برای دفع مهاجمان ماهر احتمالاً کافی نیست.
.TP 4
.BR engine=openssl
از کتابخانه openssl برای پیاده‌سازی روال‌های AES استفاده می‌کند که در صورت وجود شتاب‌دهنده سخت‌افزاری از آن بهره می‌برد و در برابر حملات مقاوم‌سازی شده است. توجه داشته باشید که پیاده‌سازی openssl از گونه‌های + (تعداد دورهای افزایش‌یافته) که در موتورهای دیگر موجود است پشتیبانی نمی‌کند.
.PP
موتورها در صورت دسترسی به همین ترتیب اولویت استفاده می‌شوند، به این معنی که
.I aesni
به‌طور پیش‌فرض در صورت پشتیبانی روی x86 استفاده می‌شود،
.I aesarm64
روی ARMv8 و
.I aes_c
به‌طور پیش‌فرض روی سایر پلتفرم‌ها به کار می‌رود.
.
.SS "پرکردن بلوک (Padding)"
از آنجا که AES یک رمز بلوکی است (با اندازه بلوک ۱۶ بایت)، فایل‌هایی که اندازه آن‌ها مضربی از اندازه بلوک نیست در انتهای فایل نیاز به پرکردن (Padding) دارند تا یک بلوک کامل تشکیل شود.
.TP 4
.BR pad=zero
بلوک آخر با صفر پر شده و سپس رمزگذاری می‌شود.
توجه داشته باشید که هنگام رمزگشایی، این صفرها را نمی‌توان به‌طور خودکار حذف کرد، چرا که رمزگشا راهی برای تشخیص اینکه صفرهای انتهایی متعلق به داده اصلی بوده‌اند یا در فرآیند پدینگ اضافه شده‌اند ندارد. بنابراین این گزینه برای رونوشت فایل‌هایی با طول دلخواه پیشنهاد نمی‌شود.
.TP 4
.BR pad=always
از طرح PKCS7 مورد استفاده در openssl استفاده می‌کند که یک تا شانزده بایت حاوی تعداد بایت‌های دورریختنی هنگام رمزگشایی را به انتها اضافه می‌کند. این روش همیشه امن است، اما همواره اندازه فایل خروجی را بزرگتر از فایل ورودی می‌کند. هنگام رونوشت فایل‌ها از این گزینه استفاده کنید. این مقدار پیش‌فرض است.
.TP 4
.BR pad=asneeded
روشی ترکیبی میان zero و always است. اگر اندازه فایل یک بلوک کامل را پر نکند پدینگ PKCS7 انجام می‌دهد، اما اگر پر کند هیچ پدینگی اعمال نمی‌کند. این مکانیزم در بدترین حالت (نبود بایت‌های پدینگ) احتمال ۱/۲۵۵ برای ایجاد نتیجه رمزگشایی نادرست به دلیل حذف اشتباه پدینگ دارد (به این معنی که در فایل‌هایی با اندازه دلخواه احتمال کلی نادرست نشان دادن اندازه نهایی فایل ۱/۴۰۸۰ است). از این گزینه استفاده نکنید مگر اینکه بتوانید چنین خطاهایی را مدیریت یا حذف کنید!
.PP
توجه داشته باشید که حالت جریانی CTR نیازی به پدینگ ندارد و در واقع ddr_crypt هنگام استفاده از آن، صرف‌نظر از گزینه pad هیچ پدینگی اعمال نمی‌کند.
.
.SS "اشکال‌زدایی و محک‌زنی (Debugging and Benchmarking)"
پارامتر
.B debug
باعث می‌شود ماژول ddr_crypt اطلاعات اشکال‌زدایی چاپ کند.
با
.B outkeyiv
کلید و بردار مقداردهی اولیه (IV) در خروجی نمایش داده می‌شوند.
پارامتر
.B benchmark
سرعت رمزگذاری/رمزگشایی را گزارش می‌دهد.
.
.SH "تنظیم کلید و بردار مقداردهی اولیه (Setting key and IV)"
روش‌های متعددی برای تعیین کلید و IV (برای حالت‌های جریانی CBC- و CTR-) وجود دارد.
.SS "تنظیم مستقیم (Setting directly)"
می‌توان آن‌ها را مستقیماً با استفاده از
.B keyhex=
و
.B ivhex=
در خط فرمان تعیین کرد. آرگومان به‌صورت نمایش هگزادسیمال ASCII از کلید/IV (بدون 0x اولیه) تفسیر می‌شود.
این روش تعیین کلید/IV فقط باید برای اهداف آزمایشی استفاده شود؛ چرا که کلید با مشاهده خط فرمان برای تمام کاربران محلی قابل دیدن خواهد بود (مگر اینکه تمهیدات خاصی برای محدود کردن دسترسی به /proc اعمال شده باشد). این کار معمولاً در سیستم‌های چندکاربره ایده مناسبی نیست. ddr_crypt داده‌های حساس را با X بازنویسی می‌کند تا حمله کمی سخت‌تر شود، اما همچنان طول کلید افشا می‌شود و مهم‌تر از آن، بازه زمانی وجود دارد که داده‌های حساس در آن قابل مشاهده هستند.
.
.SS "خواندن از فایل یا توصیف‌کننده فایل (Reading from file or file descriptor)"
بهتر است کلید و IV را از طریق یک توصیف‌کننده فایل با گزینه‌های
.B keyfd=
و
.B ivfd=
ارسال کنید.
اگر پیش از عدد صحیح یک x قرار گیرد، کلید/IV به‌صورت رشته هگز خوانده می‌شود، در غیر این صورت داده‌ها به‌صورت باینری خوانده خواهند شد. به‌صورت اختیاری می‌توان @OFF@LEN را اضافه کرد که آفست و طول (به بایت) برای خواندن از فایل ارائه‌شده از طریق توصیف‌کننده فایل را مشخص می‌کند. توجه داشته باشید که توصیف‌کننده فایل 0 بدون تغییرمسیر شل، باعث نمایش اعلان تعاملی به کاربر می‌شود و پاسخ واردشده طبیعتاً روی صفحه نمایش داده نخواهد شد.
.br
این روش بیشتر زمانی کاربرد دارد که dd_rescue از برنامه‌ای دیگر فراخوانی شود.
.P
به‌عنوان جایگزین، با گزینه‌های
.B keyfile=
و
.B ivfile=
می‌توان نام فایلی را برای باز کردن و خواندن مشخص کرد.
قالب نحوی از همان ساختار اختیاری @OFF@LEN پشتیبانی می‌کند، اما کلید و IV همیشه به‌صورت باینری خوانده خواهند شد.
(برای روش خواندن به‌صورت هگز، بخش فایل‌های نمایه را در زیر ببینید.)
در حال حاضر (برخلاف سالت) راهی برای استفاده از ddr_crypt جهت نوشتن داده‌های باینری کلید و IV با این گزینه‌ها وجود ندارد.
.
.SS "تولید کلید و IV تصادفی (Generating random key and IV)"
می‌توان از تولیدکننده اعداد تصادفی سیستم‌عامل برای تولید بلادرنگ کلید و IV استفاده کرد؛ اگر سیستم شما اعداد تصادفی با کیفیت تولید کند، این امن‌ترین روش برای تعیین کلید رمزگذاری است. گزینه‌های مربوطه عبارتند از:
.B keygen
و
.B ivgen .
شما باید کلید/IV را به نحوی ذخیره کنید، در غیر این صورت بعداً قادر به رمزگشایی نخواهید بود (برنامه به شما هشدار خواهد داد!). بهترین روش استفاده از گزینه‌های بعدی است.
.
.SS "فایل‌های نمایه (Index files)"
کلیدها و IVها را می‌توان به‌صورت رشته‌های هگز در فایل‌های نمایه ذخیره کرد؛
قالب فایل مانند قالب استفاده‌شده در MD5SUMS است:
نمایش هگزادسیمال کلید/IV و در ادامه نام فایل قرار می‌گیرد.
بدیهی است که باید دقت لازم برای محرمانه نگه داشتن این فایل‌ها به کار گرفته شود.
.P
اگر به افزونه ddr_crypt گزینه‌های
.B keysfile
و
.B ivsfile
داده شود، کلیدها/IVهای ایجادشده (از سایر گزینه‌ها) را در فایل‌هایی با نام KEYS.algname و IVS.algname با فرمت MD5SUMS ذخیره می‌کند.
(فایل‌ها متناسب با نیاز ایجاد یا به‌روزرسانی می‌شوند.)
اگر کلید/IV هنوز ایجاد نشده باشد، ddr_crypt تلاش می‌کند کلید/IV را از آن فایل‌ها بازیابی کند و در صورت عدم موفقیت با خطا خارج می‌شود.
.br
این گزینه‌ها هنگام رمزگذاری به‌خوبی با keygen و ivgen ترکیب می‌شوند (و هنگام رمزگشایی باید به‌تنهایی استفاده شوند).
.
.SS "ویژگی‌های توسعه‌یافته (Extended attributes)"
مشابه فایل‌های نمایه، کلیدها و IVها را می‌توان در ویژگی‌های توسعه‌یافته (xattr) فایل رمزگذاری‌شده نیز ذخیره و بازیابی کرد. این کار با استفاده از گزینه‌های
.B keyxattr
و
.B ivxattr
انجام می‌شود.
لطفاً نکات مربوط به استفاده از ویژگی‌های توسعه‌یافته را در صفحه راهنمای اصلی
.BR dd_rescue (1)
مطالعه کنید.
.br
توجه داشته باشید که ذخیره کلید در xattr معمولاً ایده مناسبی
.B نیست
.
کاربری که به فایل رمزگذاری‌شده دسترسی دارد (به‌صورت محلی) می‌تواند xattrها را نیز بخواند؛ بنابراین محرمانگی که معمولاً با رمزگذاری حاصل می‌شود از این طریق از بین می‌رود. (البته سناریوهای معتبری وجود دارد، مثلاً زمانی که خود فایل فقط از طریق یک پروتکل راه دور که xattr را افشا نمی‌کند مانند http یا DAV یا NFS قابل دسترسی باشد.)
.br
همچنین می‌توانید گزینه‌های
.B kxfallb[ack]
و
.B ixfallb[ack]
را مشخص کنید تا ddr_crypt در صورت عدم پشتیبانی سیستم فایل از ویژگی‌های توسعه‌یافته، تلاش کند از xattr استفاده کند و در صورت نیاز به keysfile و ivsfile بازگردد (fallback).
.
.SS "تولید کلید و IV مبتنی بر گذرواژه (Password based key and IV generation)"
استفاده از کلید/IV یکسان برای فایل‌های متعدد به امنیت آسیب جدی می‌زند (بخش «الگوریتم‌ها» را در زیر ببینید). بنابراین استفاده از کلید مشخص‌شده مستقیم (غیرتولیدی) ایده خوبی نیست. با این حال، اگر ترجیح می‌دهید به جای ذخیره‌سازی از عبارتی به یادماندنی استفاده کنید، می‌توانید از گذرواژه و سالت (salt) برای تولید چندین کلید از یک گذرواژه استفاده کنید.
.P
کلید و IV از یک تابع محاسباتی سنگین (و با معکوس‌پذیری به مراتب سنگین‌تر) روی گذرواژه و سالت مشتق می‌شوند.
به‌طور پیش‌فرض، ddr_crypt از ۱۷۰۰۰ دور pbkdf2() برای کلید (و یک‌سوم آن برای IV) استفاده می‌کند،
اگرچه توابع سنگین‌تری (مانند scrypt) برای آینده برنامه‌ریزی شده‌اند. سنگینی محاسباتی این تابع محافظتی در برابر حملات جستجوی فراگیر (brute force) گذرواژه است. برای استفاده از pbkdf2 باید
.B pbkdf2
یا
.B pbkdf2=rounds
را مشخص کنید. فرمت دوم امکان تغییر تعداد تکرارها برای تولید کلید را می‌دهد (تولید IV مجدداً با یک‌سوم این تعداد انجام خواهد شد).
.P
برای سازگاری با openssl، کلید و IV را می‌توان با استفاده از تابع اشتقاق کلید سازگار با openssl با گزینه
.B opbkdf
مشتق کرد.
توجه داشته باشید که این روش توصیه نمی‌شود؛ زیرا تنها از یک دور درهم‌سازی md5 استفاده می‌کند که حملات brute force را بسیار کارآمد می‌سازد. استفاده از این گزینه همچنین دارای اثر جانبی نوشتن (در رمزگذاری) یا تجزیه (در رمزگشایی) هدر به سبک OpenSSL یعنی Salted__ است. توجه داشته باشید که openssl از نسخه 1.1 به بعد به‌طور پیش‌فرض از یک دور درهم‌سازی sha256 استفاده می‌کند که در نسخه‌های قدیمی‌تر openssl با سوییچ md sha256- اجباری می‌شد و با مشخص کردن md md5- در خط فرمان openssl قابل بازنویسی بود. می‌توانید با مشخص کردن
.B opbkdf11
به dd_rescue دستور دهید از یک KDF سازگار با openssl به همراه sha256 استفاده کند.
یک دور sha256 نیز البته همچنان می‌تواند با کارایی بالا هدف حمله brute force قرار گیرد، بنابراین اگر واقعاً ناچار به استفاده از این روش هستید از گذرواژه‌هایی با آنتروپی بالا استفاده کنید.
.B nosalthdr .
نرم‌افزار openssl از نسخه 3.0 در صورتی که سالت صراحتاً ارسال شود دیگر هدر Salted__ را نمی‌نویسد. برای سازگاری با نسخه 3.0 به بالا، این گزینه اجازه می‌دهد تا این هدر دیگر نوشته نشود (هنگام رمزگذاری) و به دنبال آن نیز گشته نشود (هنگام رمزگشایی).
.P
سالت را می‌توان به‌طور خودکار از نام (و طول) فایل رمزگذاری‌شده مشتق کرد؛ این کار امکان کار با تنها یک گذرواژه به یادماندنی را فراهم می‌کند. با این حال، آگاه باشید که تغییر اندازه یا نام فایل منجر به سالت متفاوت و در نتیجه کلید/IV متفاوت می‌شود که فایل رمزگذاری‌شده شما را غیرقابل رمزگشایی می‌کند. اگر احتمال وقوع چنین اتفاقی وجود دارد، بهتر است برای هر فایل یک سالت به خاطر بسپارید (یا ترجیحاً کلید و IV را با گزینه‌های keysfile و ivsfile ذخیره کنید یا سالت را با saltsfile یا saltxattr ذخیره نمایید؛ توضیحات زیر را ببینید). به یاد داشته باشید که نام فایل‌ها (مانند همیشه در یونیکس) به حروف کوچک و بزرگ حساس هستند. بدیهی است که فایل keysfile باید در برابر خوانده شدن توسط افراد غیرمجاز به‌خوبی محافظت شود.
.P
گذرواژه و سالت را می‌توان با یک رشته از طریق
.B pass=
و
.B salt=
یا با استفاده از گزینه‌های
.B passfd=
.B passfile=
و
.B salthex=
.B saltfd=
.B saltfile=
با همان پارامترهای ممکن بالا برای تعیین مستقیم کلید و IV مشخص کرد. (توجه داشته باشید که سالت مانند حالت اشتقاق از نام و طول فایل، هش می‌شود.) گذرواژه/عبارت عبور به‌صورت یک رشته با پایان تهی (null-terminated) در نظر گرفته شده و کاراکتر CRLF انتهایی آن حذف می‌شود.
.br
هشدارهای مربوط به ارسال داده‌های محرمانه (در اینجا: pass، salt، salthex) در خط فرمان در اینجا نیز صدق می‌کند؛ فقط برای آزمایش یا در محیط‌های تک‌کاربره این کار را انجام دهید. استفاده از passfd=0 امکان ارسال گذرواژه از طریق پایپ را فراهم می‌کند.
.P
اگر از اشتقاق خودکار سالت بر اساس نام فایل استفاده شود، طول فرض‌شده فایل برای تولید سالت را می‌توان با
.B saltlen=
تغییر داد.
.P
به‌عنوان روش جایگزین، سالت‌ها را می‌توان با مشخص کردن گزینه
.B saltsfile
در یک فایل نمایه به سبک MD5SUMS (مشابه keysfile و ivsfile) ذخیره و بازیابی کرد.
هنگامی که saltsfile برای ذخیره سالت‌ها استفاده می‌شود، استفاده از سالت‌های تصادفی هنگام رمزگذاری انتخابی بسیار مناسب خواهد بود. این کار با مشخص کردن گزینه
.B saltgen
انجام می‌شود.
.P
به جای فایل نمایه سالت (saltsfile)، سالت را می‌توان در یک ویژگی توسعه‌یافته (xattr) نیز ذخیره (و از آن بازیابی) کرد. این کار را می‌توان با گزینه
.B saltxattr[=xattr_name]
انجام داد. نام ویژگی اختیاری است و مقدار پیش‌فرض آن user.salt.ALGNAME است (که در آن ALGNAME با نام الگوریتم جایگزین می‌شود). از نسخه 1.99 افزونه ddr_crypt، تابع اشتقاق کلید مبتنی بر گذرواژه (و تعداد دورهای آن) نیز با این گزینه در ویژگی user.pbkdf ذخیره و بازیابی می‌شود.
.br
همچنین می‌توان تلاش کرد از قابلیت xattr استفاده کرد و در صورتی که سیستم فایل از ویژگی‌های توسعه‌یافته پشتیبانی نکند، به استفاده از فایل نمایه (saltsfile) بازگشت.
از گزینه
.B sxfallback
استفاده کنید تا به ddr_crypt دستور انجام این کار را بدهید. توجه داشته باشید که اگر بازگشت (fallback) رخ دهد، pbkdf ذخیره (یا بازیابی) نمی‌شود.
.br
برای بررسی مزایا و معایب استفاده از ویژگی‌های توسعه‌یافته، صفحه راهنمای اصلی
.BR dd_rescue (1)
را ببینید.
.
.SH "الگوریتم‌ها و حالت‌های جریانی (ALGORITHMS AND STREAM MODES)"
خانواده الگوریتم‌های AES (Rijndael) در زمان نگارش این متن از نظر رمزنگاری امن محسوب می‌شوند، زیرا تاکنون هیچ حمله عملی و کاربردی علیه آن منتشر نشده است. قضاوت درباره اینکه آیا سازمان‌های اطلاعاتی یا مجرمان بزرگ به‌طور چشمگیری از دانش عمومی (منتشرشده) جلوتر هستند یا خیر، به عهده خواننده است. در عمل معمولاً استفاده از مهندسی اجتماعی یا نقص در مدیریت کلیدها و تولید اعداد تصادفی برای انجام حملات آسان‌تر است.
.
.SS "حالت‌های پلاس (Plus modes)"
با توجه به اینکه شناخته‌شده‌ترین حملات علیه نسخه‌های AES با تعداد دورهای کاهش‌یافته و آن هم با کاهش اندک دورها بوده است، به نظر می‌رسد افزایش تعداد دورها یک اقدام متقابل منطقی در برابر حملات رمزنگاری باشد. (این ایده از نظری از بروس اشنایر الهام گرفته شده که نویسنده این سند احترام بسیار زیادی برای او قائل است.)
.P
پیاده‌سازی‌های C و AESNI از حالت‌های AES128، 192 و 256 با ۲، ۳ و ۴ دور اضافی پشتیبانی می‌کنند که به ترتیب منجر به ۱۲، ۱۵ و ۱۸ دور می‌شود. این حالت‌ها به ترتیب +AES128، +AES192 و +AES256 (حالت‌های پلاس) نامیده می‌شوند.
آن‌ها روشی نسبتاً ارزان از نظر محاسباتی برای ارتقای امنیت ارائه می‌دهند. برای نمونه، نویسنده این سند +AES192 را به AES256 ترجیح می‌دهد. اگرچه نویسنده این سند هرگز خود را متخصصی آنچنان برجسته در رمزنگاری نمی‌داند که الگوریتم‌های جدید بسازد یا تغییرات بنیادین در الگوریتم‌های موجود ایجاد کند، اما این دگرگونی را انتخابی امن‌تر از نسخه اصلی می‌داند. لطفاً توجه داشته باشید که این الگوریتم‌های سفارشی منجر به ایجاد فایل‌هایی می‌شوند که با هیچ ابزار دیگری قابل رمزگشایی نیستند. همچنین موتور openSSL از حالت‌های پلاس پشتیبانی نمی‌کند.
.
.SS "حالت‌های دوگانه (Double modes)"
یک روش سنگین‌تر از نظر محاسباتی برای ارتقای امنیت، دو برابر کردن تعداد دورها است. این کار معادل دو بار رمزگذاری است (که در آن کلید دوم یک اشتقاق ساده از کلید اول است).
این روش‌ها توسط تمامی موتورها پشتیبانی می‌شوند و AES128x2، AES192x2 و AES256x2 نام دارند.
.
.SS "حالت‌های جریانی (Stream modes)"
الگوریتم AES یک رمز بلوکی است؛ یعنی بلوک‌های ۱۶ بایتی را تبدیل می‌کند. ساده‌ترین روش اعمال آن روی فایلی با اندازه دلخواه، اعمال آن روی تک‌تک بلوک‌های فایل است. این حالت ECB (کتاب رمز الکترونیکی) نامیده می‌شود. این حالت بسیار ناامن است... ورودی یکسان همیشه به خروجی یکسان منجر می‌شود. الگوها به‌راحتی قابل تشخیص هستند و حملات متن آشکار معلوم (known plaintext) روی آن پیش‌پاافتاده است.
.P
بهتر است فرآیند تبدیل به محتوای پیشین فایل یا موقعیت درون آن وابسته شود. این همان کاری است که حالت‌های CBC (رمزگذاری زنجیره‌ای بلوک‌ها) و CTR انجام می‌دهند.
.P
حالت CBC دارای چندین عیب است: نمی‌توان آن را موازی‌سازی کرد (در رمزگذاری هر بلوک به تمامی بلوک‌های پیشین وابسته است؛ البته وضعیت در رمزگشایی بهتر است) و دسترسی تصادفی به بخش‌های فایل غیرممکن است.
.P
حالت CTR دارای ویژگی‌های مطلوب بسیاری است. این حالت اساساً جریانی از اعداد شبه‌تصادفی (تکرارپذیر) است که برای رمزگذاری با ورودی XOR می‌شوند. رمزگشایی نیز طبیعتاً یک عملیات XOR دیگر است. این روش مانند پد یک‌بارمصرف (one-time pad) عمل می‌کند که اثبات شده در صورت ناشناخته بودن پد برای مهاجم و استفاده تنها برای یک‌بار، کاملاً امن است.
.br
نکته اخیر را هرگز نمی‌توان بیش از حد مورد تأکید قرار داد: هرگز از یک ترکیب کلید/IV یکسان برای دو فایل استفاده نکنید. به زبان ریاضی:
.nf
c1 = r1 XOR p1
c2 = r2 XOR p2
.fi
(که در آن c = متن رمزگذاری‌شده، r = اعداد تصادفی AES و p = متن اصلی است).
اگر r == r1 == r2 باشد، به‌سادگی مشاهده می‌شود که مهاجم می‌تواند مقدار زیر را محاسبه کند:
.nf
c1 XOR c2 = r XOR p1 XOR r XOR p2 = p1 XOR p2
.fi
اگر متن اصلی یکی از فایل‌ها تا حدی مشخص باشد، متن فایل دیگر نیز افشا می‌شود.
.P
حالت CTR ویژگی‌های خوب دیگری نیز دارد: امکان دسترسی تصادفی را فراهم می‌کند، زیرا اعداد تصادفی AES (متعلق به یک ترکیب کلید/IV) با یک آفست مشخص مستقیماً قابل محاسبه هستند و بلوک آخر نیازی به پدینگ ندارد؛ زیرا بلوک‌های ناقص نیز قابل پردازش هستند.
.P
نویسنده این سند حالت جریانی CTR را ترجیح می‌دهد و اطمینان حاصل می‌کند که کلیدها/IVها مجدداً استفاده نشوند.
.
.SH "قابلیت‌های پشتیبانی‌شده dd_rescue (Supported dd_rescue features)"
در حالت CTR، می‌توانید نوشتن جزئی را روی فایل‌های رمزگذاری‌شده انجام دهید و نتیجه همچنان فایلی یکپارچه خواهد بود (البته با فرض اینکه کلید و IV استفاده‌شده یکسان باشند). همین امر برای الحاق (گزینه x-) یا رونوشت در جهت معکوس نیز صادق است.
.br
در حالت ECB، این کار تنها در صورتی کار می‌کند که اندازه فایل و آفست‌ها همگی با مرز بلوک (۱۶ بایت) تراز باشند. در حالت CBC، هیچ‌یک از این کارها امکان‌پذیر نیست.
.P
افزونه ddr_crypt از کدگذاری حفره‌ها پشتیبانی می‌کند؛ اگر حفره‌ها به دلیل خطاهای خواندن ایجاد شوند و گزینه skiphole تنظیم شده باشد، از آن نواحی صرف‌نظر شده و چیزی در محل متناظر در فایل خروجی نوشته نمی‌شود؛ در نتیجه آنچه قبلاً در آنجا بوده دست‌نخورده باقی می‌ماند (یا اگر چیزی نبوده صفر باقی می‌ماند). این قابلیت فقط برای حالت‌های CTR و ECB کار می‌کند و در CBC پشتیبانی نمی‌شود.
.br
می‌توانید گزینه
.B skiphole
را ارسال کنید تا مطمئن شوید ddr_crypt بلوک‌های صفر با اندازه ۵۱۲ بایت را دست‌نخورده باقی می‌گذارد. این کار بلوک‌های حاوی صفر را آشکار می‌کند و ممکن است اطلاعات باارزشی را برای مهاجم افشا سازد، بنابراین با احتیاط از آن استفاده کنید. همچنین توجه داشته باشید که برای برگشت‌پذیر بودن رمزگذاری باید از این گزینه در هر دو مرحله رمزگذاری و رمزگشایی و با همان تراز (mod 512) استفاده کنید. به شما هشدار داده شد. (نیازی نیست نگران تشخیص اشتباه صفرها هنگام رمزگشایی باشید؛ شانس اینکه یک متن اصلی غیرصفر پس از رمزگشایی به یک بلوک تراز ۵۱۲ بایتی از صفر تبدیل شود کمتر از ۲ به توان منفی ۴۰۹۶ است. بنابراین استفاده از این گزینه هنگام رمزگشایی امن است؛ اگر بخشی از متن رمزگذاری‌شده با بلوک‌هایی از صفر بازنویسی شده باشد، حتی ممکن است ترجیح دهید در فایل رمزگشایی‌شده صفر داشته باشید تا داده‌های تصادفی نامفهوم.)
اگر بلوک‌های خالی را شناسایی کردید (گزینه a- در dd_rescue)، می‌توانید از skiphole استفاده کنید تا ddr_crypt از روی حفره‌ها در فایل‌های خلوت (sparse) عبور کند. اگر این کار را نکنید، صفرها به‌درستی رمزگذاری می‌شوند (از نسخه 1.99.19 به بعد) که خروجی آن مثلاً با openssl نیز قابل رمزگشایی خواهد بود.
بنابراین برای رمزگذاری فایل‌های دارای حفره سه راه پیش رو دارید:
.br
(الف) از a- و skiphole (در حالت CTR یا ECB) هم برای رمزگذاری و هم برای رمزگشایی استفاده کنید. این کار منجر به تولید فایل رمزگذاری‌شده‌ای می‌شود که فقط dd_rescue به همراه ddr_crypt قادر به رمزگشایی آن است.
.br
(ب) هنگام رمزگذاری از هیچ‌یک از این گزینه‌ها استفاده نکنید. اما برای رمزگشایی گزینه a- را ارسال کنید تا بلوک‌های خالی پیش از نوشته شدن روی دیسک شناسایی شوند و به جای صفر، حفره ایجاد گردد.
.br
(ج) (جدید از نسخه 1.99.19:) می‌توانید گزینه a- را هنگام رمزگذاری بدون skiphole ارسال کنید و همچنان خروجی ایجاد کنید که در آن صفرهای ناشی از حفره‌ها به‌درستی رمزگذاری شده‌اند. آن‌ها مجدداً به 0 رمزگشایی می‌شوند و با a- حتی منجر به ایجاد حفره در فایل رمزگشایی‌شده خواهند شد.
.P
توجه داشته باشید که می‌توانید با ddr_lzo داده‌ها را فشرده کرده و حفره‌ها را کدگذاری کنید، سپس برای رمزگذاری به ddr_crypt بسپارید، و برای رمزگشایی داده‌ها را از ddr_crypt عبور داده و با ddr_lzo از حالت فشرده خارج کرده و حفره‌ها را دوباره استخراج کنید. این کار فقط در حالت CTR کار می‌کند.
.P
گزینه
.B weakrnd
برای آزمایش در محیط‌هایی ارائه شده است که اعداد تصادفی قوی در دسترس نیستند. این گزینه باعث می‌شود اعداد تصادفی ضعیف‌تری برای تولید کلید استفاده شود. اگر امنیت می‌خواهید از آن استفاده نکنید.
.
.SH "سازگاری با openssl (openssl compatibility)"
فایل‌هایی که با دستور openssl enc رمزگذاری شده‌اند و در آن‌ها کلید (با K-) و IV (با iv-) مشخص شده است، همان خروجی را ایجاد می‌کنند که ddr_crypt برای حالت‌های ECB- و CBC- تولید می‌کند.
افزونه ddr_crypt در حالت‌های CTR- از یک شمارنده ۶۴ بیتی استفاده می‌کند.
.P
با گزینه
.B opbkdf
افزونه ddr_crypt هدر Salted__ مربوط به openSSL را نیز می‌خواند/می‌نویسد تا با openssl سازگار باشد. البته این عملکرد نیازمند تست‌های بیشتر و مدیریت خطای بهتری است.
.
.SH "اشکالات و محدودیت‌ها (BUGS/LIMITATIONS)"
.SS "بلوغ و پایداری (Maturity)"
این افزونه با dd_rescue نسخه 1.98 معرفی شد. از آن زمان تاکنون استفاده و آزمایش‌های زیادی را پشت سر گذاشته است، اما همچنان هنگام تکیه بر آن به‌عنوان تنها نسخه پشتیبان برای داده‌های بسیار ارزشمند باید احتیاط کرد.
.P
به دلیل اشکالی در مقداردهی اولیه IV برای حالت CTR در dd_rescue نسخه 1.98، آخرین ۳۲ بیت همیشه قبل از اضافه شدن شمارنده صفر می‌شدند. این مشکل در نسخه 1.99 برطرف شده است. برای حفظ سازگاری با نسخه 1.98، گزینه
.B ctrbug198
را می‌توان در خط فرمان مشخص کرد.
.br
.
.SS "امنیت (Security)"
اگرچه دقت لازم برای بررسی نتایج تخصیص‌های حافظه به کار گرفته شده است، اما کد مورد ممیزی کامل قرار نگرفته و تنها فازینگ (fuzzing) محدودی برای اطمینان از عدم آسیب‌پذیری در برابر داده‌های مخرب انجام شده است؛ بنابراین هنگام پردازش داده‌ها از منابع غیرقابل اعتماد احتیاط کنید.
.br
مدیریت کلیدها کاری پیچیده است؛ ممکن است نویسنده در بخش‌هایی مرتکب خطاهای غیربدیهی شده باشد که باعث شود برخی روش‌های استفاده از این برنامه برای رمزگذاری داده‌ها به سطح محرمانگی مورد نظر نینجامد.
.
.SS "آزمون و تست (Testing)"
افزونه crypt در حال حاضر پوشش آزمایشی مناسبی را کسب کرده است، اما انجام آزمون‌های بیشتر قطعاً مطلوب خواهد بود.
.
.SS "ترتیب زنجیره افزونه‌ها (Plugin chain ordering)"
اگر چندین افزونه را به صورت زنجیره‌ای استفاده می‌کنید (dd_rescue از این قابلیت پشتیبانی می‌کند)، لطفاً اطمینان حاصل کنید که هیچ افزونه‌ای اندازه/آفست‌ها را بعد از ddr_crypt در رمزگذاری و قبل از ddr_crypt در رمزگشایی تغییر ندهد.
اگر چنین کنید، محاسبه موقعیت در فایل با اختلال مواجه شده و مقدار نادرستی برای شمارنده در حالت CTR استفاده خواهد شد.
این موضوع روی ECB تأثیری ندارد، اما ECB معمولاً انتخاب مناسبی نیست.
این محدودیت به این معنی است که شما می‌توانید داده‌ها را ابتدا فشرده و سپس رمزگذاری کنید، و هنگام بازیابی ابتدا رمزگشایی و سپس از حالت فشرده خارج نمایید. این یک انتخاب طراحی بوده است؛ چرا که داده‌های رمزگذاری‌شده غیرقابل فشرده‌سازی هستند و ترتیب دیگر عملاً هیچ معنایی ندارد.
.
.SS "کارهای آینده (Future work)"
به جز آزمایش‌های بیشتر و ممیزی کد، چند ویژگی دیگر برای این افزونه در نظر گرفته شده است:
.br
پشتیبانی از سایر الگوریتم‌های غیر AES مانند twofish (و احتمالاً threefish).
.br
تابع قوی‌تر برای اشتقاق کلیدها/IVها از گذرواژه نسبت به pbkdf2.
.br
پشتیبانی از سایر حالت‌های جریانی (XTS، GCM، ...).
.
.SH "مثال‌ها (EXAMPLES)"
.TP
.BI dd_rescue\ \-ptAL\ crypt=algo=AES256-CTR:enc:keygen:ivgen:keysfile:ivsfile\ infile\ outfile
داده‌ها را از
.IR infile
با الگوریتم AES256 در حالت CTR با استفاده از کلید و IV تولیدشده (تصادفی) رمزگذاری کرده و نتیجه را در
.IR outfile
می‌نویسد.
.
خطی به KEYS.AES256-CTR و IVS.AES256-CTR اضافه می‌کند که در آن کلید و IV استفاده‌شده به ترتیب نوشته می‌شوند. (لطفاً اطمینان حاصل کنید که این فایل‌ها برای هیچ فرد غیرمجازی قابل دسترسی نباشند!) رمزگشایی را می‌توان با دستور زیر انجام داد:
.P
.BI dd_rescue\ \-ptAL\ crypt=algo=AES256-CTR:dec:keysfile:ivsfile\ outfile\ infile
.
.TP
.BI dd_rescue\ \-AL\ crypt=AES192+-CTR:enc:saltgen:saltxattr:sxfallback:passfd=0:pbkdf2\ infile\ outfile
گذرواژه را درخواست می‌کند، یک سالت تصادفی تولید کرده و آن را در ویژگی توسعه‌یافته
.B outfile
ذخیره می‌کند (و در صورت عدم پشتیبانی به فایل نمایه SALTS.AES192+-CTR بازمی‌گردد) و از تابع pbkdf2 برای تولید کلید و IV جهت رمزگذاری داده‌ها استفاده می‌کند. برای رمزگشایی، کافی است پارامتر
.B saltgen
را حذف کنید.
.TP
.BI dd_rescue\ \-ptL\ lzo=compr,crypt=AES256-CTR:enc:keygen:ivgen:keysfile:ivsfile\ infile\ outfile
داده‌ها را (با استفاده از lzo) فشرده کرده و سپس رمزگذاری می‌کند. برای رمزگشایی و خروج از حالت فشرده از ترتیب معکوس استفاده کرده و keygen و ivgen را حذف کنید. فشرده‌سازی دارای اثر جانبی مطلوب مدیریت حفره‌ها است که در غیر این صورت به مقادیر غیرصفر فشرده می‌شوند (مگر اینکه skiphole را مشخص کنید). می‌توانید افزونه hash را در ابتدا یا انتها اضافه کنید تا چکسام‌های رمزنگاری برای هر دو فایل اصلی و فایل نهایی تولید شود.
.
.SH "همچنین ببینید (SEE ALSO)"
.BR dd_rescue (1)
.
.SH "نویسنده (AUTHOR)"
Kurt Garloff <kurt@garloff.de>
.
.SH "قدردانی‌ها (CREDITS)"
پیاده‌سازی بهینه‌شده AES با دستورالعمل‌های AESNI در x86 از مقاله‌ای سفید از اینتل در سال ۲۰۰۹ الهام گرفته شده است:
https://software.intel.com/sites/default/files/article/165683/aes-wp-2012-09-22-v01.pdf
.br
پشتیبانی از AES در ARMv8 با بررسی کدهای اسمبلی openSSL و همچنین پیاده‌سازی درون‌هسته‌ای Linaro الهام گرفته شده است.
.
.SH "حق نشر (COPYRIGHT)"
این افزونه تحت همان مجوز dd_rescue منتشر شده است: مجوز عمومی همگانی گنو (GPL) نسخه ۲ یا نسخه ۳ \- به انتخاب شما.
.
.SH "تاریخچه (HISTORY)"
افزونه ddr_crypt نخستین بار با dd_rescue نسخه 1.98 (مه ۲۰۱۵) معرفی شد.
.br
نسخه 1.99 پشتیبانی از شتاب‌دهنده رمزنگاری ARMv8 و پشتیبانی از اشتقاق کلید به سبک openssl و هدرهای Salted__ را به همراه داشت. همچنین ذخیره‌سازی اطلاعات مرتبط با pbkdf در xattr و پشتیبانی از ذخیره و بازیابی کلیدها (توصیه نمی‌شود!) و IVها در/از xattr را اضافه کرد. یک باگ در مقداردهی اولیه CTR برطرف شد (گزینه ctrbug198 را ببینید). نسخه 1.99.19 مدیریت تمیز حفره‌ها را در جهت معکوس فایل نیز فراهم کرد (برای حالت‌های CTR). فایل‌های رونوشت معکوس پیش از 1.99.19 ممکن بود با فایل‌های مستقیم تفاوت داشته باشند.
.PP
برخی اطلاعات تکمیلی را می‌توان در نشانی زیر یافت:
.br
http://garloff.de/kurt/linux/ddrescue