I'm not stalking you, you pathetic drama queen. I'm temporarily providing a service to the community to make sure you don't spread any more (unchallenged) self-indulgent authoritarian gibberish for a little while. Also, there may be some jokes at your expense if you happen set me up with a good line. Things have been slow lately but I've some upcoming stuff that will require my keenest attention and after that point I'm pretty sure keeping an eye on you will fall far down into the darkest depths of the extended to-do list, never to be seen again.
Jesus Christ, somebody certainly has a big ego.
Do you want me to stalk you? I'm going to have to see a picture before I make that kind of commitment. Or at least some measurements.
Possibly, though I think the better explanation might have to do with Hillary's self-identification as a feminist.Just read any post regarding feminism and see all the people railing against "SJWs". I think gender is still very relevant for a lot of people.
I'm sure plenty of sexists use anti-SJW criticism as cover, but this is some damn twisted logic you've got going on there.
The person who brings up gender by:
* Explicitly calling herself a feminist (as you yourself just mentioned)
* Campaigning for feminist causes
* Having her people engage in those "Bernie Bros" attack
* Treating every single negative thing Trump has ever said about specific women as evidence that he believes they are an inferior sex
is demonstrating that gender is, in fact, "relevant" to her.
The people who are reacting to it... are the ones reacting to it. Some rightly, some wrongly.
*sigh*. 4chan is what started and popularized that meme. Don't mod down a joke just because you don't get it. (and don't mod this up informative, either.)
If there does turn out to be a small link, I'll be shocked if the risk is going to be too minuscule to obsess over. People only care about cell phones causing cancer because invisible EM / radio waves are freaky. It's weird magical stuff flying through the air that I can't see or hear or smell --> We need to be paranoid about it. That is the basis of the concern over non-ionizing EM causing cancer. Here are a list of things that we're almost certain cause cancer:
* Barbecued food with any black "grill marks" or other carbonization on it.
* Smoked foods
* Regularly being around lit candles
* Being around a lit fireplace, even if it's just occasionally.
* Drinking your coffee (or any other drink/food) while it's too hot.
* The sun--anything over the minimum amount required for your body to manufacture the vitamin D you need (just a few minutes per day, at least for lower-melanin people in lower latitudes).
* Possibly anything that causes prolonged or repeated inflammation.
I'm not saying you shouldn't worry about your kids or err on the side of caution, but if you aren't at all concerned about everything on the above list... don't kid yourself. You're not a safe, informed conscientious parent. You're simply unduly afraid of what you don't understand.
The problem is that you have no clue about the topic
The problem is you don't understand the concept of "in principle" or perhaps even causation in general.
Mike bought three shirts last week. The first one was $900. The second one was $1700. The third one was $1300.
This is your logic at work: If Mike lost all his money and then had a house fire and lost all his clothes and other possessions, he shouldn't ever buy another shirt again, even though all of his clothes have been burned up, because he can't afford it. Because the data clearly shows that Mike only buys expensive shirts. He should walk around shirtless, for the rest of his life, because it wouldn't make sense for a poor person to spend so much money on a shirt.
This fully encapsulates your current argument. I've already agreed that past and existing nuclear power plants generate too much waste, fully agree! (Although I don't view the waste as being quite as dangerous as some people seem to think it is.) That is not the same thing as saying nuclear power inherently creates a lot of waste.
Actual experts can succinctly explain why they consider something to be massively flawed.
And I'm not going to take etiquette advice from someone who uses sock puppets or minions, thanks. I'm performing a useful service; I'll be fact-checking all of your stuff for a little while. Won't take me 5 minutes a day. Don't worry, all other posts will be strictly on-topic from here on out.
I don't mind losing debates, but I no longer abide frauds. Particularly not frauds who apologize for incompetence.
Yes, as you imply, clearly the WWW is the most important foundational piece of the Internet. Not the invention or popularization of markup languages or Arpanet or Telenet or any of the other early American computer networks.
Maybe it could have something to do with the fact that half of you security "experts" are clearly frauds who do not understand the first thing about information theory. Where do you work, by the way?
The $1000 is still yours, if you or one of your mental midget followers can manage to demonstrate a flaw in my design.
Summary here: https://slashdot.org/comments.... The preamble is a loose working definition of hash. My stances and claims are enumerated below.
I disagree with the current state of discourse virtually everywhere, and on virtually every topic. Insularity of experts and alleged experts, in both technical and non-technical fields, is one of the most daunting challenges that modern civilization faces and (when I can find the time) it's something I intend to explore at length. Part of the issue is what I call "The Inverse Bike Shed Effect", although there are a lot of other factors involved here, many quite sordid.
One tragic consequence of all this is that clear communication, including pointing out the flaws in the information that was just handed to you, is routinely mis-characterized as irrational or emotional communication, often even in the context of a debate. It is possible to purge all emotion while still conveying the same information, but this has the regrettable, almost invariable side-effect of causing critical information to be overlooked. You can be called boring or hysterically irrational, but never anything in-between.
I managed to retrieve your key (it appears that MIT doesn't take too kindly to VPNs) and will be emailing you shortly.
I don't doubt that this is well-tread ground. I never claimed to be an expert. So, whatever existing product there may be accomplishes the same basic goals as my scheme--use that instead. My overarching point is that he status quo is not acceptable and that some form of client-side hashing (or pseudo-hashing) must be present to mitigate the potential incompetence of people running the server.
"Every thread" == two different threads, apparently.
The whole argument is just fundamentally flawed anyway. All it boils down to "I'm lazy and want to reuse the same password. I don't trust you to protect me from my own lazyness server-side so do it... client-side!" like its going to be some magic bullet of accountability/auditability or something...
Everybody is lazy. Password reuse will happen regardless of training. Our computers are powerful enough to make what I'm saying trivial to do in principle, particularly in places where HTTPS is already used. I do not think the laziness of devs and admins should trump the laziness of users. As a general principle, I think that computers should remove as much of the burden from users as possible. I think that people who believe that users everywhere should do extra work and memorize more stuff instead of the devs doing a little extra work have no business whatsoever in the IT industry.
You might as well argue that the functionality to lookup and auto-dial phone numbers on cell phones is flawed and we'd all be better off if phone numbers had to be memorized.
like its going to be some magic bullet of accountability/auditability or something...
You may want to work on your reading comprehension. I am very, VERY clear that client-side hashing is not a magic bullet. It reduces the attack surface (by which I mean discovering the plaintext password without having to crack a hash) a little bit, but its main purpose is easy auditing. Other than those two things, serverside hashing is pretty much better across the board. I am further VERY clear that neither one will protect a weak password from having its hash quickly cracked.
Nice try, but you didn't invent serverside hashing. I was merely clarifying that this wasn't intended to replace server-side hashing. The role that server hashes have only partially overlaps with the role of client-side hashes.
You didn't point out a flaw in anything. I never said my scheme was comprehensive or meant to take the place of anything.
Even if it wasn't, its just a bad implementation of a problem solved in a much more elegant and secure manner elsewhere e.g. federated authentication.
Don't give a shit. Implement that, then. Some other guy said that Kerberos fixed the problems I was talking about--use that, then. I never claimed this to be more than a 5000 foot back of the napkin thing written by a non-expert; nonetheless, it is provably much, much better than how most places are doing it. I don't have to be dog expert to know that your Chihuahua makes a shit guard dog. If my layman suggestion of "use a Great Dane" isn't ideal, I don't care; it's still objectively much, much better than the status quo.
Your 'security bulletins, browser popups and corporate pressure' you've mentioned elsewhere is just... laughable.
Uh, no it isn't. This is the non-technical aspect, and I assure you that a dozen industry professionals, people who had clout (and obviously would be using a refined version of this, maybe with challenge response, maybe some other very old idea that nonetheless address my concerns) using very aggressive shaming and security advisory techniques could easily change how things are done. None of this is particularly hard to implement in principle; there's just too much political momentum behind the current criminally incompetent way of doing things.
Incidentally, the client-side part of idea apparently has been independently thought of and implemented as a browser extension called Hashpass. I've not had time to examine this yet.
I need more peace and quiet than is available at the moment to be able to properly navigate through the literature for the bits I need. Conversing is usually easier than absorbing unless the literature is of exceptional quality. Is there any you care to recommend?
For the key, I'll get back to you on that tomorrow. I haven't used GPG in quite a while. These days, it's hard enough convincing people to even use OTR. I'm doing something decidedly less pleasant than network security at the moment and it would actually be much quicker to get the proper concepts and/or terminology from one of you, if only one of you would drop this childish, pedantic elitism for just a few moments.
you can replace SHA-256 with other commonly used algorithms, and you'll get very similar results.
Uh huh. I'm afraid I can't quite let this slide--before we take this conversation private, I need to clearly emphasize just how ridiculous you're behaving.
As I've repeatedly indicated, I am a layman using goal-based working definitions, not technical process-based terms, because I am not (and never claimed to be) intimately familiar with the processes. I'm using "hash" as a shorthand for so-called one-way functions that are intended to obscure, i.e. with no need for symmetry or decoding but a strong need for it to be hard to reverse. I'm sure that "hash" means something very different to you. Congratulations. I knew that there was a distinction between "nonce" and "salt" too (and I even briefly brought up nonces in this thread long before you did), but that doesn't mean you have a legitimate point here. Ditto "hash" and whatever magical terms there are that you refuse to share with me.
You know... if I hear someone saying "clip" instead of "magazine" or "mag" I will sometimes correct them, but you know what I don't do? Pretend to not understand what they are talking about and then refuse to tell them the correct term. And if someone says "hey, the reason why that clip isn't fitting is it's backwards!"... the fact that you aren't actually holding a clip in your hand has very little bearing on the usefulness of their advice.
An astute observer might mention that there are subsets of this family of algorithms, having the strict stipulation of input sizes being less than the output digest size, which are referred to as perfect hashing functions. These are actually relatively rarely used for typical cryptographic applications, and for various good reasons.
I'm not sure if you could have ended that sentence in a more obnoxious manner, given the context of this discussion. (However, I'll go out on a limb here and say that it potentially leaks too much information about the input. Yes?)
That said, before I go any further, I do withdrawal my assertion (from a couple posts back, but not present in my original post) that provably zero collisions is achievable. I mean such transforms do exist, obviously, but perhaps not in a manner that is also sufficiently hard for an attacker to reverse engineer.
So let's do a bit of a test here to see how much intellectual honesty you're capable of. You and a lot of other people are caught up on the word "hash", even though I told you to feel free to substitute another word. Given your last few replies, the implication is that such a substitution doesn't exist and what I'm suggesting is inherently flawed and that *any* hashlike algorithm would have these issues. Well, ok then. I wish for you to tell me precisely what is wrong with this setup. I am not saying that this is what the final product would look like (I have no idea how it would look once optimized for efficiency), but it may give you a better idea of what I include under my umbrella term of "hash".
Plug the salt (or nonce or whatever you term it; I do_not_care) and password into a well designed crypto PRNG capable of generating a stream of numbers of arbitrary le
. The main difference between LXC and Docker containers is LXC launches a minimal init process in the chroot/pivot root while Docker launches the app process directly.
I know containers don't depend on cgroups or any other stuff that the systemd folks hype, but it's something that systemd appears to pander to--and it's something that Poettering is specifically catering to. The issue is that different types of criticisms are being conflated:
1. Some people say that cgroups suck (in implementation or design.) Not having used it, I couldn't say, but if there are concrete reasons for saying so then OK, that's fine.
2. Some people don't like that it's a hard requirement for systemd. I'm fully on board with this criticism--it locks out the BSDs unnecessarily and doesn't appear to jive with systemd's core purpose, or rather what should be its core purpose. This is where the modularity complaints come into play: whatever Poettering wants to have cgroups for, he should bloody well keep it out of our base init system.
3. Some people say "who needs cgroups?" (or the much worse "who needs containerization?") and this makes me cringe. There are so, so many clusterfucks in this world that can be gracefully sidestepped with virtualization/containerization and anything that improves the use or control of containers is by definition a win, at least on paper (but see #1.)
#3 is quite bad for the anti-systemd cause; the response "why would you want to do that?" / "We're not concerned with that use case" is one of the most annoying things to say to anyone.
#1 may or may not have merit.
#2 is entirely appropriate, and if you can offer an equivalent or better solution on an OpenRC system (either implemented or an in-principle solution) then that would also be a great point to raise.
An ad hominem is not an 'attack'; it is an informal fallacy, and it is one I did not commit. You being a dick is a (tentative) conclusion, not a piece of supporting evidence used to reach some other conclusion.
And I'm probably unbearably arrogant. Not going to let that stop me. I find there is nothing LESS constructive in this world than slavish adherence to positive tones. Positive tones should follow positive content.
actually I suppose the kicker is avoiding information leakage and collisions at the same time, right? That may be slightly tricker. But the fact is I never said SHA, and even if the word "hash" is entirely inappropriate you and I both know that the properties I am describing are achievable. You probably even have a word for it; you're just having too much fun to come out and say it.
How about this: you tell me the word you know I'm referring to, and I'll go and replace "hash" with that word in every communication from now on.
A hash-like transform but without compression aspects. A "one way" transform that is very hard to reverse--toss a little RSA in here somewhere, I don't give a shit. The nuts and bolts of it wasn't the point; I implicitly and then later explicitly deferred that you people, the alleged experts too busy apologizing for gross incompetence to actually push for solutions. You and I both know that the properties I am describing here are achievable using known and freely available algorithms, without needing much more CPU than HTTPS already requires.
ecisively demonstrates your flawed understanding of the subject matter at hand
Blah blah blah. It merely proves I don't use your jargon, which is something I repeatedly admitted up front. I am fairly positive could design something utilizing SHA with zero collisions, given an aggregate storage space for output from the hashes that was significantly bigger than the maximum password size. This probably wouldn't be the most efficient way of doing things, and you probably have some other special word to refer to what I'm talking about ("key derivation function" ?), but I never claimed my 5000 foot back of napkin design was meant to be comprehensive or final. Pay me for my time, and I'd be happy to learn your lingo and also provide a more specific, less wasteful solution. But at no point did I remotely expect or imply that anyone should use SHA256 in that manner.
Your response also tends to indicate you are, at best, a dick whose top priority is providing highly misleading statements in a clumsy attempt to cover for the gross negligence and incompetence of the people running your industry. But it's possible you're merely a sore loser, because by now you must realize that I was absolutely correct in everything I said and the only possible criticism you can have ultimately centers around the fact that I wasn't invited to the clubhouse to learn the secret handshake and codewords.
Or is this a jargon issue? Am I wrong because I didn't say "key derivation function" instead of "hash"? I really don't care. I'm not even going to look it up on wikipedia; I've no desire to learn about the intricacies of your silly little DSL; I don't need to in order to understand that the incompetence of your industry is screwing over millions of people. You know my solution is entirely effective, because it does not decrease security (properly implemented) and unlike server-side stuff is it actually audit-able.
And the fact that you choose to badmouth me and hide behind pseudonymity instead of debating or providing an equivalent system of your own (using all of the correct magical words that you special snowflakes have invented for yourselves) makes you complicit in that incompetence. What incompetence? This incompetence: https://slashdot.org/comments....
Upon further consideration: A single random server-provided salt is more desirable for the client-side hash since it does prevent the use of rainbow tables; however, I'm not particularly impressed since it's redundant with the random-salt server hash and the salt can be easily obtained by any attacker. The only significant advantage here is it prevents rainbow tables from be used in the case that client side hashing is present but server doesn't do any hashing... so, if you entirely agree with my philosophy of protecting ourselves from incompetently administered backends, then yes, by all means use different client salt value for each client, a value that the server must provide to anyone who asks.
So, I've identified a reason for doing what some of you are suggesting but for completely different reasons, and you are still very, very wrong about the properties of competently designed hashes.
Challenge-response hashing would be yet another interesting layer to add, but I'm not sure I like it. It requires that the client and server both have access to the same initial value to hash, which I view as inherently undesirable (I want the server to have access only to a hash that used random salt known only to it), but the randomization of client salt *is* interesting. Needs further pondering. I'm distracted at the moment. I'll get back to you.
Hey, it looks like all of your friends around here think I'm wrong because they seem to think that "hash" means a single default invocation of whatever CLI version of sha they have lying around, without any regard whatsoever to the size of input and output.
Is that what you thought? Is your brain so ossified that you cannot conceive of the fact that, in the presence of input maximums (which all websites have with the password fields), it is in fact entirely possible to construct a hash algorithm that does not generate collisions?
I'm still having to guess at the source of your idiocy here, since you refuse to explain yourself. I'm breathless with anticipation to find out if I'm right.
Yes, because incompetent jackasses who refuse to provide any explanation whatsoever deserve +5 informative.
I've shot down every objection people have given, and I've convinced someone who has a CS Masters degree and experience with cryptography that my design (which was never asserted to be a comprehensive solution, just an easy and important improvement) is fundamentally sound and desirable.
Slashdot Mirror
I'm not stalking you, you pathetic drama queen. I'm temporarily providing a service to the community to make sure you don't spread any more (unchallenged) self-indulgent authoritarian gibberish for a little while. Also, there may be some jokes at your expense if you happen set me up with a good line. Things have been slow lately but I've some upcoming stuff that will require my keenest attention and after that point I'm pretty sure keeping an eye on you will fall far down into the darkest depths of the extended to-do list, never to be seen again.
Jesus Christ, somebody certainly has a big ego.
Do you want me to stalk you? I'm going to have to see a picture before I make that kind of commitment. Or at least some measurements.
Possibly, though I think the better explanation might have to do with Hillary's self-identification as a feminist.Just read any post regarding feminism and see all the people railing against "SJWs". I think gender is still very relevant for a lot of people.
I'm sure plenty of sexists use anti-SJW criticism as cover, but this is some damn twisted logic you've got going on there.
The person who brings up gender by:
* Explicitly calling herself a feminist (as you yourself just mentioned)
* Campaigning for feminist causes
* Having her people engage in those "Bernie Bros" attack
* Treating every single negative thing Trump has ever said about specific women as evidence that he believes they are an inferior sex
is demonstrating that gender is, in fact, "relevant" to her.
The people who are reacting to it... are the ones reacting to it. Some rightly, some wrongly.
*sigh*. 4chan is what started and popularized that meme. Don't mod down a joke just because you don't get it. (and don't mod this up informative, either.)
If you want to help keep 4chan the way it is and not have it all crapped up with ads, a crowdfunding campaign has been set up here.
Does anyone know more info about it?
Yes, I do recall having read something somewhere about it being total bullshit.
But wait, there's this new study I heard about...
If there does turn out to be a small link, I'll be shocked if the risk is going to be too minuscule to obsess over. People only care about cell phones causing cancer because invisible EM / radio waves are freaky. It's weird magical stuff flying through the air that I can't see or hear or smell --> We need to be paranoid about it. That is the basis of the concern over non-ionizing EM causing cancer. Here are a list of things that we're almost certain cause cancer:
* Barbecued food with any black "grill marks" or other carbonization on it.
* Smoked foods
* Regularly being around lit candles
* Being around a lit fireplace, even if it's just occasionally.
* Drinking your coffee (or any other drink/food) while it's too hot.
* The sun--anything over the minimum amount required for your body to manufacture the vitamin D you need (just a few minutes per day, at least for lower-melanin people in lower latitudes).
* Possibly anything that causes prolonged or repeated inflammation.
I'm not saying you shouldn't worry about your kids or err on the side of caution, but if you aren't at all concerned about everything on the above list... don't kid yourself. You're not a safe, informed conscientious parent. You're simply unduly afraid of what you don't understand.
The problem is that you have no clue about the topic
The problem is you don't understand the concept of "in principle" or perhaps even causation in general.
Mike bought three shirts last week. The first one was $900. The second one was $1700. The third one was $1300.
This is your logic at work: If Mike lost all his money and then had a house fire and lost all his clothes and other possessions, he shouldn't ever buy another shirt again, even though all of his clothes have been burned up, because he can't afford it. Because the data clearly shows that Mike only buys expensive shirts. He should walk around shirtless, for the rest of his life, because it wouldn't make sense for a poor person to spend so much money on a shirt.
This fully encapsulates your current argument. I've already agreed that past and existing nuclear power plants generate too much waste, fully agree! (Although I don't view the waste as being quite as dangerous as some people seem to think it is.) That is not the same thing as saying nuclear power inherently creates a lot of waste.
Actual experts can succinctly explain why they consider something to be massively flawed.
And I'm not going to take etiquette advice from someone who uses sock puppets or minions, thanks. I'm performing a useful service; I'll be fact-checking all of your stuff for a little while. Won't take me 5 minutes a day. Don't worry, all other posts will be strictly on-topic from here on out.
I don't mind losing debates, but I no longer abide frauds. Particularly not frauds who apologize for incompetence.
People do not understand that Mathematics is pretty absolute.
Including yourself.
"Discovery"? Like how radium was discovered?
Yes, as you imply, clearly the WWW is the most important foundational piece of the Internet. Not the invention or popularization of markup languages or Arpanet or Telenet or any of the other early American computer networks.
Maybe it could have something to do with the fact that half of you security "experts" are clearly frauds who do not understand the first thing about information theory. Where do you work, by the way?
The $1000 is still yours, if you or one of your mental midget followers can manage to demonstrate a flaw in my design.
Summary here: https://slashdot.org/comments.... The preamble is a loose working definition of hash. My stances and claims are enumerated below.
I disagree with the current state of discourse virtually everywhere, and on virtually every topic. Insularity of experts and alleged experts, in both technical and non-technical fields, is one of the most daunting challenges that modern civilization faces and (when I can find the time) it's something I intend to explore at length. Part of the issue is what I call "The Inverse Bike Shed Effect", although there are a lot of other factors involved here, many quite sordid.
One tragic consequence of all this is that clear communication, including pointing out the flaws in the information that was just handed to you, is routinely mis-characterized as irrational or emotional communication, often even in the context of a debate. It is possible to purge all emotion while still conveying the same information, but this has the regrettable, almost invariable side-effect of causing critical information to be overlooked. You can be called boring or hysterically irrational, but never anything in-between.
I managed to retrieve your key (it appears that MIT doesn't take too kindly to VPNs) and will be emailing you shortly.
A comprehensive clarification of where I stand and what I claim can be found here: https://slashdot.org/comments....
I don't doubt that this is well-tread ground. I never claimed to be an expert. So, whatever existing product there may be accomplishes the same basic goals as my scheme--use that instead. My overarching point is that he status quo is not acceptable and that some form of client-side hashing (or pseudo-hashing) must be present to mitigate the potential incompetence of people running the server.
The whole argument is just fundamentally flawed anyway. All it boils down to "I'm lazy and want to reuse the same password. I don't trust you to protect me from my own lazyness server-side so do it... client-side!" like its going to be some magic bullet of accountability/auditability or something...
Everybody is lazy. Password reuse will happen regardless of training. Our computers are powerful enough to make what I'm saying trivial to do in principle, particularly in places where HTTPS is already used. I do not think the laziness of devs and admins should trump the laziness of users. As a general principle, I think that computers should remove as much of the burden from users as possible. I think that people who believe that users everywhere should do extra work and memorize more stuff instead of the devs doing a little extra work have no business whatsoever in the IT industry.
You might as well argue that the functionality to lookup and auto-dial phone numbers on cell phones is flawed and we'd all be better off if phone numbers had to be memorized.
like its going to be some magic bullet of accountability/auditability or something...
You may want to work on your reading comprehension. I am very, VERY clear that client-side hashing is not a magic bullet. It reduces the attack surface (by which I mean discovering the plaintext password without having to crack a hash) a little bit, but its main purpose is easy auditing. Other than those two things, serverside hashing is pretty much better across the board. I am further VERY clear that neither one will protect a weak password from having its hash quickly cracked.
You didn't point out a flaw in anything. I never said my scheme was comprehensive or meant to take the place of anything.
Even if it wasn't, its just a bad implementation of a problem solved in a much more elegant and secure manner elsewhere e.g. federated authentication.
Don't give a shit. Implement that, then. Some other guy said that Kerberos fixed the problems I was talking about--use that, then. I never claimed this to be more than a 5000 foot back of the napkin thing written by a non-expert; nonetheless, it is provably much, much better than how most places are doing it. I don't have to be dog expert to know that your Chihuahua makes a shit guard dog. If my layman suggestion of "use a Great Dane" isn't ideal, I don't care; it's still objectively much, much better than the status quo.
Your 'security bulletins, browser popups and corporate pressure' you've mentioned elsewhere is just... laughable.
Uh, no it isn't. This is the non-technical aspect, and I assure you that a dozen industry professionals, people who had clout (and obviously would be using a refined version of this, maybe with challenge response, maybe some other very old idea that nonetheless address my concerns) using very aggressive shaming and security advisory techniques could easily change how things are done. None of this is particularly hard to implement in principle; there's just too much political momentum behind the current criminally incompetent way of doing things.
Incidentally, the client-side part of idea apparently has been independently thought of and implemented as a browser extension called Hashpass. I've not had time to examine this yet.
For the key, I'll get back to you on that tomorrow. I haven't used GPG in quite a while. These days, it's hard enough convincing people to even use OTR. I'm doing something decidedly less pleasant than network security at the moment and it would actually be much quicker to get the proper concepts and/or terminology from one of you, if only one of you would drop this childish, pedantic elitism for just a few moments.
you can replace SHA-256 with other commonly used algorithms, and you'll get very similar results.
Uh huh. I'm afraid I can't quite let this slide--before we take this conversation private, I need to clearly emphasize just how ridiculous you're behaving.
As I've repeatedly indicated, I am a layman using goal-based working definitions, not technical process-based terms, because I am not (and never claimed to be) intimately familiar with the processes. I'm using "hash" as a shorthand for so-called one-way functions that are intended to obscure, i.e. with no need for symmetry or decoding but a strong need for it to be hard to reverse. I'm sure that "hash" means something very different to you. Congratulations. I knew that there was a distinction between "nonce" and "salt" too (and I even briefly brought up nonces in this thread long before you did), but that doesn't mean you have a legitimate point here. Ditto "hash" and whatever magical terms there are that you refuse to share with me.
You know... if I hear someone saying "clip" instead of "magazine" or "mag" I will sometimes correct them, but you know what I don't do? Pretend to not understand what they are talking about and then refuse to tell them the correct term. And if someone says "hey, the reason why that clip isn't fitting is it's backwards!"... the fact that you aren't actually holding a clip in your hand has very little bearing on the usefulness of their advice.
An astute observer might mention that there are subsets of this family of algorithms, having the strict stipulation of input sizes being less than the output digest size, which are referred to as perfect hashing functions. These are actually relatively rarely used for typical cryptographic applications, and for various good reasons.
I'm not sure if you could have ended that sentence in a more obnoxious manner, given the context of this discussion. (However, I'll go out on a limb here and say that it potentially leaks too much information about the input. Yes?)
That said, before I go any further, I do withdrawal my assertion (from a couple posts back, but not present in my original post) that provably zero collisions is achievable. I mean such transforms do exist, obviously, but perhaps not in a manner that is also sufficiently hard for an attacker to reverse engineer.
So let's do a bit of a test here to see how much intellectual honesty you're capable of. You and a lot of other people are caught up on the word "hash", even though I told you to feel free to substitute another word. Given your last few replies, the implication is that such a substitution doesn't exist and what I'm suggesting is inherently flawed and that *any* hashlike algorithm would have these issues. Well, ok then. I wish for you to tell me precisely what is wrong with this setup. I am not saying that this is what the final product would look like (I have no idea how it would look once optimized for efficiency), but it may give you a better idea of what I include under my umbrella term of "hash".
Plug the salt (or nonce or whatever you term it; I do_not_care) and password into a well designed crypto PRNG capable of generating a stream of numbers of arbitrary le
. The main difference between LXC and Docker containers is LXC launches a minimal init process in the chroot/pivot root while Docker launches the app process directly.
I know containers don't depend on cgroups or any other stuff that the systemd folks hype, but it's something that systemd appears to pander to--and it's something that Poettering is specifically catering to. The issue is that different types of criticisms are being conflated:
1. Some people say that cgroups suck (in implementation or design.) Not having used it, I couldn't say, but if there are concrete reasons for saying so then OK, that's fine.
2. Some people don't like that it's a hard requirement for systemd. I'm fully on board with this criticism--it locks out the BSDs unnecessarily and doesn't appear to jive with systemd's core purpose, or rather what should be its core purpose. This is where the modularity complaints come into play: whatever Poettering wants to have cgroups for, he should bloody well keep it out of our base init system.
3. Some people say "who needs cgroups?" (or the much worse "who needs containerization?") and this makes me cringe. There are so, so many clusterfucks in this world that can be gracefully sidestepped with virtualization/containerization and anything that improves the use or control of containers is by definition a win, at least on paper (but see #1.)
#3 is quite bad for the anti-systemd cause; the response "why would you want to do that?" / "We're not concerned with that use case" is one of the most annoying things to say to anyone.
#1 may or may not have merit.
#2 is entirely appropriate, and if you can offer an equivalent or better solution on an OpenRC system (either implemented or an in-principle solution) then that would also be a great point to raise.
An ad hominem is not an 'attack'; it is an informal fallacy, and it is one I did not commit. You being a dick is a (tentative) conclusion, not a piece of supporting evidence used to reach some other conclusion.
And I'm probably unbearably arrogant. Not going to let that stop me. I find there is nothing LESS constructive in this world than slavish adherence to positive tones. Positive tones should follow positive content.
I'll get back to you with the key later tonight.
actually I suppose the kicker is avoiding information leakage and collisions at the same time, right? That may be slightly tricker. But the fact is I never said SHA, and even if the word "hash" is entirely inappropriate you and I both know that the properties I am describing are achievable. You probably even have a word for it; you're just having too much fun to come out and say it.
How about this: you tell me the word you know I'm referring to, and I'll go and replace "hash" with that word in every communication from now on.
A hash-like transform but without compression aspects. A "one way" transform that is very hard to reverse--toss a little RSA in here somewhere, I don't give a shit. The nuts and bolts of it wasn't the point; I implicitly and then later explicitly deferred that you people, the alleged experts too busy apologizing for gross incompetence to actually push for solutions. You and I both know that the properties I am describing here are achievable using known and freely available algorithms, without needing much more CPU than HTTPS already requires.
ecisively demonstrates your flawed understanding of the subject matter at hand
Blah blah blah. It merely proves I don't use your jargon, which is something I repeatedly admitted up front. I am fairly positive could design something utilizing SHA with zero collisions, given an aggregate storage space for output from the hashes that was significantly bigger than the maximum password size. This probably wouldn't be the most efficient way of doing things, and you probably have some other special word to refer to what I'm talking about ("key derivation function" ?), but I never claimed my 5000 foot back of napkin design was meant to be comprehensive or final. Pay me for my time, and I'd be happy to learn your lingo and also provide a more specific, less wasteful solution. But at no point did I remotely expect or imply that anyone should use SHA256 in that manner.
Your response also tends to indicate you are, at best, a dick whose top priority is providing highly misleading statements in a clumsy attempt to cover for the gross negligence and incompetence of the people running your industry. But it's possible you're merely a sore loser, because by now you must realize that I was absolutely correct in everything I said and the only possible criticism you can have ultimately centers around the fact that I wasn't invited to the clubhouse to learn the secret handshake and codewords.
Or is this a jargon issue? Am I wrong because I didn't say "key derivation function" instead of "hash"? I really don't care. I'm not even going to look it up on wikipedia; I've no desire to learn about the intricacies of your silly little DSL; I don't need to in order to understand that the incompetence of your industry is screwing over millions of people. You know my solution is entirely effective, because it does not decrease security (properly implemented) and unlike server-side stuff is it actually audit-able.
And the fact that you choose to badmouth me and hide behind pseudonymity instead of debating or providing an equivalent system of your own (using all of the correct magical words that you special snowflakes have invented for yourselves) makes you complicit in that incompetence. What incompetence? This incompetence: https://slashdot.org/comments....
https://slashdot.org/comments.... *Cannot* be trusted.
Upon further consideration: A single random server-provided salt is more desirable for the client-side hash since it does prevent the use of rainbow tables; however, I'm not particularly impressed since it's redundant with the random-salt server hash and the salt can be easily obtained by any attacker. The only significant advantage here is it prevents rainbow tables from be used in the case that client side hashing is present but server doesn't do any hashing... so, if you entirely agree with my philosophy of protecting ourselves from incompetently administered backends, then yes, by all means use different client salt value for each client, a value that the server must provide to anyone who asks.
So, I've identified a reason for doing what some of you are suggesting but for completely different reasons, and you are still very, very wrong about the properties of competently designed hashes.
Challenge-response hashing would be yet another interesting layer to add, but I'm not sure I like it. It requires that the client and server both have access to the same initial value to hash, which I view as inherently undesirable (I want the server to have access only to a hash that used random salt known only to it), but the randomization of client salt *is* interesting. Needs further pondering. I'm distracted at the moment. I'll get back to you.
Hey, it looks like all of your friends around here think I'm wrong because they seem to think that "hash" means a single default invocation of whatever CLI version of sha they have lying around, without any regard whatsoever to the size of input and output.
Is that what you thought? Is your brain so ossified that you cannot conceive of the fact that, in the presence of input maximums (which all websites have with the password fields), it is in fact entirely possible to construct a hash algorithm that does not generate collisions?
I'm still having to guess at the source of your idiocy here, since you refuse to explain yourself. I'm breathless with anticipation to find out if I'm right.
Yes, because incompetent jackasses who refuse to provide any explanation whatsoever deserve +5 informative.
I've shot down every objection people have given, and I've convinced someone who has a CS Masters degree and experience with cryptography that my design (which was never asserted to be a comprehensive solution, just an easy and important improvement) is fundamentally sound and desirable.