Re:Now what do we use?
on
SHA-1 Broken
·
· Score: 1
The paper says nothing about RIPEMD-128 or RIPEMD-160, which are strengthened versions of the original RIPEMD. The original RIPEMD attack paper that the above-linked paper cites was done by H. Dobbertin in '95. In '96 he co-authored the paper that introduced RIPEMD-128 and RIPEMD-160.
This is also reflected in the "Attack(s)" column on the Hashing Function Lounge page which others have cited.
Microsoft, for example, was instrumental in helping Apple resolve problems with Mac OS X
We can only speculate as to whether Microsoft did anything more than report the bugs, but certainly Apple wouldn't have provided Microsoft with their propietary source code, so unless the bugs were in the Darwin subset of Mac OS X (seems unlikely), it would seem clear that reporting them is all they did.
If I find 70 bugs in OS X and report them, can I also have a CNET story stating that "Dan Harkless was instrumental in helping Apple resolve problems with OS X"...?
Hey, thanks for that. Several people have mentioned seeing such a list somewhere, but no one else have a URL.
Interesting that a couple of the de-trademarked names are still used by their companies as if they were trademarked. For instance, Monopoly and Softsoap.
I've seen lots of "themed" Monopoly variants over the years -- are some of those by companies other than Parker Brothers (?) and are they able to get away with that only because Monopoly has lost its trademark status?
I do get a little tired of them endlessly having to mention "MSNBC is partially owned by Microsoft" (or however it's worded) every time they mention the big M. I'd rather have them use a hyperlinked asterisk that jumps to that disclaimer at the bottom of the page.
Someone said that the only way they could think of to discourage ballot stuffing was to make each vote expensive. Well, that assumes that nobody with lots of money wants to stuff ballots.
Better than making it expensive monetarily might be to make it expensive time-wise. Voting would require going to a page that gives an X-minute delay after submission. At the end of the delay, a random (out of big pool) multiple-choice question would appear, and only Y seconds would be given in which to answer it successfully. The questions would be easy enough that anyone with half a brain could answer them, but the pool would be big enough that you couldn't write a program to answer them without having access to the Q/A database. Don't answer the question correctly in time => your vote isn't counted.
Sounds like a big pain to set up and use, though.
Instead, there are better unique identifiers than email addresses. I'm guessing almost everybody with web access has a credit card. Each credit card number could be given just one vote, and you could take other steps to ensure that the same person didn't vote multiple times using multiple credit cards. You wouldn't even have to charge money to the credit cards, unless it were impossible to use the credit card verification services without charging something. If this were the case, you could just credit back whatever amount you charged. Not sure if fees taken by the credit card verification firms would make this unworkable...
Otherwise, this would work out pretty well -- about the only thing you could do to stuff the ballot boxes would be to get a bunch of friends to vote the same way as you, but this is a danger in any voting situation.
Yeah, 99/99/99 is no doubt more common; SCCS & 99
on
9/9/99: News? Nein!
·
· Score: 1
I agree with the posters saying that anyone who expected 09/09/99 to be a big deal is a bozo. No doubt 99/99/99 is a much more common "special case" date, and since it's not valid, one doesn't need to worry about it ever coming up. I've heard of other special case dates also using invalid months and days, like 88/88/88 and 77/77/77.
The 99 thing is sometimes more of a problem than expected, however. At the beginning of this year, SCCS on our HP-UX 10.20 machines mysteriously started failing. Apparently the HP-UX SCCS tools were using 99 in the year as a special value, even though the SCCS format makes no such specifications. Applying patches fixed this problem.
Slashdot Mirror
Yup, it has happened again, although VeriSign may or may not have been the negligent CA involved. Someone recently managed to get an SSL cert for login.live.com.
The paper says nothing about RIPEMD-128 or RIPEMD-160, which are strengthened versions of the original RIPEMD. The original RIPEMD attack paper that the above-linked paper cites was done by H. Dobbertin in '95. In '96 he co-authored the paper that introduced RIPEMD-128 and RIPEMD-160.
This is also reflected in the "Attack(s)" column on the Hashing Function Lounge page which others have cited.
If I find 70 bugs in OS X and report them, can I also have a CNET story stating that "Dan Harkless was instrumental in helping Apple resolve problems with OS X"...?
Hey, thanks for that. Several people have mentioned seeing such a list somewhere, but no one else have a URL.
Interesting that a couple of the de-trademarked names are still used by their companies as if they were trademarked. For instance, Monopoly and Softsoap.
I've seen lots of "themed" Monopoly variants over the years -- are some of those by companies other than Parker Brothers (?) and are they able to get away with that only because Monopoly has lost its trademark status?
So you're saying people would have to say instead "Hey, Microsoft Bob, I got Office last week"?
Heh. But on a serious note, your point is well-made, and one which hadn't struck me before.
I do get a little tired of them endlessly having to mention "MSNBC is partially owned by Microsoft" (or however it's worded) every time they mention the big M. I'd rather have them use a hyperlinked asterisk that jumps to that disclaimer at the bottom of the page.
And if f0bic stands for "homophobic", we can assume flipz is indeed female. ;^>
Someone said that the only way they could think of to discourage ballot stuffing was to make each vote expensive. Well, that assumes that nobody with lots of money wants to stuff ballots.
Better than making it expensive monetarily might be to make it expensive time-wise. Voting would require going to a page that gives an X-minute delay after submission. At the end of the delay, a random (out of big pool) multiple-choice question would appear, and only Y seconds would be given in which to answer it successfully. The questions would be easy enough that anyone with half a brain could answer them, but the pool would be big enough that you couldn't write a program to answer them without having access to the Q/A database. Don't answer the question correctly in time => your vote isn't counted.
Sounds like a big pain to set up and use, though.
Instead, there are better unique identifiers than email addresses. I'm guessing almost everybody with web access has a credit card. Each credit card number could be given just one vote, and you could take other steps to ensure that the same person didn't vote multiple times using multiple credit cards. You wouldn't even have to charge money to the credit cards, unless it were impossible to use the credit card verification services without charging something. If this were the case, you could just credit back whatever amount you charged. Not sure if fees taken by the credit card verification firms would make this unworkable...
Otherwise, this would work out pretty well -- about the only thing you could do to stuff the ballot boxes would be to get a bunch of friends to vote the same way as you, but this is a danger in any voting situation.
I agree with the posters saying that anyone who expected 09/09/99 to be a big deal is a bozo. No doubt 99/99/99 is a much more common "special case" date, and since it's not valid, one doesn't need to worry about it ever coming up. I've heard of other special case dates also using invalid months and days, like 88/88/88 and 77/77/77.
The 99 thing is sometimes more of a problem than expected, however. At the beginning of this year, SCCS on our HP-UX 10.20 machines mysteriously started failing. Apparently the HP-UX SCCS tools were using 99 in the year as a special value, even though the SCCS format makes no such specifications. Applying patches fixed this problem.