Re: [cryptography] Email encryption for the wider public
On 17 September 2014 09:43, Henry Augustus Chamberlain henryaugustuschamberl...@gmail.com wrote: Using keys as addresses would remove the need for the user to understand public keys, encryption and digital signatures: everything would just work automatically - without compromising security in any way. I'm not sure I understand what problem you've just solved. Senders still need to generate a keypair and encrypt their mail, receivers still need to decrypt their mail. All you've done is remove key lookup and replaced it with a From: header. -- *Maarten Billemont* (lhunath) me: http://www.lhunath.com – business: http://www.lyndir.com – http://masterpasswordapp.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Hashing power of attackers
Is there any kind of recent estimation of what kind of hashing power we should expect identity thieves and other attackers to posses? Is there public research to demonstrate what kind of cost would be associated with, say, 10B, 50B, 100B SHA-256 hashes per second? Can we expect the cost for increasing the speed of hashing to increase linearly for all hashes? To get started, I found a few numbers on hashcat.net: Hash Type PC1 PC2 PC3 PC4 PC5 MD4 15445M c/s 4245M c/s 19868M c/s 5718M c/s 183232M c/s MD5 7893M c/s 2802M c/s 10436M c/s 3178M c/s 93800M c/s SHA12495M c/s 879M c/s3833M c/s 1103M c/s 29528M c/s SHA256 1036M c/s 337M c/s1413M c/s 406M c/s12328M c/s SHA512 179M c/s103M c/s383M c/s90M c/s 1952M c/s SHA-3(Keccak) 157M c/s91M c/s 277M c/s111M c/s2005M c/s The scrypt paper has a table with cost estimates: Table 1. Estimated cost of hardware to crack a password in 1 year. KDF 6 letters 8 letters 8 chars 10 chars40-char text 80-char text DES CRYPT$1 $1 $1 $1 $1 $1 MD5 $1 $1 $1$1.1k $1 $1.5 TMD5 CRYPT $1 $1$130$1.1M $1.4k $1.5 × 10^15 PBKDF2 (100 ms) $1 $1$18k$160M $200k $2.2 × 10^17 bcrypt (95 ms) $1$4 $130k $1.2B $1.5M $48B scrypt (64 ms) $1$150$4.8M $43B$52M $6 × 10^19 PBKDF2 (5.0 s) $1$29 $920k $8.3B $10M $11 × 10^18 bcrypt (3.0 s) $1$130$4.3M $39B$47M $1.5T scrypt (3.8 s) $900$610k $19B$175T $210B $2.3 × 10^23 How realistic are these numbers (and are the odd drops such as $175T - $210B typo's?), how modern are they and is there any other reliable research in this area? In particular, I'm interested in finding out about the different class of attackers and what kind of hashing power we might expect from them (script kiddy, criminal group with eg. a botnet, state / well funded organization). — Maarten Billemont (lhunath) — me: http://www.lhunath.com – business: http://www.lyndir.com – http://masterpasswordapp.com smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Internet Giants erect barriers to spy agencies
On Jun 7, 2014, at 8:08, John Young j...@pipeline.com wrote: No they haven't, Jim, you know that is a con from the 1990s. Same type of corporations pushing the deceptive scheme, matched by displeasure of the spies. I feel there’s an important implicit reference there I’m missing. What con in the 90s are you referring to? smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Master Password
On 30 May 2012, at 01:01, Maarten Billemont wrote: Dear readers, I've written an iOS / Mac application whose goal it is to produce passwords for any purpose. I was really hoping for the opportunity to receive some critical feedback or review of the algorithm used[1]. I'd like to thank everyone involved for their tremendously useful feedback. After considering the discussion both on this list and with external parties, an attempt to weigh the careful balance between security, usability, convenience and safety, I've completed a new release of Master Password which embodies the following changes since it was last evaluated: - Still using scrypt[1] to derive a key from the user's master password, however, I've introduced a name concept for its salt. The name has few constraints and is chosen by the user. This choice assumes that the user understands that their name is a key part of access to their passwords. I believe that in modern times, where users sign up for websites everywhere using a username - password combination, that we can safely expect this of most users. The name introduces a salt to the scrypt key derivation. The salt is not secure-random, so its entropy is understandably fairly low. I'm convinced, however, that this moderate entropy is sufficient to protect the user against a reasonable attempt at pre-calculating rainbow tables. - I'm prefixing user data with (1) a fixed identifier com.lyndir.masterpassword and (2) the length of the user data. The identifier (1) should help avoid cases where the algorithm might in the future be inadvertently re-implemented by another party, unexpectedly yielding the same results. The length (2) should help protect the algorithm if any of the functions in the future are found vulnerable to certain length-based side-effects. - I've normalized the algorithm by using HMAC-SHA256 instead of SHA1 hashing to determine the seed. There's been some discussion about this, and in the end I believe the original implementation was without known flaws. However, following certain recommendations I've decided the job is very befitting of a HMAC hash (given that we're hashing data using a key) and this should help avoid awkward questions from future peers. The algorithm now calculates the seed using hmac-sha256(key, 'com.lyndir.masterpassword' | length(site-name) | site-name | site-counter) The reason I've opted for SHA256 over SHA1 here (against certain recommendations) is that the function yields me a larger hash. This is important because: - I've increased the entropy of the Long Password type (1) and added a Maximum Security Password type (2). Assume that you've used Master Password to create a password for a certain website, the site stores a hash of your password but gets compromised and your hash becomes public. The idea of Master Password is to generate passwords for sites that are strong enough to give you at least a good chance at safety in this event. Naturally, it depends on the exact conditions under which the hosting site was compromised and whether or not they stored your site password in clear-text, as a result of a salted hash, or a simple hash function. Master Password can only do its best in this case to protect you, so assuming the site host had taken mild precautions and only a SHA1 or MD5 hash of your password got leaked and became public, it would be nice if Master Password's generated passwords were strong enough to make finding your site password from a leaked hash infeasible. Long Password (1) type passwords were before a 14-character sequence of numbers, upper-and-lowercase letters, and symbols. Assuming the attacker knows nothing more about the layout of your password, that would take him 1210537694726365245693116416 (86**14) attempts to try all combinations. Assume furthermore that our attacker is in the posesssion of a machine that can calculate 2 billion MD5/SHA1's per second (eg. 10 8800GT's). This blind attempt at brute-forcing a Long Master Password generated password would take them at most 19678164253 years. However, because of the template that Master Password uses to make Long Passwords readable to the user (usability), the true entropy of such passwords was in fact much less than 86**14. In fact, doing the math, I determined that it would take a mere 96486886125 permutations. With the same hardware at his disposal, an attacker that knows your password was generated by Master Password and is a Long Password type, he now needs less than 5 days to discover the password for your leaked hash. This has made me revise the template used to create the Long Password. It was important to me that passwords generated by Master Password were easy for a user to transfer manually using a keyboard. After all, the standard use case is generating a password on your iPhone (with a moderately secure keypad - at least in comparison to that of your desktop) and typing
Re: [cryptography] Master Password
On 30 May 2012, at 02:49, Jonathan Thornburg wrote: On Wed, 30 May 2012, Maarten Billemont wrote: Master Password is different in that it generates passwords based purely off of a user's master password and the name of the site. Is there a provision to rollover the master password [Useful to, e.g., regain security after ending a relationship in which the master password had been shared with a spouse/SO/lover/etc.] without requiring re-visiting every site where one has used a derived password based on that master password? ciao, No, the Master Password application makes it very explicit that the password is not to be shared with anyone. Passwords output by the algorithm for a specific site can optionally be shared, at the risk of needing to increment the password counter for the site when the user wishes to stop sharing their account. smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Master Password
First of all, thanks for your time and very valuable feedback. On 30 May 2012, at 07:20, Marsh Ray wrote: On 05/29/2012 06:01 PM, Maarten Billemont wrote: Dear readers, I've written an iOS / Mac application whose goal it is to produce passwords for any purpose. I was really hoping for the opportunity to receive some critical feedback or review of the algorithm used[1]. [1] http://masterpassword.lyndir.com/algorithm.html Master Password Master Password So how does it work? The theory behind Master Password is simple. The user remembers a single, secure password. The user only ever uses that password to log into the Master Password application. This master password is then used as a seed to generate a different password based on the name of How about just used to generate? Usually the term seed is used when it completely determines a pseudorandom sequence rather than being combined with other information. [edit: OIC, the master password generates a seed based on the name of the site. This was unclear.] the site to generate a password for. The result is that each master password generates its own unique sequence of passwords for any site name. Since the only input data is the master password and the site name (along with a password counter, see below), there is no need for any kind of storage to recreate a site's password. All that's needed is the correct master password and the correct algorithm implementation. How do you know how far along in the password sequence you are? The summary descriptions of the algorithm are simplified (perhaps, too much so) by assuming default values for those inputs that have ones. Technically, there are these inputs: - The master password, - The site name, - The password counter (default 0), - The password type (default Long Password). What that does for you is make it almost impossible to lose your passwords. To lose a password has multiple meanings. How about much easier to create and remember strong passwords? The intended meaning was, get in a situation where you can no longer obtain to the data necessary for accessing your passwords. Additionally, you can no longer get in a situation where this data can be lost to a third party, such as when someone steals your notebook full of passwords. It also makes it nearly impossible for hackers to steal your online identity. I don't think this claim is well substantiated. :-) The basis of this claim is the theory that attacking your password for a single site remains as vulnerable as password authentication has ever been, but this does not risk your global identity as reusing or rehashing the same password on multiple sites would. It's phrased awkwardly for an audience of professionals, but was targeted at users. This page may not be the right location for such language. The Algorithm In short, the algorithm is comprised of the following steps: Determining the master key Determining the cipher seed Encoding a user-friendly password The Master Password The user chooses a single master password, preferably sufficiently long to harden against brute-force attacks. Master Password recommends absurd two or three-word sentences as they're easily remembered and generally sufficiently high in entropy. I believe this is not good advice because two and three word sentences will not provide enough entropy. Wikipedia cites a Harvard/Google study indicating English has 1,022,000 words. https://en.wikipedia.org/wiki/Number_of_words_in_English#Number_of_words_in_English Users have great difficulty picking original passwords, even security pros tend to be overconfident in the uniqueness of password schemes. For example: http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf the 5000 most popular passwords [] are used by a share of 20% of the users. So even if users chose two completely independent passwords from the RockYou statistical distribution to form their sentence it would mean that more than 4% of users will use one of the top 25 million two password combinations. But that's when users are asked to pick unguessable passwords, asking for very short proper sentences is certain to make this worse. Many proper two word sentences in English are of the form noun-verb. But English has far more nouns than verbs. For example, https://en.wiktionary.org/ has 174871 entries for nouns and only 24931 under verbs. Adverb-verb sentences will be popular too, but there are only 12982 adverbs listed. In fact, a recent study tested two word minimum passphrases against an Amazon system which returned a different error depending on whether or not the passphrase was in use. They estimate that a dictionary of 20,656 phrases covers the choices of about 1.13% of users and concluded that by our metrics, even 5-word phrases would be highly insecure against offline attacks, with fewer than 30
Re: [cryptography] Master Password
Thanks a lot, Jon, for taking the time and sharing your thoughts. On 30 May 2012, at 09:32, Jon Callas wrote: Your algorithm is basically okay, but there are a couple of errors you've made, things you and I will disagree over, and one flaw that I consider to wreck the whole thing. But all of the problems are correctable, easily. If I have not understood something, or read it too quickly and gotten confused, I apologize in advance. Let me walk through a reduction of your system: (1) You take the master password and run it through a 512-bit hash function, producing master binary secret. You pick scrypt for your hash function, because you think burning time and space adds to security. I do not. This is a place where gentlepersons can disagree, and I really don't expect to convince you that SHA-512 or Skein would be better options. I'm convinced that I know why you're doing it, and it would be a waste of both our times to go further. We just disagree. At the end of it, it hardly matters because if an attacker wishes to construct a rainbow table, the correct way to do it is to assemble a list of likely passwords and just go from there. It will take longer if they use scrypt than with a real hash function, but once it's done it is done. They have the rainbow table. This isn't a flaw, it just is. The goal of your system requires that you have a master secret. But security-wise, there's no win here other than burning some cycles in a way that the attacker can trivially replicate. Security-wise, I'm quite certain that scrypt isn't nearly as secure as any real hash function you'd pick, but I'm just whining. We know that the security is password. If they pick puppies as their password, it really doesn't matter what hash function you run it through. Almost certainly, there is not enough security in their password to make it a difference what function you picked. If I understand your point correctly, you're telling me that while scrypt might delay brute-force attacks on a user's master password, it's not terribly useful a defense against someone building a rainbow table. Furthermore, you're of the opinion that the delay that scrypt introduces isn't very valuable and I should just simplify the solution with a hash function that's better trusted and more reliable. Tests on my local machine (a MacBook Pro) indicate that scrypt can generate 10 hashes per second with its current configuration while SHA-1 can generate about 1570733. This doesn't quite seem like a trivial delay, assuming rainbow tables are off the... table. Though I certainly wish to see and understand your point of view. Let's call the parameters P for password and M for the master key. (2) You take M and construct site-specific keys. We'll call the site name N, your counter C, and the site keys K_s. You compute a given site-specific key, K_s, with: K_s = SHA1(S + M + C), where + is the function that concatenates a null byte and then the second string. Strictly speaking, you really ought to do it in the order K + C + S, because that's more collision-resistant. It's good practice when computing a keyed hash to hash the key first. In reality, it probably doesn't matter, but it *does* save you lots of debates with people like me. Slight mix-up of parameters, but I think I can follow :-) You also want to hash in the length of S, too, because that's also more collision-resistent. So you really want it to be K_s = SHA1(M + C + S.length + S), but that's the only real security problems I can see. The ordering is a nit, and omitting the length is only a problem if the hash function is broken. Speaking of which, why not use a non-broken hash function, like SHA256, or SHA512 or SHA512/160, if the output size matters to you? Given that you're using scrypt, why not use a better hash function, even if it is slower? But that's also a nit. I changed the order so that the name of the site wouldn't be last, in order to avoid length extension issues. Adding in the length of the site name would curtail those issues as well, I expect, without needing to change the order. When you say SHA-1 is broken, are you referring to this property or something else? I was unaware of any other issues that SHA-1 suffers but the others do not. The real problem you have, however, is in the counter. First of all a counter is not a salt. A salt is an arbitrary non-security parameter. But arbitrary means random, just not secret. A counter is a counter. The counter has two problems to it. One is that it doesn't add to the security of the system. The other it makes system utterly useless. An attacker can easily brute force through the site keys by just running a counter. That's why I say it doesn't add to the security. Even if you used scrypt here, too, it wouldn't matter much. It's still easy to brute force. However, this completely ruins the
Re: [cryptography] Master Password
On 30 May 2012, at 15:09, Jonathan Thornburg wrote: You're right, sharing of master passwords is a bad idea. But given human nature, it happens, and a security system needs to take that into account. There are also a lot of other ways a master password can be compromised and thus need rolling over, e.g. shoulder-surfing, virus keyloggers, theft of PC where web browser remembered it, etc. So... it would be a *big* plus to have a way to rollover the master password without having to manually re-visit and re-password each website. If somebody gets a hold of your master password, they now have the ability to generate any password on demand. There is only one fix: Change all the passwords that the attacker can now generate. Whatever trickery you aim to do with your master password, all site passwords must be changed, either way. Since Master Password is a solution that hooks into the password authentication mechanism of arbitrary sites and it works completely offline, there is no way for it to communicate with sites on your behalf or invalidate your passwords somehow. What you're pointing out is a flaw of the decentralized password authentication mechanism, and the only fix is to stop using decentralized password authentication. It's not a terribly big deal, IMO, but if you are indeed worried about loosing your master password, you need to either start using something like OpenID exclusively or use a password solution that doesn't work statelessly and then hope you won't also loose that state to the attacker along with your master password (seems unlikely that you can protect yourself from this). A very valid point, however, is key logging. To thwart that, Master Password users could use only the iOS application, which displays their password, and copy it manually to their desktop. That would void the need to enter the master password on the desktop which may potentially be compromised. Don't get me wrong; your iPhone can also get compromised, but it's significantly less likely to happen. It's probably the most secure keypad you have around, not to mention it's much easier to keep nosey sholder-surfers away from a tiny screen you hold in your hand than a large keyboard in a fixed position on your desk. smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Master Password
On 30 May 2012, at 16:26, Wyss, Felix wrote: What about including a random salt when generating the key from the master password? The application could either generate the salt for you on first use (and recommend writing it down and keeping in a safe place) or allow entering an existing salt (e.g. when transferring to a new device). That would make password guessing practically infeasible and two users sharing the same master password won't inadvertently break the system. You're proposing adding a second secret to the mix. While interesting in the sense that it guards against both loss of a master password and rainbow tables, I'd rather avoid introducing any factors that can easily become lost to the user. I imagine introducing a username to the scheme as a salt, as proposed by Jon Callas, would create sufficient protection against rainbow tables. smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Master Password
I'm going to attempt to summarize/rehash the comments I've found have a significant relevance to the quality of the algorithm. I've had a lot of great feedback, which I'm tremendously thankful for. My apologies in advance for any important aspects that any of you have highlighted if I forget to include them here. [1] There's no way to recover or change the master password without forcing the user to set new passwords for each of their sites. [2] It's difficult for a user to come up with a master password that's high in entropy. [3] Master passwords with weak entropy put the user at a significant risk of having all their passwords stolen. [4] The algorithm can do with some tweaking and cleaning up. (eg. no overly high scrypt output key size, employ HMAC over SHA1, remove scrypt in favor of alternative hashing functions, ...) [5] The terminology in the algorithm's documentation can be improved. [6] There are quite a few input values that the user is expected to remember in order to reproduce his passwords on another clean device. [7] The master password can be determined relatively easily using a rainbow table built for the given scrypt parameter values and either a hash of the master key or all of the site name + site password counter + site password type + site output password. [8] The modulo operator introduces a bias when used to choose an element from a range. [9] The cipher currently employed to construct an output password yields a password whose entropy is significantly below the ideal. Proposals to address these issues: [1] Instead of creating a hash of the master password, create a salt value on the device using a pseudo-number generator. Use that salt to computer the master key. This allows changing the Master Password, and protects against rainbow tables, but turns Master Password into a stateful solution. [2] I currently propose sentences. This may yet be insufficient. [3] Known issue. The master password must be decent. [4] Parameter values can be optimized such as scrypt parameters, ciphers, etc. We can also change things like use proven HMAC over SHA-1 where relevant. [5] The vocabulary must be fixed or amended. [6] Most of the current input values have good defaults which will not generally be changed by users. For those that users to change, the user can fairly easily recover from forgetting the parameter value by means of some trail-and-error. [7] A salt must be added when scrypt is used or afterwards, when the master key is used. This salt should be high enough in entropy that it makes it infeasible to construct a rainbow table for each salt value. [8] Consider replacing the modulo operator or fixing its bias. [9] Perhaps the cipher can be improved upon. Additional cipher candidates might help. Ideally, the solution does not sacrifice usability. If I've missed any issues, highlight them for me. I believe the algorithm can be fixed by introducing a salt, ideally one that's memorable to the user, and its initial goal preserved. Presumably, it will never be quite as secure as using the output of dd (| base64) as a password. smime.p7s Description: S/MIME cryptographic signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
