Re: [cryptography] Should Sha-1 be phased out?
On 14 Oct 2015 13:39 -0400, from kevinsisco61...@gmail.com (Kevin): > http://www.networkworld.com/article/2990801/sha-1-hashing-algorithm-could-succumb-to-75k-attack-researchers-say.html To answer the question in the subject line: SHA-1 is already being phased out, particularly in areas where collision resistance matters. Just like MD5, there are still situations in which SHA-1 provides a fully adequate level of security even _if_ finding collisions was actually easy, and there are mitigative strategies that can be used to make finding useful collisions much harder (such as using multiple hash algorithms in tandem, or iterative hashing). A major use for even a cryptographic hash algorithm where collisions can be found reasonably easily is as a compression function for password hashing. With the above said, new designs that need collision resistance should obviously use more secure hash algorithms, and even more than that, should probably plan ahead for when _those_ algorithms reach the end of their useful life and allow for a migration strategy. SSL/TLS certificates allow for a migration strategy, which is why the fact that we no longer trust previously MD5 and now SHA-1 doesn't immediately break everything. For SHA-1 sunsetting, see for example [1], [2], both of which are over a year old. SHA-1 is on schedule to be sunset for TLS certificates at the end of 2016; the major browsers don't consider SHA-1 based certificates which are valid after 1 Jan 2017 to be trustworthy, which with the one-year commonly selected validity period of CA-signed certificates means we are only a few months away from starting to see this in practice. It's possible that this schedule is overly optimistic in light of recent events, but even so, that's moving SHA-1 from basically ubiquitous to actually untrusted in two and a half years, which is already quite fast. It would seem likely to me that accelerating the sunset of SHA-1 at this point would cause massive disruption, considering that people probably are making plans based on the announced dates. [1]: https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ [2]: https://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Unbreakable crypto?
On 21 Mar 2015 21:17 -0700, from sch...@eff.org (Seth David Schoen): *True random pad*: Attacker doesn't know whether pad k₁ is actually more likely than pad k₂, if (c ⊕ k₁) and (c ⊕ k₂) both appear to be equally plausible plaintexts. *Choosing a meaningful file but keeping secret which one you used*: An attacker who tries your file f₁ as the pad notices that both (c ⊕ f₁) and f₁ itself appear meaningful, so it's more likely that f₁ is correct compared to some other f₂ which is not meaningful. This also goes hand in hand with the difference between a true OTP and a stream cipher secured by a key of length less than the length of the message to be encrypted. In that sense, which file was used as the pad? corresponds to what was the encryption key fed into the cipher?. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Unbreakable crypto?
On 22 Mar 2015 09:36 -0500, from jeff...@goldmark.org (Jeffrey Goldberg): There are good crypto systems in use which generate pseudo-random pads from keys that are 128 (or 256) bits in length. But these are – at best – no better than the length of their keys. Which is, admittedly, _quite good enough_ for almost any _practical_ purpose that an individual is likely to face. Nobody (to within experimental error) is going to successfully brute force your truly-random AES-256 key that was used to protect the 10 MiB archive containing your Evil Overlord Plans for World Domination. But it's a _lot_ easier to keep secret a 32-byte key than a 10 MiB pad, and it is a lot easier to generate 256 truly-random bits than ~80 _million_ truly-random bits. If they want access to the data, they are going to do it differently. Compare https://xkcd.com/538/ -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Unbreakable crypto?
On 22 Mar 2015 10:50 -0400, from givo...@gmx.com (Givon Zirkind): I was tempted by the promise of software to run a one-time pad on my machine. I am a fool and I fall upon my own sword. An unauthenticated one-time pad is trivial to implement; it's literally a few lines of code in any reasonably modern language, and a handful of lines of code in less modern ones. The hard part, as has been pointed out in this thread, is to generate and handle the _pad_. imho, this is not as difficult as you say. using a time-date stamp as part of your seed. Any pseudo-random number generator is going to, _at best_, be exactly as secure as the entropy of the seed. And the entropy of a date/time-stamp in most contexts is _incredibly_ low; I would expect a few tens of bits at the very most even with a high-precision timestamp. Remember that a timestamp of one second accuracy between about 1902 and 2038 can be expressed as a single 32-bit integer value, so for any semi-reasonable range, we'd be looking at an entropy of 30 bits or less. For something like message was sent between 2011-01-01 and 2017-12-31 (seven full years' range) and one-second precision that's approximately log(7×365×86400)/log(2) ≅ 27.7 bits of entropy, assuming no other knowledge on part of the attacker. The point I made Friday still stands: # It doesn't matter how the PRNG works. If it's seeded by a key, and # the pad is regenerable given the key (which it sounds like given the # description), then it's not an OTP, and you get _at the very best_ # 2^k bits security (where k is the number of entropy bits in the key) # rather than a proper OTP's 2^n bits security (where n is the length # of the message, in bits). There is a time and a place for a seedable CSPRNG together with an operation to combine the CSPRNG output with the ciphertext or plaintext. That construct is called a _stream cipher_; it is _not_ called a one-time pad. the real difficulty is in the length of the key. rounding other calculations errors will quickly interfere. but, for up to 500 characters, the length of the avg email, imho, you can produce a non-reusable pad 1. Do you have any data to suggest that the average length of an email, even if we play nice by excluding headers and quoted material, is 500 characters or less? My experience points toward it being significantly higher. 2. How do you propose to get the pad to the recipient? 3. How do you propose the recipient should securely store the pad until it is used? 4. How do you guarantee that no part of the pad is ever reused for a different message? -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Unbreakable crypto?
On 20 Mar 2015 15:11 -0400, from kevinsisco61...@gmail.com (Kevin): I was tempted by the promise of software to run a one-time pad on my machine. I am a fool and I fall upon my own sword. An unauthenticated one-time pad is trivial to implement; it's literally a few lines of code in any reasonably modern language, and a handful of lines of code in less modern ones. The hard part, as has been pointed out in this thread, is to generate and handle the _pad_. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Unbreakable crypto?
On 19 Mar 2015 16:10 -0400, from kevinsisco61...@gmail.com (Kevin): On 3/19/2015 4:00 PM, Ben Lincoln (F70C92E3 - Cryptography ML) wrote: There's no demo version available, but based on the screenshots and the information on the site, it looks like it's using a one-time pad generated using a PRNG or other sequence-generator seeded with a key generated by the application, and it's the key that's exchanged. I assume it uses your hardware to generate the random value. It doesn't matter how the PRNG works. If it's seeded by a key, and the pad is regenerable given the key (which it sounds like given the description), then it's not an OTP, and you get _at the very best_ 2^k bits security (where k is the number of entropy bits in the key) rather than a proper OTP's 2^n bits security (where n is the length of the message, in bits). The reason why a OTP is provably secure in theory (in the confidentiality sense of secure) is that the key _is_ as long as the message and completely random; thus you cannot tell whether a key you just tried is valid without already knowing the plaintext message, in which case there really is no point to the exercise to begin with. Combining a seeded PRNG with a simple operation on the PRNG output and the plaintext or ciphertext is how stream ciphers work. Now, something like a decent KDF feeding a key into AES running in counter mode to generate a ciphertext stream which is then used as a key for encryption in a stream cipher-like construct is _probably reasonably_ (_very heavy_ emphasis on probably) secure, and not too dissimilar from what is hypothesized above. But at that point, you might just as well use the fairly well-proven AES directly; it will be marginally faster given identical hardware and otherwise identical software (since you avoid your extra algorithm, and AES is often hardware-accellerated on modern CPUs) and it will be at least equally secure (because the security of the ciphertext in the combined scheme will be totally dependent on the security of the stronger algorithm pass anyway -- see Kerckhoffs' principle -- and most people are unlikely to come up with something that is _more_ secure than AES against any type of attack, much less all types of attacks). And it absolutely is _not_ a one-time pad. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE
On 7 Jan 2015 16:57 -1000, from yoz...@gmail.com (Open eSignForms): But if you are not a high value target, your crypto may provide adequate security as there's unlikely a cabal who will invest the resources to attempt to crack it. Life is short and freedom to explore is your right! You mean like how the NSA is alleged to store _all_ encountered cryptotext _indefinitely_, _just in case_ they are able to decrypt it later? The specific value of a target is relative as well as bound to change over time, possibly abruptly. If someone wants to target you, they will; it does not matter whether _you_ believe you are worthy of being targetted. Consider _for example_ [1], [2], [3], [4]. The way a bottle of snake oil helps against snakes is that you hit the snake very hard over the head with the bottle. That does not mean that snake oil is an effective way to get rid of snakes. [1] https://firstlook.org/theintercept/2014/02/24/jtrig-manipulation/ [2] https://firstlook.org/theintercept/2014/03/12/nsa-plans-infect-millions-computers-malware/ [3] https://firstlook.org/theintercept/2014/05/19/data-pirates-caribbean-nsa-recording-every-cell-phone-call-bahamas/ [4] https://firstlook.org/theintercept/2014/07/14/manipulating-online-polls-ways-british-spies-seek-control-internet/ -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 7 Jan 2015 15:55 -0500, from kevinsisco61...@gmail.com (Kevin): Code: ;QODE(Quick Offline Data Encryption) ;by ;Kevin J. Sisco(kevinsisco61...@gmail.com ;provides strong encryption for data entered ;written in Autoit $i = Inputbox( , Enter data) $b = StringToBinary($i) ;convert to binary $s = StringToBinary(the data is now secure) ;salt $salt = $b+$s ;add salt to input A salt isn't a part of the encryption algorithm, though it's often a part of a sane cryptosystem implementation. Take a look at for example RC4; it's been broken, but it's a _dead simple_ example of an encryption algorithm that for a long time stood the test of the community. (And it was designed by a well-known and well-renowned individual in the field of cryptography, who knows and knew the craft. Ever heard of RSA? One of those guys.) $l = BinaryLen($b) ;length in bytes $br = BitRotate($b, $l) ;left bit rotation So this is basically a Caesar cipher with the rotation amount equal to the plaintext length? If we assume for a second that the rotation is per-byte, that will be modulo eight anyway. I can try those eight combinations by hand if necessary; it'd probably be quicker than writing up a program to do it for me. Even if the rotation is bitwise over the entire plaintext input, the value is bounded by 8 * L, where L is the length in bytes of the plaintext input. For a full DVD (a little over 4 GiB), that value is about 32 billion, corresponding to right around 32 bits of key. Anything less than 128 bits of key is considered short, and 80 bits of key is considered breakable with some reasonable amount of effort by a determined attacker. Keep in mind that every single bit added to the key _doubles_ the attacker's effort, assuming a brute force mode of attack. $x = BitXor($br, $l) ;xor of rotation and length $y = @YEAR ;current year $r = Random(20, 50) ;random number $formula = $salt+$br+$x+$y+10+32+$r*100 ;formula Wait, _what!?!_ Back up a few lines above, you assigned $salt to _include a representation of the plaintext input!_ $t = $formula*$formula*$formula*Log($formula) ;total So, for some transformation f(x) on the plaintext (your $formula assignment), _the output of which includes x_, we have that the algorithm is f(x)^3 * log(f(x)). I'm not really up to looking at the math of that right now, and the intricacies will depend on exactly what Log() in your language is, but I'm willing to bet that there is a trivial transformation of that right back to _x_, at which point we essentially have the original plaintext input. There should _certainly_ be a trivial transformation back to $formula, which is essentially the same thing. There isn't even a key in there that I can see, only a salt (which is included in clear in the output once you allow for the Log()). $o = FileOpen(output.txt, 1) ;create output file FileWriteLine($o, $formula) ;store the result Doesn't this mean that in your implementation, since $formula includes $salt which includes $b which is a representation of $i (the original plaintext input), the output file will contain a copy of that representation of the input? Presumably, StringToBinary() is trivially reversible. FileFlush($o) ;flush buffer to disk FileClose($o) ;close the stream The above took me all of a few minutes to look over and write up (mostly slowed down by your rather odd code formatting, causing me to have to look back and forth several times). And _I am definitely not an expert in the field_ and _have never used the language you wrote it in_. I'm just a mostly random guy who happens to do _programming_ for a living and have an _interest_ in cryptography. If we may assume that writing $formula to the output file is a simple bug, and you meant to write $t instead (a very embarassing bug indeed, but one that does not affect the _cryptography_), then is the entire security of your algorithm in what you call the salt? Is it even in the _length_ of what you call the salt? If so, you should start out with some basic terminology: _salts are meant to be public_ and are generally used so that _two plaintexts *hash* to different outputs_ in order to thwart dictionary or rainbow table attacks on hash values. They are, roughly, the _hash_ equivalent of an initialization vector. Here is an exercise for you. Assume that an adversary has access to the full and complete details of your algorithm. Also assume that the same adversary can run as many encryption attempts as they want to, on any plaintext input they choose to. Assume that they have access to the _particular_ implementation that the entity attempting to secure communications uses, as well as a copy of the ciphertext of the communication. Under these circumstances, _what_ property of your algorithm provides guarantees of _confidentiality_ against reasonable effort on the part of the attacker? -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https
Re: [cryptography] QODE(quick offline data encryption)
On 7 Jan 2015 22:11 +, from mich...@kjorling.se (Michael Kjörling): Even if the rotation is bitwise over the entire plaintext input, the value is bounded by 8 * L, where L is the length in bytes of the plaintext input. For a full DVD (a little over 4 GiB), that value is about 32 billion, corresponding to right around 32 bits of key. Apologies for the noise, people; of course, 32e9 corresponds to about 35 bits of key. (log(32e9)/log(2) ~ 34.9) Stupid mistake of mine that I really should have caught in proofreading. Doesn't change the big picture, though; for these purposes, 32 = 35. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 6 Jan 2015 16:12 -0500, from kevinsisco61...@gmail.com (Kevin): I figured I'd start building my own open source encryption algorithm: https://github.com/kjsisco/qode To borrow a very apt quote from Bruce Schneier: Who the hell are you? [1] [2] Nobody is perfect. Even very clever people make mistakes when designing encryption algorithms. Sometimes they are unaware of particular attacks which turned the believed-secure algorithm into a trivially breakable entropy-reducing mess. Other times cryptographic advancements make previously infeasibly breakable algorithms feasibly breakable. Yet other times pure computing power did. Sometimes those same smart people come up which believed secure schemes that are trivially breakable by anyone with the right knowledge. [3] Which leads us back to the question: who are you? What are your credentials in the field of cryptography? Why should we trust _your_ algorithm over something designed by people with an established track record in the field? And also, _what problems_ do you see with current algorithms which you are attempting to solve, and _how_ do you intend to solve those problems? This is not meant to be sarcastic at all. Homegrown algorithms tend to fall very quickly to even a modicum of competent analysis. If you want the community to take your algorithm proposal (whatever it might be) seriously, then you need to show why the community should take it seriously. I once believed I had come up with a great encryption algorithm. Thankfully, it never saw any use beyond a few toy programs which I never distributed to anyone else. [1] https://www.schneier.com/crypto-gram-0608.html#7 [2] https://www.schneier.com/blog/archives/2011/04/schneiers_law.html [3] http://ftp.pgpi.org/pub/pgp/2.x/doc/pgpdoc1.txt section Beware of Snake Oil -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA Attacks on VPN, SSL, TLS, SSH, Tor
On 28 Dec 2014 15:24 -0800, from rya...@gmail.com (Ryan Carboni): On Sun, Dec 28, 2014 at 3:14 PM, John Young j...@pipeline.com wrote: We offer a RAR of the 44 docs: http://cryptome.org/2014/12/nsa-spiegel-14-1228.rar (197MB) my browser says it's 188 MB... am I being man in the middled? Some quick math says 188 × 2^20 ~ 197 × 10^6. Let's have a hash and I think we can boil this one down to decimal versus binary prefixes. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] new encrypted phones
On 20 Nov 2014 06:08 -0500, from givo...@gmx.com (Givon Zirkind): does the encryption extend to call logs? If you're looking for call logs, don't go after the data on the phone, which may or may not be complete and which may or may not have been tampered with. Just issue a subpoena to the phone company and move on with your life. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Weak random data XOR good enough random data = better random data?
On 28 Jul 2014 18:23 +0200, from l...@odewijk.nl (Lodewijk andré de la porte): If I XOR probably random data with good enough random data, does that result in at least good enough random data? If you are truly concerned, have you considered implementing a proper CSPRNG yourself in Javascript (or using someone else's implementation of the same; I'm sure they are out there) and seeding that PRNG with randomness from both sides of the communications channel? It'd be a bit less obvious to the casual code viewer what's going on, but you would seem to have a much better shot of guaranteeing a particular level of randomness provided to whatever uses the PRNG. -- Michael Kjörling • http://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 http://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
