azet

yea. I don't get why HS1-SIV isn't in the next round.

For the record: I'm not a cryptographer.

:)

I'd usually not even consider replying to such a post as you clearly have neither read nor tried to understand my comment.

I replied to a post made above, and expressed deepest sympathy for the Japanese people. While I was born in central Europe, I'd rather not be a citizen of any nation. I spend more time abroad than in the country I was born in. Speaking of which: central Europe currently has a huge resurgence of facist ideologies and xenophobia due to migrants from war-torn countries. Something which is utterly inconceivable to most people able to read a history book, given Europe's not so distant past with genocide. Unfortunately, xenophobia and right-wing sentiment is something that every democracy and thus nation faces, Japan isn't exempt from that [0] [1] [2].

(I currently live in Asia and spend a lot of time in Arabic countries, you may reconsider educating me on the subject with references to the bboy scene.)

Aaron

[0] https://en.wikipedia.org/wiki/Category:Far-right_politics_in...

[1] https://en.wikipedia.org/wiki/Political_extremism_in_Japan#R...

[2] https://en.wikipedia.org/wiki/Uyoku_dantai

Yea, I always liked Ruby's implicitness and style of writing code. For crypto I'd prefer to use Sage or Python's cryptography.io framework (a lot of other good options for performance critical code of course).

I stopped reading these 'cypherpunk'-epilog lists a few years back. I'm still subscribed because of cross-postings. The amount of tinfoil-hattery is just unsustainable. And there's barely any interesting information for people working on real cryptography-, systems or engineering.

Users of languages can't be expected to. Therefore the language designers and maintainers themselves, especially if they're working on the stdlib, should do so, IMO. It's not only education for a proficient programmer, it helps to understand the underlying system you're building on and it's security assumptions.

The random char device code isn't that hard to understand, and if you're not a strong C programmer (the Ruby-core people are good C programmers, I suppose) - there's a paper explaining how it works: https://eprint.iacr.org/2012/251.pdf

Aaron

I don't think it's a culture thing at all. Japanese people are usually extremely polite and sincere. I also don't think this has anything to do with their history.

If you look at replies I got from Ruby-core: some people would consider them to be rude as well; I'm constantly told I do not understand what I'm doing, and I've been in engineering for more than 12 years, into crypto for more than five (and been reading cypherpunk lists since I was 15). I'm certainly not an academic cryptographer nor among the best engineers in the field, but I think I know a fair bit about the topic by now. I've contributed to many security projects, academic publications and standards processes -- this was certainly among the worst experiences I've had so far (you'd think IETF is worse, no. heated discussions all the time, but people stay focused and technical, listen to comments made by domain experts et cetera and act on them).

The Ruby community even has their own acronym for being nice to other developers: MINASWAN (https://en.wikipedia.org/wiki/Yukihiro_Matsumoto). I'm puzzled by the outcome of this discussion, but am assured by other security engineers and cryptographers that bugs they opened were treated equally badly, often ignored, even if they were non-disclosed, heavy security issues.

No idea. I'm not part of Ruby-core, neither Japanese. In my travels I've encountered many cultures and peoples, Japanese are amongst the most polite and friendly people I've met. Often very shy in that regard, like many asians (this is indeed a culture thing & certainly not a bad one). Some are xenophobic, but I wouldn't say that they all are, that's just false, I've met so many open-minded Japanese that I'd never generalise in that regard.

Aaron

Some of this is certainly my own fault (context: I'm the rude guy in the thread). There were two comments made by myself that were considered "rude": one early on, where I actually didn't even mean to be. And my last reply was bascially a rage-quit.

But I put all relevant information, academic and engineering-wise in the thread to try to convince Ruby-core to change their opinion. I replied to false assumptions and comments as best as I could.

I'm also only a human and since this bug has been open for 2 years, I've used SecureRandom extensively in the past, this was a very frustrating experience for myself and all the commenters involved. I certainly do not have the most "diplomatic" approach (as a friend put it). I know that. But I'm not really sorry about that either, it's just who I am. I'm a nice guy IRL people tell me, but I can get obnoxious when people don't listen to severe security issues and always refer to upstream, have been so in quite a few projects and standards processes.

I'll work on that, promise ;)

Aaron

Short story? No. Adam Langely has extensively written about the subject and difficulties at Google and in Chrome. In chronological order:

https://www.imperialviolet.org/2011/03/18/revocation.html

https://www.imperialviolet.org/2012/02/05/crlsets.html

https://www.imperialviolet.org/2014/04/19/revchecking.html

https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

There hasn't been a lot of progress there but Certificate Transparency is of course a new player that might change how revocation works for different systems as well.

Thanks for working on this! Post is also spot on.

edit: Running a CA is a full-time job that requires financial backing, gear, well-trained operational staff and a lot of policies to operate in a reasonable and safe way. I'm happy that Let's Encrypt take their time to get everything in place and do not rush General Availability, BTW. I could not find /any/ information on SPI's CA on the web. I have no idea who or how they currently operate their CA. Their Website has a horrible and real-world vulnerable HTTPS set-up. I imagine their CA might also have aged a bit.

PoC (not weaponized and ugly code due to lack of time): https://github.com/azet/CVE-2014-3466_PoC

hf.