In statistics, "average" often means "expected value". No time frame is specified (although you could consider it an infinite time frame). With a small sample size your actual average might not be 10 minutes, but as your sample size grows, it will tend toward 10 minutes.
If you are talking about spherical-cow style poisson buses, yeah (that's what the author means by "reasonable assumptions). But as the author concludes, bus arrival times are not well modeled by a poisson process.
Here's my take. The prisoner considers the statement "I will be hanged, and it will be a surprise", and after "proving" it false, takes its negation "Either I won't be hanged, or it won't be a surprise". But this is not correct. The prisoner actually disproves the statement "I will be hanged, and it will be a surprise no matter which day it happens". When you negate this statement, you obtain "Either I won't be hanged, or there is a day that it would not be a surprise", which is consistent with the outcome.
The paradox is because the prisoner does indeed disprove the statement "I will be hanged, and it will be a surprise no matter which day it happens", but the statement turns out to be true (he is both hanged, and surprised no matter what day he's hanged).
No, it would not have been a surprise if he were hanged on Friday. The prisoner disproves the existence of a strategy for the judge that guarantees surprise, but does not disprove the existence of a strategy that gives the possibility of surprise.
He concludes that because he assumes what the judge said is true. If we assume that, we must reject the scenario where he gets executed without surprise.
Actually, you're right. However, the paradox arises no matter what the prisoner concludes. If he concludes that the hanging won't be a surprise, he will be surprised by the outcome (the knock on Wednesday).
Let me say it again in a different way. My resolution of the paradox is that the prisoner incorrectly negates "x will happen" as "x won't happen" instead of negating "x definitely will happen" as "x might not happen". Thus,the prisoner cannot conclude that the hanging won't be a surprise. The prisoner can only conclude that the hanging might not be a surprise.
I don't think multi-algorithm is taken into account for multi-algorithm coins. Several coins have multiple independent mining algorithms each with their own difficulty, and need to be attacked simultaneously.
Yes, this is correct - I wasn't actually aware that there were multi-algorithm coins, but I'm assuming there aren't very many. I will go through the list and try to update this, but let me know if there are any that you know of that I should update.
(c(mod p)) (mod 2) = (p * q + 2 * r + m (mod p)) (mod 2) = 2r + m (mod 2) = m
This breaks if 2*r > p. Even if you choose r to be small during encryption, the r values accumulate with each homomorphic operation and will eventually be too big. The only restriction stated is that r is "from a different interval than the private key one". This should be made more clear.
> Even if you choose r to be small during encryption, the r values accumulate with each homomorphic operation and will eventually be too big
As @tuxxy points out, there is a metaphor for describing this - a "noise ceiling". To see this phrase used in context, see, for example: https://eprint.iacr.org/2011/277.pdf
I used to answer secret questions with bogus answers that I deemed unguessable. Then I discovered that when my bank asks me the questions back it does multiple choice, displaying the answer I gave along with 4 other possible options! Sometimes my answer would not be shown and the correct answer is "none of the above", but otherwise my answer sticks out like a sore thumb.
Who in the world thought this was a good idea!? I can hardly think of a less secure way to ask security questions. You should name and shame; there’s a minimum bar everyone should uphold and this is far below it.
The problem they were trying to solve is someone typing in “Woodbridge Lane” as the answer and then later typing “Wood Bridge” or “Woodbridge Ln” or “Woodbridge Ln.” when prompted.
This, too, was my problem. I don't want to give out real answers to my security question for two (slightly contradictory) reasons. The first is: what if this site is hacked? Now my security question answers are floating around for use on other sites that ask similar questions. The second is: some of these questions are pretty easy to find the answer to, or guess. So I used a generated string for those questions, too. Generally worked, but sometimes made for some interesting phone calls. "My mothers maiden name is <random string>. You can guess why she took my father's."
Then they started reading back random choices, which made it pretty easy to guess what I picked.
I have a third problem -- often times, the list of questions they ask are non-sense to me. "What is your favorite food?" I don't have a favorite, and can't think of anything that I'd remember later. "What was the name of your first pet?" I never had a pet. "What was the name of your high school sweetheart?" Gee, thanks a lot for stirring up bad memories.
Funny story - I had an old short-length insecure password on a website that I hadn't used for years.
I decided to log in and change it to a randomly generated secure password. However, they had upgraded their off the shelf software some time over the last 4-5 years to a newer version.
The problem was, on their password change page the "new password" field had a minimum length of 8 characters, however the "OLD password" field also had that exact same requirement.
So I put in:
* Old: 12345
* New: 717&t!1XFCWJWk!q@ut3B
* Confirm: 717&t!1XFCWJWk!q@ut3B
And got an error "your password must be 8 characters or greater".
After swearing a few times, I breakpointed and edited the javascript validation to remove the length requirement and submitted the change again - this time got a server-side error saying the same thing.
I ended up beating it by logging out, clicking "I've forgot my password" and resetting it via email.
I had a similar experience with a city bill pay website, except in this situation it was a new account and they simply didn't prevent me from setting the password to something long in the first place, so once my account was created I wasn't allowed in. And because you need to log in once to verify your email, I couldn't reset the damn thing either.
Just go with the snark and out in a joke answer that you will find funny. Some of my security questions are hilariously inapplicable, so the first silly, snarky thing I think up is likely to be memorable. It is also a little hard to guess unless you know me really well to an unlikely degree, and it won't stick out as much as a sore thumb in multi-choice situations.
Yesterday, I was logging onto Australian MyGov site, and forgot the password, it sent SMS code for reset to my mobile phone, but then would not let me proceed without answering the secret questions. I usually put last word of the question sentence as an answer itself because I can't be bothered, but it was not the case this time. Not a great experience when they threaten lock out of account, and you have to go link all services again on a new account. Also, the site has no option to change mobile number for SMS code, and you will have to create a new account if you change your number.
Some of it is legacy - integrating systems built throughout the last three decades.
Some of it is management - they fired multiple teams partway through, with 100% turnover. They also massively underfunded said teams, devoting the majority of funding to PR. Also some... Interesting technical policies, like banning version control and advocating regular backups instead. (Something to do with code "theft protection").
Some of it was technical issues - different integration teams were given different browser compatibility goals. Some teams were told they must use PHP and Apache, others they must use NodeJS and nginx. Often for related parts of the UI.
If you want to know how to screw up a multi-million dollar project, look no farther.
(Source: Worked with a team leader during one of the "fire everyone" times.)
Some people think they're too smart for putting a random string as their mother's maiden name. I'd rather just put something that looks like a name there.
There's a decent chance the passwords you found aren't the actual passwords either, considering how easy it is to generate collisions for the hash function.
"(long)pow(a, len_s - (i+1))" is both inefficient and inaccurate. You should store the current power in a variable which you multiply by 'a' and reduce by 'm' on each iteration.
Also, your double hashing scheme has a bug. You identified that it's problematic if hash_b returns 0, but adding 1 to the result doesn't actually solve anything, because now you have the same problem if hash_b returns num_buckets-1.
