درباره (About)

این افزونه امکان رمزگذاری و رمزگشایی داده‌ها را به‌صورت بلادرنگ و همگام با نوشته‌شدن توسط dd_rescue فراهم می‌کند. این افزونه از انواع گوناگون رمزهای AES پشتیبانی کرده و در صورت وجود، از شتاب‌دهنده سخت‌افزاری در معماری‌های x86 (شامل AESNI) و ARMv8 برای دستیابی به کارایی بالا بهره می‌برد.

این افزونه برای dd_rescue نوشته شده و از رابط افزونه آن استفاده می‌کند. برای اطلاعات بیشتر درباره dd_rescue صفحه راهنمای dd_rescue(1) را ببینید.

راهنما (Help)

گزینه help را ارسال کنید تا ddr_crypt فهرست کوتاهی از گزینه‌ها را نمایش دهد.

رمزگذاری یا رمزگشایی (Encryption or Decryption)

باید به افزونه crypt در dd_rescue (که زین‌پس به‌اختصار ddr_crypt نامیده می‌شود و بازتاب‌دهنده بخش متغیر نام فایل libddr_crypt.so است) مشخص شود که قصد رمزگذاری دارد یا رمزگشایی. این کار با مشخص کردن پارامترهای enc[rypt] یا dec[rypt] در خط فرمان انجام می‌گیرد.

الگوریتم رمزگذاری/رمزگشایی (De/encryption algorithm)

افزونه crypt از چندین گونه مختلف رمزگذاری/رمزگشایی AES پشتیبانی می‌کند. می‌توانید با ارسال گزینه زیر گونه مورد نظر را تعیین کنید:

algo=AESxxx-yyy

که در آن xxx می‌تواند 128، 192، 256، +128، +192، +256، 128x2، 192x2 یا 256x2 باشد، و yyy می‌تواند ECB، CBC یا CTR باشد. برای دریافت فهرست الگوریتم‌های در دسترس، algo=help را ارسال کنید. برای بررسی تفصیلی گزینه‌ها، بخش «الگوریتم‌ها و حالت‌های جریانی» را ببینید. توجه داشته باشید که رمزگشایی یک فایل تنها در صورتی موفقیت‌آمیز خواهد بود که دقیقاً همان الگوریتمی انتخاب شود که هنگام رمزگذاری استفاده شده است. از روی فایل رمزگذاری‌شده به هیچ عنوان نمی‌توان فهمید چه الگوریتمی انتخاب شده بود.
حالت پیش‌فرض (AES192-CTR) انتخابی مناسب است به شرط آن‌که اطمینان حاصل کنید ترکیب کلید/IV هرگز مجدداً استفاده نمی‌شود.

موتور رمزنگاری (Crypto engine)

در حال حاضر پیاده‌سازی‌های متعددی از الگوریتم‌های AES وجود دارد که این افزونه می‌تواند از آن‌ها استفاده کند:

engine=aesni

از پیاده‌سازی اختصاصی AES با دستورالعمل‌های سخت‌افزاری AESNI پردازنده‌های x86 اینتل (از معماری Westmere به بعد) استفاده می‌کند. در صورت امکان بهتر است از این گزینه استفاده شود، زیرا علاوه بر کارایی بسیار بالاتر، از برخی حملات زمانی حافظه موقت (cache timing attacks) که پیاده‌سازی‌های مبتنی بر جدول جستجو ممکن است در معرض آن باشند جلوگیری می‌کند. این موتور از تمام الگوریتم‌ها پشتیبانی می‌کند.

engine=aesarm64

از پیاده‌سازی اختصاصی AES با افزونه‌های رمزنگاری AESv8 معماری ARMv8 (معماری AArch64 یا 64 بیتی ARM) استفاده می‌کند (در پردازنده‌ها/تراشه‌های مبتنی بر Cortex A53، A57، A72 آرم یا Kryo کوالکام یا A7x اپل و طرح‌های جدیدتر در دسترس است). در صورت امکان بهتر است از این موتور استفاده شود، زیرا علاوه بر کارایی عالی، از حملات زمانی حافظه موقت جدول‌های جستجو جلوگیری می‌کند. این موتور از تمام الگوریتم‌ها پشتیبانی می‌کند.

engine=aes_c

از پیاده‌سازی AES به زبان C که بر پایه کد مرجع rijndael است استفاده می‌کند. روی تمام پردازنده‌ها در دسترس است و از همه الگوریتم‌ها پشتیبانی می‌کند. عملیات واکشی اولیه (prefetching) روی جدول‌ها انجام می‌شود تا حملات زمانی حافظه موقت سخت‌تر شوند، اما برای دفع مهاجمان ماهر احتمالاً کافی نیست.

engine=openssl

از کتابخانه openssl برای پیاده‌سازی روال‌های AES استفاده می‌کند که در صورت وجود شتاب‌دهنده سخت‌افزاری از آن بهره می‌برد و در برابر حملات مقاوم‌سازی شده است. توجه داشته باشید که پیاده‌سازی openssl از گونه‌های + (تعداد دورهای افزایش‌یافته) که در موتورهای دیگر موجود است پشتیبانی نمی‌کند.

موتورها در صورت دسترسی به همین ترتیب اولویت استفاده می‌شوند، به این معنی که aesni به‌طور پیش‌فرض در صورت پشتیبانی روی x86 استفاده می‌شود، aesarm64 روی ARMv8 و aes_c به‌طور پیش‌فرض روی سایر پلتفرم‌ها به کار می‌رود.

پرکردن بلوک (Padding)

از آنجا که AES یک رمز بلوکی است (با اندازه بلوک ۱۶ بایت)، فایل‌هایی که اندازه آن‌ها مضربی از اندازه بلوک نیست در انتهای فایل نیاز به پرکردن (Padding) دارند تا یک بلوک کامل تشکیل شود.

pad=zero

بلوک آخر با صفر پر شده و سپس رمزگذاری می‌شود. توجه داشته باشید که هنگام رمزگشایی، این صفرها را نمی‌توان به‌طور خودکار حذف کرد، چرا که رمزگشا راهی برای تشخیص اینکه صفرهای انتهایی متعلق به داده اصلی بوده‌اند یا در فرآیند پدینگ اضافه شده‌اند ندارد. بنابراین این گزینه برای رونوشت فایل‌هایی با طول دلخواه پیشنهاد نمی‌شود.

pad=always

از طرح PKCS7 مورد استفاده در openssl استفاده می‌کند که یک تا شانزده بایت حاوی تعداد بایت‌های دورریختنی هنگام رمزگشایی را به انتها اضافه می‌کند. این روش همیشه امن است، اما همواره اندازه فایل خروجی را بزرگتر از فایل ورودی می‌کند. هنگام رونوشت فایل‌ها از این گزینه استفاده کنید. این مقدار پیش‌فرض است.

pad=asneeded

روشی ترکیبی میان zero و always است. اگر اندازه فایل یک بلوک کامل را پر نکند پدینگ PKCS7 انجام می‌دهد، اما اگر پر کند هیچ پدینگی اعمال نمی‌کند. این مکانیزم در بدترین حالت (نبود بایت‌های پدینگ) احتمال ۱/۲۵۵ برای ایجاد نتیجه رمزگشایی نادرست به دلیل حذف اشتباه پدینگ دارد (به این معنی که در فایل‌هایی با اندازه دلخواه احتمال کلی نادرست نشان دادن اندازه نهایی فایل ۱/۴۰۸۰ است). از این گزینه استفاده نکنید مگر اینکه بتوانید چنین خطاهایی را مدیریت یا حذف کنید!

توجه داشته باشید که حالت جریانی CTR نیازی به پدینگ ندارد و در واقع ddr_crypt هنگام استفاده از آن، صرف‌نظر از گزینه pad هیچ پدینگی اعمال نمی‌کند.

اشکال‌زدایی و محک‌زنی (Debugging and Benchmarking)

پارامتر debug باعث می‌شود ماژول ddr_crypt اطلاعات اشکال‌زدایی چاپ کند. با outkeyiv کلید و بردار مقداردهی اولیه (IV) در خروجی نمایش داده می‌شوند. پارامتر benchmark سرعت رمزگذاری/رمزگشایی را گزارش می‌دهد.

تنظیم مستقیم (Setting directly)

می‌توان آن‌ها را مستقیماً با استفاده از keyhex= و ivhex= در خط فرمان تعیین کرد. آرگومان به‌صورت نمایش هگزادسیمال ASCII از کلید/IV (بدون 0x اولیه) تفسیر می‌شود. این روش تعیین کلید/IV فقط باید برای اهداف آزمایشی استفاده شود؛ چرا که کلید با مشاهده خط فرمان برای تمام کاربران محلی قابل دیدن خواهد بود (مگر اینکه تمهیدات خاصی برای محدود کردن دسترسی به /proc اعمال شده باشد). این کار معمولاً در سیستم‌های چندکاربره ایده مناسبی نیست. ddr_crypt داده‌های حساس را با X بازنویسی می‌کند تا حمله کمی سخت‌تر شود، اما همچنان طول کلید افشا می‌شود و مهم‌تر از آن، بازه زمانی وجود دارد که داده‌های حساس در آن قابل مشاهده هستند.

خواندن از فایل یا توصیف‌کننده فایل (Reading from file or file descriptor)

بهتر است کلید و IV را از طریق یک توصیف‌کننده فایل با گزینه‌های keyfd= و ivfd= ارسال کنید. اگر پیش از عدد صحیح یک x قرار گیرد، کلید/IV به‌صورت رشته هگز خوانده می‌شود، در غیر این صورت داده‌ها به‌صورت باینری خوانده خواهند شد. به‌صورت اختیاری می‌توان @OFF@LEN را اضافه کرد که آفست و طول (به بایت) برای خواندن از فایل ارائه‌شده از طریق توصیف‌کننده فایل را مشخص می‌کند. توجه داشته باشید که توصیف‌کننده فایل 0 بدون تغییرمسیر شل، باعث نمایش اعلان تعاملی به کاربر می‌شود و پاسخ واردشده طبیعتاً روی صفحه نمایش داده نخواهد شد.
این روش بیشتر زمانی کاربرد دارد که dd_rescue از برنامه‌ای دیگر فراخوانی شود.

به‌عنوان جایگزین، با گزینه‌های keyfile= و ivfile= می‌توان نام فایلی را برای باز کردن و خواندن مشخص کرد. قالب نحوی از همان ساختار اختیاری @OFF@LEN پشتیبانی می‌کند، اما کلید و IV همیشه به‌صورت باینری خوانده خواهند شد. (برای روش خواندن به‌صورت هگز، بخش فایل‌های نمایه را در زیر ببینید.) در حال حاضر (برخلاف سالت) راهی برای استفاده از ddr_crypt جهت نوشتن داده‌های باینری کلید و IV با این گزینه‌ها وجود ندارد.

تولید کلید و IV تصادفی (Generating random key and IV)

می‌توان از تولیدکننده اعداد تصادفی سیستم‌عامل برای تولید بلادرنگ کلید و IV استفاده کرد؛ اگر سیستم شما اعداد تصادفی با کیفیت تولید کند، این امن‌ترین روش برای تعیین کلید رمزگذاری است. گزینه‌های مربوطه عبارتند از: keygen و ivgen . شما باید کلید/IV را به نحوی ذخیره کنید، در غیر این صورت بعداً قادر به رمزگشایی نخواهید بود (برنامه به شما هشدار خواهد داد!). بهترین روش استفاده از گزینه‌های بعدی است.

فایل‌های نمایه (Index files)

کلیدها و IVها را می‌توان به‌صورت رشته‌های هگز در فایل‌های نمایه ذخیره کرد؛ قالب فایل مانند قالب استفاده‌شده در MD5SUMS است: نمایش هگزادسیمال کلید/IV و در ادامه نام فایل قرار می‌گیرد. بدیهی است که باید دقت لازم برای محرمانه نگه داشتن این فایل‌ها به کار گرفته شود.

اگر به افزونه ddr_crypt گزینه‌های keysfile و ivsfile داده شود، کلیدها/IVهای ایجادشده (از سایر گزینه‌ها) را در فایل‌هایی با نام KEYS.algname و IVS.algname با فرمت MD5SUMS ذخیره می‌کند. (فایل‌ها متناسب با نیاز ایجاد یا به‌روزرسانی می‌شوند.) اگر کلید/IV هنوز ایجاد نشده باشد، ddr_crypt تلاش می‌کند کلید/IV را از آن فایل‌ها بازیابی کند و در صورت عدم موفقیت با خطا خارج می‌شود.
این گزینه‌ها هنگام رمزگذاری به‌خوبی با keygen و ivgen ترکیب می‌شوند (و هنگام رمزگشایی باید به‌تنهایی استفاده شوند).

ویژگی‌های توسعه‌یافته (Extended attributes)

مشابه فایل‌های نمایه، کلیدها و IVها را می‌توان در ویژگی‌های توسعه‌یافته (xattr) فایل رمزگذاری‌شده نیز ذخیره و بازیابی کرد. این کار با استفاده از گزینه‌های keyxattr و ivxattr انجام می‌شود. لطفاً نکات مربوط به استفاده از ویژگی‌های توسعه‌یافته را در صفحه راهنمای اصلی dd_rescue(1) مطالعه کنید.
توجه داشته باشید که ذخیره کلید در xattr معمولاً ایده مناسبی نیست کاربری که به فایل رمزگذاری‌شده دسترسی دارد (به‌صورت محلی) می‌تواند xattrها را نیز بخواند؛ بنابراین محرمانگی که معمولاً با رمزگذاری حاصل می‌شود از این طریق از بین می‌رود. (البته سناریوهای معتبری وجود دارد، مثلاً زمانی که خود فایل فقط از طریق یک پروتکل راه دور که xattr را افشا نمی‌کند مانند http یا DAV یا NFS قابل دسترسی باشد.)
همچنین می‌توانید گزینه‌های kxfallb[ack] و ixfallb[ack] را مشخص کنید تا ddr_crypt در صورت عدم پشتیبانی سیستم فایل از ویژگی‌های توسعه‌یافته، تلاش کند از xattr استفاده کند و در صورت نیاز به keysfile و ivsfile بازگردد (fallback).

تولید کلید و IV مبتنی بر گذرواژه (Password based key and IV generation)

استفاده از کلید/IV یکسان برای فایل‌های متعدد به امنیت آسیب جدی می‌زند (بخش «الگوریتم‌ها» را در زیر ببینید). بنابراین استفاده از کلید مشخص‌شده مستقیم (غیرتولیدی) ایده خوبی نیست. با این حال، اگر ترجیح می‌دهید به جای ذخیره‌سازی از عبارتی به یادماندنی استفاده کنید، می‌توانید از گذرواژه و سالت (salt) برای تولید چندین کلید از یک گذرواژه استفاده کنید.

کلید و IV از یک تابع محاسباتی سنگین (و با معکوس‌پذیری به مراتب سنگین‌تر) روی گذرواژه و سالت مشتق می‌شوند. به‌طور پیش‌فرض، ddr_crypt از ۱۷۰۰۰ دور pbkdf2() برای کلید (و یک‌سوم آن برای IV) استفاده می‌کند، اگرچه توابع سنگین‌تری (مانند scrypt) برای آینده برنامه‌ریزی شده‌اند. سنگینی محاسباتی این تابع محافظتی در برابر حملات جستجوی فراگیر (brute force) گذرواژه است. برای استفاده از pbkdf2 باید pbkdf2 یا pbkdf2=rounds را مشخص کنید. فرمت دوم امکان تغییر تعداد تکرارها برای تولید کلید را می‌دهد (تولید IV مجدداً با یک‌سوم این تعداد انجام خواهد شد).

برای سازگاری با openssl، کلید و IV را می‌توان با استفاده از تابع اشتقاق کلید سازگار با openssl با گزینه opbkdf مشتق کرد. توجه داشته باشید که این روش توصیه نمی‌شود؛ زیرا تنها از یک دور درهم‌سازی md5 استفاده می‌کند که حملات brute force را بسیار کارآمد می‌سازد. استفاده از این گزینه همچنین دارای اثر جانبی نوشتن (در رمزگذاری) یا تجزیه (در رمزگشایی) هدر به سبک OpenSSL یعنی Salted__ است. توجه داشته باشید که openssl از نسخه 1.1 به بعد به‌طور پیش‌فرض از یک دور درهم‌سازی sha256 استفاده می‌کند که در نسخه‌های قدیمی‌تر openssl با سوییچ md sha256- اجباری می‌شد و با مشخص کردن md md5- در خط فرمان openssl قابل بازنویسی بود. می‌توانید با مشخص کردن opbkdf11 به dd_rescue دستور دهید از یک KDF سازگار با openssl به همراه sha256 استفاده کند. یک دور sha256 نیز البته همچنان می‌تواند با کارایی بالا هدف حمله brute force قرار گیرد، بنابراین اگر واقعاً ناچار به استفاده از این روش هستید از گذرواژه‌هایی با آنتروپی بالا استفاده کنید. nosalthdr . نرم‌افزار openssl از نسخه 3.0 در صورتی که سالت صراحتاً ارسال شود دیگر هدر Salted__ را نمی‌نویسد. برای سازگاری با نسخه 3.0 به بالا، این گزینه اجازه می‌دهد تا این هدر دیگر نوشته نشود (هنگام رمزگذاری) و به دنبال آن نیز گشته نشود (هنگام رمزگشایی).

سالت را می‌توان به‌طور خودکار از نام (و طول) فایل رمزگذاری‌شده مشتق کرد؛ این کار امکان کار با تنها یک گذرواژه به یادماندنی را فراهم می‌کند. با این حال، آگاه باشید که تغییر اندازه یا نام فایل منجر به سالت متفاوت و در نتیجه کلید/IV متفاوت می‌شود که فایل رمزگذاری‌شده شما را غیرقابل رمزگشایی می‌کند. اگر احتمال وقوع چنین اتفاقی وجود دارد، بهتر است برای هر فایل یک سالت به خاطر بسپارید (یا ترجیحاً کلید و IV را با گزینه‌های keysfile و ivsfile ذخیره کنید یا سالت را با saltsfile یا saltxattr ذخیره نمایید؛ توضیحات زیر را ببینید). به یاد داشته باشید که نام فایل‌ها (مانند همیشه در یونیکس) به حروف کوچک و بزرگ حساس هستند. بدیهی است که فایل keysfile باید در برابر خوانده شدن توسط افراد غیرمجاز به‌خوبی محافظت شود.

گذرواژه و سالت را می‌توان با یک رشته از طریق pass= و salt= یا با استفاده از گزینه‌های passfd= passfile= و salthex= saltfd= saltfile= با همان پارامترهای ممکن بالا برای تعیین مستقیم کلید و IV مشخص کرد. (توجه داشته باشید که سالت مانند حالت اشتقاق از نام و طول فایل، هش می‌شود.) گذرواژه/عبارت عبور به‌صورت یک رشته با پایان تهی (null-terminated) در نظر گرفته شده و کاراکتر CRLF انتهایی آن حذف می‌شود.
هشدارهای مربوط به ارسال داده‌های محرمانه (در اینجا: pass، salt، salthex) در خط فرمان در اینجا نیز صدق می‌کند؛ فقط برای آزمایش یا در محیط‌های تک‌کاربره این کار را انجام دهید. استفاده از passfd=0 امکان ارسال گذرواژه از طریق پایپ را فراهم می‌کند.

اگر از اشتقاق خودکار سالت بر اساس نام فایل استفاده شود، طول فرض‌شده فایل برای تولید سالت را می‌توان با saltlen= تغییر داد.

به‌عنوان روش جایگزین، سالت‌ها را می‌توان با مشخص کردن گزینه saltsfile در یک فایل نمایه به سبک MD5SUMS (مشابه keysfile و ivsfile) ذخیره و بازیابی کرد. هنگامی که saltsfile برای ذخیره سالت‌ها استفاده می‌شود، استفاده از سالت‌های تصادفی هنگام رمزگذاری انتخابی بسیار مناسب خواهد بود. این کار با مشخص کردن گزینه saltgen انجام می‌شود.

به جای فایل نمایه سالت (saltsfile)، سالت را می‌توان در یک ویژگی توسعه‌یافته (xattr) نیز ذخیره (و از آن بازیابی) کرد. این کار را می‌توان با گزینه saltxattr[=xattr_name] انجام داد. نام ویژگی اختیاری است و مقدار پیش‌فرض آن user.salt.ALGNAME است (که در آن ALGNAME با نام الگوریتم جایگزین می‌شود). از نسخه 1.99 افزونه ddr_crypt، تابع اشتقاق کلید مبتنی بر گذرواژه (و تعداد دورهای آن) نیز با این گزینه در ویژگی user.pbkdf ذخیره و بازیابی می‌شود.
همچنین می‌توان تلاش کرد از قابلیت xattr استفاده کرد و در صورتی که سیستم فایل از ویژگی‌های توسعه‌یافته پشتیبانی نکند، به استفاده از فایل نمایه (saltsfile) بازگشت. از گزینه sxfallback استفاده کنید تا به ddr_crypt دستور انجام این کار را بدهید. توجه داشته باشید که اگر بازگشت (fallback) رخ دهد، pbkdf ذخیره (یا بازیابی) نمی‌شود.
برای بررسی مزایا و معایب استفاده از ویژگی‌های توسعه‌یافته، صفحه راهنمای اصلی dd_rescue(1) را ببینید.

حالت‌های پلاس (Plus modes)

با توجه به اینکه شناخته‌شده‌ترین حملات علیه نسخه‌های AES با تعداد دورهای کاهش‌یافته و آن هم با کاهش اندک دورها بوده است، به نظر می‌رسد افزایش تعداد دورها یک اقدام متقابل منطقی در برابر حملات رمزنگاری باشد. (این ایده از نظری از بروس اشنایر الهام گرفته شده که نویسنده این سند احترام بسیار زیادی برای او قائل است.)

پیاده‌سازی‌های C و AESNI از حالت‌های AES128، 192 و 256 با ۲، ۳ و ۴ دور اضافی پشتیبانی می‌کنند که به ترتیب منجر به ۱۲، ۱۵ و ۱۸ دور می‌شود. این حالت‌ها به ترتیب +AES128، +AES192 و +AES256 (حالت‌های پلاس) نامیده می‌شوند. آن‌ها روشی نسبتاً ارزان از نظر محاسباتی برای ارتقای امنیت ارائه می‌دهند. برای نمونه، نویسنده این سند +AES192 را به AES256 ترجیح می‌دهد. اگرچه نویسنده این سند هرگز خود را متخصصی آنچنان برجسته در رمزنگاری نمی‌داند که الگوریتم‌های جدید بسازد یا تغییرات بنیادین در الگوریتم‌های موجود ایجاد کند، اما این دگرگونی را انتخابی امن‌تر از نسخه اصلی می‌داند. لطفاً توجه داشته باشید که این الگوریتم‌های سفارشی منجر به ایجاد فایل‌هایی می‌شوند که با هیچ ابزار دیگری قابل رمزگشایی نیستند. همچنین موتور openSSL از حالت‌های پلاس پشتیبانی نمی‌کند.

حالت‌های دوگانه (Double modes)

یک روش سنگین‌تر از نظر محاسباتی برای ارتقای امنیت، دو برابر کردن تعداد دورها است. این کار معادل دو بار رمزگذاری است (که در آن کلید دوم یک اشتقاق ساده از کلید اول است). این روش‌ها توسط تمامی موتورها پشتیبانی می‌شوند و AES128x2، AES192x2 و AES256x2 نام دارند.

حالت‌های جریانی (Stream modes)

الگوریتم AES یک رمز بلوکی است؛ یعنی بلوک‌های ۱۶ بایتی را تبدیل می‌کند. ساده‌ترین روش اعمال آن روی فایلی با اندازه دلخواه، اعمال آن روی تک‌تک بلوک‌های فایل است. این حالت ECB (کتاب رمز الکترونیکی) نامیده می‌شود. این حالت بسیار ناامن است... ورودی یکسان همیشه به خروجی یکسان منجر می‌شود. الگوها به‌راحتی قابل تشخیص هستند و حملات متن آشکار معلوم (known plaintext) روی آن پیش‌پاافتاده است.

بهتر است فرآیند تبدیل به محتوای پیشین فایل یا موقعیت درون آن وابسته شود. این همان کاری است که حالت‌های CBC (رمزگذاری زنجیره‌ای بلوک‌ها) و CTR انجام می‌دهند.

حالت CBC دارای چندین عیب است: نمی‌توان آن را موازی‌سازی کرد (در رمزگذاری هر بلوک به تمامی بلوک‌های پیشین وابسته است؛ البته وضعیت در رمزگشایی بهتر است) و دسترسی تصادفی به بخش‌های فایل غیرممکن است.

حالت CTR دارای ویژگی‌های مطلوب بسیاری است. این حالت اساساً جریانی از اعداد شبه‌تصادفی (تکرارپذیر) است که برای رمزگذاری با ورودی XOR می‌شوند. رمزگشایی نیز طبیعتاً یک عملیات XOR دیگر است. این روش مانند پد یک‌بارمصرف (one-time pad) عمل می‌کند که اثبات شده در صورت ناشناخته بودن پد برای مهاجم و استفاده تنها برای یک‌بار، کاملاً امن است.
نکته اخیر را هرگز نمی‌توان بیش از حد مورد تأکید قرار داد: هرگز از یک ترکیب کلید/IV یکسان برای دو فایل استفاده نکنید. به زبان ریاضی:

c1 = r1 XOR p1
c2 = r2 XOR p2

c1 XOR c2 = r XOR p1 XOR r XOR p2 = p1 XOR p2

حالت CTR ویژگی‌های خوب دیگری نیز دارد: امکان دسترسی تصادفی را فراهم می‌کند، زیرا اعداد تصادفی AES (متعلق به یک ترکیب کلید/IV) با یک آفست مشخص مستقیماً قابل محاسبه هستند و بلوک آخر نیازی به پدینگ ندارد؛ زیرا بلوک‌های ناقص نیز قابل پردازش هستند.

نویسنده این سند حالت جریانی CTR را ترجیح می‌دهد و اطمینان حاصل می‌کند که کلیدها/IVها مجدداً استفاده نشوند.

بلوغ و پایداری (Maturity)

این افزونه با dd_rescue نسخه 1.98 معرفی شد. از آن زمان تاکنون استفاده و آزمایش‌های زیادی را پشت سر گذاشته است، اما همچنان هنگام تکیه بر آن به‌عنوان تنها نسخه پشتیبان برای داده‌های بسیار ارزشمند باید احتیاط کرد.

به دلیل اشکالی در مقداردهی اولیه IV برای حالت CTR در dd_rescue نسخه 1.98، آخرین ۳۲ بیت همیشه قبل از اضافه شدن شمارنده صفر می‌شدند. این مشکل در نسخه 1.99 برطرف شده است. برای حفظ سازگاری با نسخه 1.98، گزینه ctrbug198 را می‌توان در خط فرمان مشخص کرد.

امنیت (Security)

اگرچه دقت لازم برای بررسی نتایج تخصیص‌های حافظه به کار گرفته شده است، اما کد مورد ممیزی کامل قرار نگرفته و تنها فازینگ (fuzzing) محدودی برای اطمینان از عدم آسیب‌پذیری در برابر داده‌های مخرب انجام شده است؛ بنابراین هنگام پردازش داده‌ها از منابع غیرقابل اعتماد احتیاط کنید.
مدیریت کلیدها کاری پیچیده است؛ ممکن است نویسنده در بخش‌هایی مرتکب خطاهای غیربدیهی شده باشد که باعث شود برخی روش‌های استفاده از این برنامه برای رمزگذاری داده‌ها به سطح محرمانگی مورد نظر نینجامد.

آزمون و تست (Testing)

افزونه crypt در حال حاضر پوشش آزمایشی مناسبی را کسب کرده است، اما انجام آزمون‌های بیشتر قطعاً مطلوب خواهد بود.

ترتیب زنجیره افزونه‌ها (Plugin chain ordering)

اگر چندین افزونه را به صورت زنجیره‌ای استفاده می‌کنید (dd_rescue از این قابلیت پشتیبانی می‌کند)، لطفاً اطمینان حاصل کنید که هیچ افزونه‌ای اندازه/آفست‌ها را بعد از ddr_crypt در رمزگذاری و قبل از ddr_crypt در رمزگشایی تغییر ندهد. اگر چنین کنید، محاسبه موقعیت در فایل با اختلال مواجه شده و مقدار نادرستی برای شمارنده در حالت CTR استفاده خواهد شد. این موضوع روی ECB تأثیری ندارد، اما ECB معمولاً انتخاب مناسبی نیست. این محدودیت به این معنی است که شما می‌توانید داده‌ها را ابتدا فشرده و سپس رمزگذاری کنید، و هنگام بازیابی ابتدا رمزگشایی و سپس از حالت فشرده خارج نمایید. این یک انتخاب طراحی بوده است؛ چرا که داده‌های رمزگذاری‌شده غیرقابل فشرده‌سازی هستند و ترتیب دیگر عملاً هیچ معنایی ندارد.

کارهای آینده (Future work)

به جز آزمایش‌های بیشتر و ممیزی کد، چند ویژگی دیگر برای این افزونه در نظر گرفته شده است:
پشتیبانی از سایر الگوریتم‌های غیر AES مانند twofish (و احتمالاً threefish).
تابع قوی‌تر برای اشتقاق کلیدها/IVها از گذرواژه نسبت به pbkdf2.
پشتیبانی از سایر حالت‌های جریانی (XTS، GCM، ...).