Questions tagged «cryptography»

密码学必须进行编程。密码学尤其涵盖加密,散列和数字签名。与crypto.stackexchange.com更好地询问与软件开发不直接相关的密码学问题。

14
为什么素数在密码学中很重要?
作为非密码学家,我总是感到一件事:使用素数为什么如此重要?是什么使它们在密码学上如此特别? 有人有简单的简短解释吗?(我知道有很多入门书籍,而《应用密码学》是圣经,但正如我所说:我不是要实现自己的密码算法,而我发现的东西却使我的大脑爆炸了-没有10页的数学公式请 :)) 感谢您提供所有答案。我已经接受了使我最清楚实际概念的那个。

8
给密码加盐:最佳做法?
我一直很好奇...给哈希密码加盐时,哪种更好:前缀还是后缀?为什么?还是重要,只要你加盐? 解释一下:到现在,我们所有人(希望如此)都知道在对密码进行哈希处理以存储到数据库之前,应该先对密码加盐 [ 编辑:这样就可以避免Jeff Atwood最近发生的事情 ]。通常,这是通过在盐经过哈希算法之前将盐与密码连接起来来完成的。但是示例各不相同...一些示例在密码前加盐。一些示例在密码后添加盐。我什至看到一些尝试将盐撒在中间的方法。 那么哪种方法更好,为什么呢?有没有一种方法可以减少哈希冲突的机会?我的Google搜索功能尚未对此问题进行过体面的分析。 编辑:乡亲们很好的答案!对不起,我只能选择一个答案。:)

7
SHA-1是否安全存储密码?
结论: SHA-1与任何其他对原像攻击的攻击一样安全,但是它易于计算,这意味着更容易进行暴力破解或字典攻击。(对于SHA-256之类的后继者也是如此。)根据情况的不同,散列函数的设计成本较高(例如bcrypt),可能是更好的选择。 有些人大声疾呼诸如“ SHA-1损坏”之类的言论,所以我试图理解这到底意味着什么。假设我有一个SHA-1密码哈希数据库,并且攻击者拥有最先进的SHA-1破坏算法,并且拥有100,000台机器的僵尸网络可以访问它。(对10万台家用计算机进行控制将意味着它们每秒可以执行约10 ^ 15次操作。)他们需要多少时间 找出任何一个用户的密码? 找出给定用户的密码? 找出所有用户的密码? 找到一种以用户身份登录的方法? 找到一种以特定用户身份登录的方法? 如果密码过大,该如何更改?加盐的方法(前缀,后缀或两者,或诸如xor-ing之类的更复杂的东西)是否重要? 经过谷歌搜索后,这是我目前的理解。如果我误解了一些内容,请纠正答案。 如果没有盐,彩虹攻击将立即找到所有密码(极长的密码除外)。 如果有足够长的随机盐,找出密码的最有效方法是蛮力攻击或字典攻击。碰撞和前映像攻击都无法帮助您找到实际的密码,因此,针对SHA-1的加密攻击没有帮助。甚至使用什么算法都没关系-甚至可以使用MD5或MD4,并且密码也一样安全(因为计算SHA-1散列的速度较慢,所以存在细微差别)。 为了评估“同样安全”的安全性,我们假设一次sha1运行需要1000次操作,并且密码包含大写,小写和数字(即60个字符)。这意味着攻击者每天可以测试10 15 * 60 * 60 * 24/1000〜= 10 17个潜在密码。对于蛮力攻击,这意味着要在3小时内测试所有密码,最多9个字符,一周最多测试10个字符,一年最多测试11个字符。(每个其他字符要花60倍的时间。)字典攻击的速度要快得多(即使攻击者只有一台计算机,也可以在数小时内将其删除),但只能找到弱密码。 要以用户身份登录,攻击者无需找出确切的密码;找到一个导致相同哈希值的字符串就足够了。这称为第一次原像攻击。据我所知,没有针对SHA-1的原像攻击。(A暴力破解攻击需要2点160的操作,这意味着我们的理论,攻击者需要10 30年,把它关闭。的理论可能性的限制是大约2个60操作,在该攻击将需要几年的时间。)有原像攻击反对SHA-1的简化版本(效果可忽略不计)(对于使用44步而不是80步的简化SHA-1,攻击时间从2160次操作减少到2157次)。有一些针对SHA-1的冲突攻击,这在理论上是可行的(我发现的最好的攻击时间从2 80降至2 52),但是对于密码哈希(即使不加盐)也没有用。 简而言之,使用SHA-1存储密码似乎非常安全。我错过了什么? 更新: Marcelo指出了一篇文章,其中提到了2 106次操作中的第二次原像攻击。(编辑:正如Thomas所解释的那样,此攻击是一种假想的构造,不适用于现实情况。)不过,我仍然看不到这对使用SHA-1作为关键派生函数的危险。通常有充分的理由认为碰撞攻击或第二原像攻击最终可以转变为第一原像攻击吗?
148 cryptography  hash  sha1 

9
为什么XOR是组合哈希的默认方法?
假设您有两个哈希H(A),H(B)并且想要将它们组合在一起。我读过,将两个散列组合在一起的一种好方法是XOR,例如XOR( H(A), H(B) )。 这些哈希函数准则在此简要地介绍了我找到的最佳解释: 对具有大致随机分布的两个数字进行异或运算会导致另一个仍具有大致随机分布*的数字,但是现在取决于这两个值。 ... *在要组合的两个数字的每一位,如果两位相等,则输出0,否则为1。换句话说,在50%的组合中,将输出1。因此,如果两个输入位各自有大约50-50的可能性为0或1,那么输出位也是如此。 您能解释为什么XOR应该是用于组合哈希函数(而不是OR或AND等)的默认操作的直觉和/或数学方法吗?

21
为什么SSL握手会产生“无法生成DH密钥对”异常?
当我与某些IRC服务器(而非其他IRC服务器)建立SSL连接时(大概是由于服务器的首选加密方法),出现以下异常: Caused by: java.lang.RuntimeException: Could not generate DH keypair at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:106) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:556) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:183) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165) ... 3 more 最终原因: Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive) at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..) …

9
我应该选择哪个加密哈希函数?
.NET框架附带6种不同的哈希算法: MD5:16个字节(散列时间500MB:1462毫秒) SHA-1:20个字节(1644毫秒) SHA256:32个字节(5618毫秒) SHA3​​84:48个字节(3839毫秒) SHA512:64个字节(3820毫秒) RIPEMD:20个字节(7066 ms) 这些功能各自执行不同的功能。MD5是最快的,而RIPEMD是最慢的。 MD5的优点是适合内置的Guid类型。它是类型3 UUID的基础。SHA-1哈希是类型5 UUID的基础。这使得它们真正易于识别。 但是,MD5容易受到碰撞攻击,SHA-1也容易受到攻击,但程度较小。 在什么情况下应该使用哪种哈希算法? 我真的很想知道答案的具体问题是: MD5不值得信赖吗?在正常情况下,当您使用没有恶意意图的MD5算法并且任何第三方都没有恶意意图时,您会期望发生任何冲突(这意味着两个任意byte []会产生相同的哈希) RIPEMD比SHA1好多少?(如果更好),其计算速度要慢5倍,但哈希大小与SHA1相同。 在对文件名(或其他短字符串)进行哈希处理时,获得非恶意冲突的几率是多少?(例如,两个具有相同MD5哈希值的随机文件名)(带有MD5 / SHA1 / SHA2xx)通常,非恶意冲突的几率是多少? 这是我使用的基准: static void TimeAction(string description, int iterations, Action func) { var watch = new Stopwatch(); watch.Start(); for (int i = 0; i < iterations; i++) { func(); …


10
在配置文件中加密密码?[关闭]
关闭。此问题不符合堆栈溢出准则。它当前不接受答案。 想改善这个问题吗?更新问题,使其成为Stack Overflow 的主题。 2年前关闭。 改善这个问题 我有一个程序可以从配置文件中读取服务器信息,并希望在该配置中加密密码,该密码可以由我的程序读取并解密。 要求: 加密要存储在文件中的纯文本密码 解密从我的程序从文件读取的加密密码 关于我将如何做到这一点的任何建议?我当时在考虑编写自己的算法,但我认为这绝对是不安全的。

15
填充无效,无法删除?
我已经在网上查找了此异常对我的程序的含义,但似乎找不到解决方案或它在我的特定程序中发生的原因。我一直在使用我的msdn使用Rijndael算法对XmlDocument进行加密和解密的示例。加密工作正常,但是当我尝试解密时,出现以下异常: 填充无效,无法删除 谁能告诉我该如何解决这个问题?下面的代码是我获取密钥和其他数据的地方。如果cryptoMode为false,它将调用解密方法,这是发生异常的地方: public void Cryptography(XmlDocument doc, bool cryptographyMode) { RijndaelManaged key = null; try { // Create a new Rijndael key. key = new RijndaelManaged(); const string passwordBytes = "Password1234"; //password here byte[] saltBytes = Encoding.UTF8.GetBytes("SaltBytes"); Rfc2898DeriveBytes p = new Rfc2898DeriveBytes(passwordBytes, saltBytes); // sizes are devided by 8 because …
124 c#  cryptography 

10
在C#中使用AES加密
已锁定。该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。它当前不接受新的答案或互动。 我似乎找不到使用AES 128位加密的漂亮示例。 有人有示例代码吗?


4
给定最终块未正确填充
我正在尝试实现基于密码的加密算法,但出现此异常: javax.crypto.BadPaddingException:给定的最终块未正确填充 可能是什么问题? 这是我的代码: public class PasswordCrypter { private Key key; public PasswordCrypter(String password) { try{ KeyGenerator generator; generator = KeyGenerator.getInstance("DES"); SecureRandom sec = new SecureRandom(password.getBytes()); generator.init(sec); key = generator.generateKey(); } catch (Exception e) { e.printStackTrace(); } } public byte[] encrypt(byte[] array) throws CrypterException { try{ Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding"); …

6
如何在php中加密/解密数据?
我目前是一名学生,并且正在学习PHP,我正在尝试对PHP中的数据进行简单的加密/解密。我进行了一些在线研究,其中一些非常令人困惑(至少对我而言)。 这是我想要做的: 我有一个包含这些字段(用户ID,Fname,Lname,Email,Password)的表 我想拥有的是先加密所有字段,然后再解密(sha256如果没有任何加密算法,是否可以用于加密/解密) 我想学习的另一件事是如何创建一种hash(sha256)与优质“盐”结合的单一方法。(hash(sha256)+salt) 先生/女士,我基本上只是想对加密/解密进行简单的实现,您的回答会很有帮助,非常感谢。谢谢++

8
我的SSL证书应使用什么RSA密钥长度?
我正在创建CSR,我想知道这可以说是RSA密钥的最佳长度。 当然,384可能太弱了,而16384可能太慢了。 根据证书的有效期,是否应该就密钥长度达成共识? 编辑:与大多数人一样,我希望我的钥匙相当坚固。我并不担心NSA可能会在2019年打破我的钥匙。我只想知道一个计划开展正常业务(例如电子商务网站)的最佳做法是什么


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.