題:
加密算法的選擇本身不會增加熵嗎?
Robert
2019-01-30 17:22:18 UTC
view on stackexchange narkive permalink

假設某人擁有我的加密數據,而他想對其解密。人們總是在談論密鑰的長度(例如256位)如何決定加密的熵,這完全是有道理的。如果攻擊者嘗試所有2 256 sup>種可能性,那麼他的曾曾曾孫會擁有我的數據。

但是如果這些年來他一直使用錯誤的算法怎麼辦? ?算法本身的選擇不是也增加了熵,還是我做錯了呢?因此,與其為我的文件 super_secret.aes256 命名,不如將其命名為 super_secret.rsa256 ,甚至可能根本不給它結尾的文件?

假設您在2019年可以選擇8種具有256位密鑰的密碼,並且攻擊者無法查看密碼文本並告訴使用哪種算法,那麼您的秘密算法選擇就是添加log2(8)= 3位熵。與密鑰的256位相比,這可以忽略不計。
@MikeOunsworth同樣值得考慮的是,某些密碼的應用可能需要花費更長的時間,但是實際上大多數加密格式都明確指出了無論如何都在使用哪種密碼。
您是否可以使用旁道攻擊來發現它是對稱密鑰算法還是公共密鑰算法?
有一種情況是有用的,加密方案是由您創建的,儘管很難實現,但您從未透露過該設計。比幾乎不可能打破。
@kelalaka如果您(或我)(或在同行中評論不多的幾十年以下的人)發明了我們自己的加密方案,則可以肯定的是,它[太弱了](https://crypto.stackexchange.com/q / 43272/17796)它將以數十種方式被破解,這些方式比暴力破解要快得多。
@Matija Nalis,加密不只是應用密碼。發明密碼需要大量的研究,計算和知識。“發明自己的加密”意味著考慮如何混合使用現有工具來保護通信。它包括詳細信息,例如密鑰的交換方式,密鑰是否有過期時間,組織中的誰可以認證密鑰,將使用哪種密碼,如果服務無法相互信任會發生什麼……
@sleblanc當然可以,但是即使您僅使用已知的安全密碼,也存在[很多] [https://crypto.stackexchange.com/]a / 205/17796)[陷阱](https://research.swtch.com/openssl)供那些在該領域不熟悉的人使用。(另外,這個問題只與密碼有關,而不是PKI或您在加密世界中可能遇到的其他問題)
查找[BassOmatic](https://en.wikipedia.org/wiki/BassOmatic)。
七 答案:
John Deters
2019-01-30 20:05:41 UTC
view on stackexchange narkive permalink

如果您正在設計密碼系統,答案是 Kerckhoffs的原理指出:“即使系統中除密鑰之外的所有內容都是公共知識,加密系統也應該是安全的。”重申為香農的格言,這意味著“應該在假設敵人會立即完全熟悉它們的前提下設計系統。”

使攻擊者不會學習您的算法的假設是通過隱蔽性實現安全性,這是一種被認為不足的安全性方法。

依靠攻擊者不知道該算法不會在他或她的目標上增加任何工作,因為根據Kerckhoff的說法,他或她已經知道了,或者可以合理地期望找出來。如果不增加不確定性,則不增加熵。而且它們的功能無法量化。

在丟失密碼系統的情況下(如您所述),通常有足夠的歷史或統計信息來確定算法的性質(如果不是密鑰本身)。但是您無法設計系統假設它將在使用後立即丟失。那是OpSec,而不是加密技術。

編輯提到了使用算法選擇作為鍵的一部分的註釋。這種方法的問題在於必須在解密數據之前確定算法選擇。如今,這正是TLS等協議的工作方式。

如果您真的想將算法混合在一起並使用關鍵因素來確定諸如S-box選擇之類的內容,那麼您實際上就是在創建一種新的奇異算法(採用所有方法並且,如果您創建了一個新算法,那麼密鑰的所有位都是該熵計算的一部分。但是,如果您可以指出確定算法而不是密鑰材料的特定位,則仍必須將它們視為協議位並排除它們。

關於算法的保密性,今天您的協議可能是保密的,但是即使您的一個代理被發現並複制了他的系統,即使沒有密鑰被洩露,舊消息也不再使用保密算法。您可能歸因於它們的任何“熵”都會丟失,您甚至可能不知道。

這不是安全隱患。它不是“依賴設計或實現的保密性作為提供安全性的主要方法”。您可以使用相同的推理來論證,假設攻擊者找不到您的私鑰就是安全隱患。擔心通過選擇算法添加的熵沒有多大意義,因為無論如何您都可以通過密鑰獲得足夠的熵。
@FINDarkside“ _您可以使用相同的推理方法..._”區別在於,只要有適當的密鑰管理,攻擊者就永遠無法算出您的私鑰。但是,您必須假定他們有機會發現越來越多的任何實現細節,例如通過對代碼進行反向工程。
@FINDarkside,查詢者正在詢問實現的保密性是否會增加熵。換句話說,他特別詢問是否應該將模糊性帶來的安全性納入方程式。答案之所以如此,在一定程度上是因為沒有辦法量化攻擊者在這方面的能力。您是正確的,所有熵都必須源於密鑰。
獲取有關該算法的信息需要一定的能量,無論是人類智能,逆向工程還是社會工程,您都可以將其與平均能量所需的能量一起考慮在內,以使他們在了解算法後就可以規避您的算法。也許在某些情況下,這可以用於組織中的安全性判斷。正如您所指出的那樣,從信息科學的角度來看,“密碼學”超出了範圍並且無法量化。
我要指出的是“隱秘的安全”方面,但我看到您已經涵蓋了這一點。向我+1。
@TripeHound您假設算法的選擇是一個能夠被發現或進行反向工程的實現細節。它同樣可以作為加密/解密過程的輸入(例如,用戶每次從列表中選擇算法)。在這種情況下,算法的選擇實際上成為關鍵的一部分。編輯:我只是注意到您實際上發布了對此效果的答案。我將留下此評論,因為此答案並未考慮這種可能性,而且IMO的書面規定是錯誤的。“否”應讀為“取決於”。
@FINDarkside問題是您無法以與保護密鑰相同的方式來保護算法。該密鑰可以從系統中省略(單獨存儲,甚至僅存儲在一個人的內存中),但是算法不能(假設我們不允許用戶通過任意代碼上傳自己的密鑰)。攻擊者至少將具有與合法用戶一樣多的算法訪問權限,甚至可能更多。
@jpmc26問題沒有提到任何實時服務器或系統。如果我有大量數據,我就不能僅僅“找出”算法,因為Kerckhoff表示您應該假設可以。
-1
@jpmc26感覺就像您在對該“系統”進行假設。在某些情況下,假定加密文件時攻擊者尚未滲透到系統中,則算法與私鑰一樣被“分隔”。我認為對此沒有任何爭論。
@FINDarkside如果沒有一些基本假設,您甚至無法進行討論。在我看來,您甚至根本不想討論,但您在這裡進行辯論。有數據。它生活在某個地方。該算法從本質上將加密數據與密鑰綁定在一起。例如,它與輸入/輸出* format *綁定,獲取數據的攻擊者知道該格式。
@FINDarkside,我想我知道您來自哪裡。您正在考慮一種“丟失的消息”方案,該方案沒有上下文或相關信息。您還考慮保密,甚至可能是為了避免被發現。這些是OpSec的屬性,絕對可以幫助提高整體安全性。但是,由於它們不是由數學確定的,因此無法作為熵計算的因數。這樣想:您的整體安全性包括算法的熵作為一個組成部分,但是整體安全性不是由熵來衡量的,而是由風險來衡量的。
@JohnDeters好的,我現在明白了,很抱歉造成混亂。
@jpmc26 NSA Suite A算法均已分類,並且AFAIK沒有當前算法被洩漏。我的理解是,它們通常是在篡改後歸零的軟件中實現的。一方面是它成功地避免了學術審查,所以大學沒有為他們從事外國情報工作。
@jpmc26我認為您在談論蘋果(算法),而OP在談論橙子(算法的*選擇*)。該實現需要包含實際的算法(因此攻擊者可以發現它們),但是使用哪種算法的“選擇”可以像密鑰一樣保留在用戶的頭腦中。
-1
TripeHound
2019-01-30 20:49:59 UTC
view on stackexchange narkive permalink

實際上,不,正如 John的答案清楚地解釋的那樣。

假設,如果您有足夠的安全加密方法可供選擇,可能會隨機選擇一種方法,並使用它來加密數據,例如使用256位密鑰。所使用的算法選擇需要“添加”到密鑰上,並成為“ 不被透露的秘密”的一部分(如果要選擇八種加密算法,則將組合熵取為259位)

執行此操作的問題包括:

  • 僅添加了少量位:八種算法僅添加了三位熵。要添加八位(使用256位密鑰的總264位),將需要256種不同的加密算法。幾乎可以肯定,要找到足夠的安全算法來產生實際的效果,要比簡單地擴展單個已知攻擊者算法的密鑰長度要困難得多。

  • 您必須使用算法選擇來“擴展”密鑰:這意味著將選擇項傳遞給“用戶”,以便與普通密鑰一起“記住”。這極大地使密鑰管理過程複雜化。將選擇存儲在加密數據中並不是一件容易的事,因為具有“全面知識”的攻擊者將能夠找到信息並知道使用哪種算法。

  • 如果任何選擇的算法都會留下某種“指紋”,使攻擊者能夠識別所使用的算法(或至少減小可能算法的範圍),然後這將(部分)使熵的額外比特無效。

總而言之,擴展使用的密鑰的長度要容易得多,而不必擔心攻擊者知道加密方法。

更糟的是,有必要以某種方式提出算法選擇中使用的位。如果一個人擁有一種可以使用256位密鑰的算法,而真正擁有一個256位熵的算法,那麼由於熵不足而造成損害的可能性實際上將為零。如果沒有256位的實際熵,那麼採用本可以用於密鑰生成的熵並將其用於算法選擇將不會有任何改善。
我想如果您想對這個問題真的很痴迷,可以*允許*用戶上傳自己的算法,而不是從預定義列表中進行選擇。但是,與任意代碼執行相關的不利因素,大多數用戶不會選擇安全算法的事實以及用戶管理此代碼的難度不斷增加,顯然超過了任何好處。
Kerckhoffs原理的一種解釋是,必須保密的信息“包含”密鑰,這就是我們在這裡所說的。因此,從固定的8組中選擇算法需要在密鑰存儲區中額外增加3位。您所編碼的算法選擇會為密鑰存儲增加更多的數量(至少是代碼的Shannon熵)。這不是很好的位價值。
Conor Mancone
2019-01-31 02:06:06 UTC
view on stackexchange narkive permalink

@John Deter和@TripeHound的答案很好地解釋了事情,但是我想舉一個例子,將Kerckhoffs的原理放在上下文中。從外部攻擊者的角度來解決這些問題是很自然的,但這不是唯一的相關威脅模型。實際上,所有數據洩露中大約有一半是從內部代理(又名員工,承包商等)開始的,其中既有偶然的洩漏也有故意的洩漏。

具有隱藏的加密算法 可以幫助外部攻擊者輕鬆推斷出您使用的系統。但是,對於可以訪問您的代碼的內部攻擊者,它絕對不會提供任何額外的保護。舉一個極端的例子,如果您的系統在數據庫中保留了關鍵的個人身份信息(PII),但是生產數據庫訪問憑據,加密算法和加密密鑰都直接存儲在代碼存儲庫中,那麼您就有效地賦予了所有有權訪問的人

當然,您不想這樣做,因此您可以將生產系統與每個期望管理員分開,將加密密鑰存儲在單獨的位置密鑰管理系統只能(盡可能)只能由應用程序訪問,等等。。。開發人員知道使用了哪種加密算法(因為他們可以在代碼存儲庫中看到它),但是他們無權訪問生產數據庫,即使他們確實獲得了對數據庫的讀取訪問權限,他們也沒有密鑰來解密其中的數據。

應用Kerckhoff原理

這就是Kerckhoffs原理的全部要點-您唯一需要保守秘密的就是實際秘密(也就是您的加密密鑰)。所有人都可以知道其他所有內容,但是您仍然是安全的。這很好,因為僅保留一個秘密就足夠了。試圖設計一種不僅向所有人隱藏密鑰,而且向所有人隱藏加密算法和其他細節的系統,要困難得多,而且容易出現故障。

總之,人們不擅長保密。結果,對系統進行設計以使您擁有更少的秘密來進行保護實際上可以使您更多安全,即使這看起來很不直觀。畢竟,您的建議在某種程度上是有道理的:為什麼我們只應加密數據?讓我們也隱藏加密方法並提高安全性!不過,在實踐中,隱藏更多的東西可以使您有更多的空間犯錯,並帶來虛假的安全感。最好使用一種有效的加密方法,該方法使秘密盡可能地簡單-隱藏密鑰,確保消息的安全。

Christoph Burschka
2019-01-31 22:32:01 UTC
view on stackexchange narkive permalink

抽像地講,如果有2 ^ n個完全難以破解的加密方案,並且具有相同的可用密鑰空間,那麼可以肯定的是,您可以定義一個新的加密方案,因為“隨機選擇2個方案”,並有效地考慮將這n位添加到密鑰中。

但是在實踐中,即使有可能,當您只選擇一個算法並設置一個按鍵時間更長。

drjpizzle
2019-02-01 05:56:31 UTC
view on stackexchange narkive permalink

我認為OP的問題表明了洞察力,答案至少在理論上是肯定的。這裡有東西。我認為這是應該提出的第一點。給出的答復大部分是這樣的:在實踐中,它不是那樣工作的。這不是錯誤的,但我認為他們錯過了OP觀點的有效性/興趣。我之所以這樣認為:從理論上的黑匣子角度來看,兩個加密系統之間的選擇類似於選擇密鑰的第一位。實際上,它們確實是同一回事(如果再加上一點)。在黑匣子中,密鑰確實沒有什麼特別的。它們只是枚舉您要使用哪種加密轉換的選項的好方法。

要查看此信息:

說,我製作了一個新的AES128變種,稱其為JES_0_128。它的工作方式是:我在提供的密鑰的開頭添加二進制編碼0(在這種情況下為128個零),並在(標準)AES256中使用它。然後,我再創建一個名為JES_1_128的編碼:一直到JES_(無論以2為基數的128還是10的基數)_128的編碼。所有這些都是完全有效的128位密鑰加密算法。但是,如果您不知道是哪一個...這是256位密鑰加密算法。精確地說是AES256。確實確實有更多的熵。

另一個答案指出的差異是,實際上,密鑰是從2 ^ 256個AES-256加密算法中選擇使用哪種的一種非常好的方法。靈活,易於理解,並將生成和信任彼此的秘密留給用戶。為什麼還要使用其他東西?

另一方面,選擇少數256位加密算法家族之一來使用並對其進行硬編碼不是一個好方法。即使相對於密鑰大小的很小增加。或完全沒有。您最好也告訴所有人。從實用/編寫軟件/類型的角度來看,將其與任何感興趣的攻擊者隔離都是不安全的。原因有很多。尤其重要,因為如果攻擊者擁有副本,那麼您選擇的值將很容易測試。但這只是“實際”考慮...

Damon
2019-01-31 19:38:26 UTC
view on stackexchange narkive permalink

如果您僅使用一種算法對某事物進行加密並假裝使用了另一種算法,那麼Kerckhoff的原理就如其他答案所指出的那樣適用,因此這至少對了解我們實現知識的攻擊者毫無用處。它仍然可以“對抗”攻擊者,例如

如果您需要選擇加密算法以包含在解密過程中(即您的工具從多種算法中選擇一種,取決於您輸入的內容),然後有效地在密鑰長度中添加位。 Kerckhoff的原理在這裡適用。但是,要添加大量的位有點困難-一個位需要很多算法來選擇-而且這沒有任何意義(請參閱最後一段)。

無論哪種情況,無論你想做的幾乎沒有意義。假設某人的曾曾孫子女如果投資數十億美元購買設備和eletricity賬單,則可能會擁有您的數據,這對於90-100位範圍的密鑰可以說是正確的。儘管實際上,沒有人(甚至是國家安全局)也不會這樣做。成本效益比並沒有體現這一點。社會工程或酷刑再加上謀殺是一種更便宜,更快捷,更實用的方法。

對於任何明顯大於110比特的東西,即使您忽略了暴力攻擊,也是不現實的成本效益比。您應該更加擔心內置於AES的後門,這比您在一生中看到一個 128位密鑰被蠻力破壞更容易。

現在,僅僅通過蠻力破解256位密鑰的想法是完全荒謬的,在其之上添加位的想法是荒謬的,它的差值恰好為零。不可能比“不可能”要好。

我真的看不出這對已經給出的其他答案有什麼幫助。你能詳細說明嗎?
@TomK:如果沒有別的,那麼即使考慮蠻力地使用256位密鑰或其假設後果也是荒謬的(或添加到256位密鑰)這一事實。似乎沒有其他人考慮。儘管強行使用強行破解128位密鑰的可能性的思考已經足夠荒謬了,儘管這在物理上是可能的。
benrg
2019-02-04 00:31:25 UTC
view on stackexchange narkive permalink

我認為這是查看它的好方法:

您有一個秘密,它可能是256位密鑰,或者是您從中獲得該密鑰的密碼,或者是其中任何一個加上其他信息,例如您使用的加密算法。

攻擊者想猜測您的秘密。他們通過嘗試各種可能性來做到這一點,直到找到合適的可能性,或者他們用光了時間,金錢或動力為止。

您不知道他們正在嘗試什麼可能性。在您的問題中,您說“如果這些年來他一直使用錯誤的算法會怎樣?”唯一的答案是“如果不是,會怎樣?”您對此無能為力。如果您知道攻擊者將嘗試哪種可能性,則可以選擇他們名單上沒有的任何東西作為您的秘密,而安全性問題將被輕鬆解決。

您可以做的大概是根據計算技術的狀態,估計在耗盡時間和/或金錢之前他們可以嘗試多少種可能性。假設他們沒有秘密獲得世界上其他地方無法獲得的技術,例如量子計算或AES的後門-這可能是一個安全的假設,因為在這種情況下,他們要做的事比嘗試破解您的密碼。 (請參閱切掉Lex Luthor一張支票,儘管另請參閱此反駁。)

您還可以提供以下結果:如果您從 n 種可能性中隨機地(使用高質量的RNG)均勻地選擇您的秘密,並且攻擊者嘗試了 k 種可能性,無論它們是什麼,他們猜到您的秘密的機會最多為 k / n

最棒的是, n 隨您必須存儲/記住的信息量呈指數增長,而 k 僅隨其花費的時間/金錢成線性增長,因此製作 k並不難 / n 非常小。

因此,您應該從大量可能性中隨機選擇一致的秘密。從大小為2 256 sup>的集合中均勻選擇一個隨機的256位對稱密鑰,該密鑰(足夠大)。

您可以從一包(算法,密鑰)也可以配對,但這是沒有意義的,因為任何一種算法都已經提供了很多選擇。

您可以選擇一種晦澀的算法,並希望攻擊者不會嘗試使用它,但是那是不明智的不再需要隨機,因此您無法證明完全有幫助。如果沒有其他選擇,那總比沒有好,但是還有其他選擇。

這是密碼學家建議您僅將密鑰視為您的秘密的根本原因:有很多密鑰和鍵是最容易隨機選擇的東西。您什麼都不需要。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 4.0許可。
Loading...