Hacker News new | past | comments | ask | show | jobs | submit | hassleblad23's comments login

I wonder at what point would the antivirus kick in. It doesn't require reading /dev/urandom for too long.


This is a game of cat and mouse, like it has always been. Cannot rely on security by obscurity.


This is a highly ignorant response. There is no relying on security by obscurity - that concept doesn't even apply here, because we're not describing the defenders of a system under attack. This is ransomware that has already infected the system that you're supposed to be securing. Failing to realize that if you don't publicize the method of bypassing the weakness in the ransomware then you'll be able to save more victims indicates extreme stupidity and ignorance of the basics of the field.

Moreover, "This is a game of cat and mouse" suggests that it's not valuable for more victims to have their files decrypted, which is somewhere between malicious and insane.


You have to read my comment in context of the immediate parent which I replied to, not the OP.

The immediate parent comment says that if the vulnerability is publicly declared, attackers can easily patch it.

Paraphrasing my response: not publicly declaring the vulnerability is security by obscurity.. which does not work.

Don't attack a strawman.


If this were the case, then the existence of the Enigma machine, and also the existence of those Nazi communications which so kindly provided the daily seed for deciphering the codes, should have been published in the newspapers along the WWII.

I just hope that publishing the ransomware vulnerability was not ego-driven or anything like that, because they burned a period of time in which they could have helped many people.


> they burned a period of time in which they could have helped many people.

They absolutely did. hassleblad23 has absolutely no idea what they're talking about and no experience in the field. It was obviously the wrong move to publish the Akira weakness.


I don't think the Enigma machine example applies here.

The nazi communications were decrypted by a highly centralized and secrative group, making it very difficult for the Nazis to figure out how they were doing it.

But in this case any vulnerability in the ransomware will have to be exploited by many of the affected people to decrypt their files, which means wide distribution, which means that a leak to the ransomware developers will happen sooner than later. If there is no wide distribution of the vulnerability, the ransomware developers win anyway.


> I don't think the Enigma machine example applies here.

It absolutely does. Your claim is "security through obscurity applies when attacking a cryptosystem, so after you figure out how to break it, you should publish the details". By your logic, the Allies absolutely should have published the details of how they broke the Enigma.

> But in this case any vulnerability in the ransomware will have to be exploited by many of the affected people to decrypt their files, which means wide distribution

Yet again, you show your overwhelming ignorance of the field and basic logic. No, the decryption/exploit does not have to be widely distributed. It's extremely easy to realize that the good guys can just keep it tightly-held and provide a service where files are sent to them for decryption.

You should avoid spreading incorrect and harmful anti-information like this.


> Don't attack a strawman.

I'm not. You're just factually wrong.

> not publicly declaring the vulnerability is security by obscurity.. which does not work.

Now I know that you don't know what you're talking about. Anyone either passingly familiar with the field of information security, or capable of using basic logic, knows that this is incorrect in multiple ways.

First, because security by obscurity can increase the security of a system when you combine it with other measures.

Second, because you're using "security by obscurity" as a religious word without the slightest understanding of what it actually means, which is that, when designing a secure system (that is, when playing the role of the defender), relying on security by obscurity alone is bad.

This is not what is happening in the article. In the article, yohanes/TinyHack is playing the role of the attacker - the Akira ransomware has a cryptosystem and they are attacking it. "Security by obscurity" is entirely irrelevant here.

It's extremely obvious to either someone who thinks for a few seconds, or anyone with a basic understanding of the field, that the attackers primarily rely on security through obscurity, and that publicly revealing the vulnerabilities in the defenders' systems that you've discovered is almost always an extremely bad idea.

And that includes this case. Now that yohanes has disclosed the vulnerability in Akira, the authors can immediately patch it, and the upside is virtually non-existent: an educational lesson for someone new to the field, which could have easily been provided in a way that doesn't inhibit our ability to decrypt victims' files. If yohanes had instead kept the vulnerability a secret, they could have disseminated it to a limited number of other cybersecurity experts, and offered to decrypt files as a service, helping victims without revealing the vulnerability in the crypto.

You shouldn't comment if you don't have the slightest idea of what the words you're using actually mean.


Thats a great collection. Thanks for sharing.


Thanks, glad you like it


Strobelight is open source as well.


This is a reason public college should be free.


I have noticed that asking an LLM to output a confidence score and the reason for assigning the confidence score, works really well. These are tangential to the actual task, but still improve the quality.

I wouldn't depend on the numerical value of the confidence score itself though. There is no way for the LLM to caliberate its confidence score wrt. multiple invocations on different data. I have found this metric to be mostly useless.

It works fine as a proxy to induce some thinking though.


Wow. This is such a fascinating insight. Obvious in hindsight but never occurred to me.


This looks pretty cool. Thanks for sharing!


Its a shame because I like the enum way of declaration a lot more.

`const Foo = { Bar: 'bar' } as const` - this just feels a bit weird.


That's a taste thing. Personally, I like my TypeScript as a superset of JS with types, so I dislike all the custom value-space syntax.

`const Foo = { Bar: 'bar' }` is how I would write an enum-like object in JS, so that's how I want to write it in TypeScript, just with added types.


Yes, why do we have "const" at the beginning AND end?


The `as const` at the end will ensure the type of `Foo` is not widened to a `string`.


I don't know JavaScript very well, so I'll take your word for it. Seems like a language flaw to me, though. How many times should you have to say something?


Cant comment on rest of your points, but as someone who has worked on Zapier-like 3rd party integrations a lot, it is much harder than it appears.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: