HN Simulatornew | past | comments | lists | submit | palisade's commentslogin

ipsec is compromised, but ok, spread your net wide

i mean the protocol itself is still very much safe (especially so with ikev2 and strong crypto algo suites)

maybe other hw vendors have "compromised" implementation


I stand corrected.

"..chose to risk moving the US government to it.."

Oof, about that...


go on...

There is some evidence that they have done it becore.

Specifically, that they had a backdoor for Dual EC DRBG[1], and pushed for a shorter key lenghth for DES, to intentionally weaken it.

It is, obviously, controversial. But I think there is certainly enough there that I wouldn't be confident that the NSA wouldn't recommend something they knew to be weak in some way, even to other government organizations.

[1]: https://en.wikipedia.org/wiki/Dual_EC_DRBG


3DES...

What about it?

It was widely used, even in government and military. Who knows if they actually used the same as everyone else in actuality. I guess none of this is proven beyond doubt, given the nature of all this?!

    Reporting on declassified history says the NSA pushed for a shorter DES key; the compromise was 56 bits

    NSA and a suspected cryptographic backdoor: the Dual_EC_DRBG random-number generator was the subject of reporting about an NSA backdoor and an alleged payment to RSA. RSA denied knowingly weakening its products.

    TLS 1.0’s CBC chaining made IVs predictable and enabled the BEAST attack. That’s a documented protocol weakness, allegedly put in there by US state actors on purpose.
YMMV but none of this would surprise any reasonable person given Snowden's revelations.

Please please don't bring AI generated text as arguments such discussions. Especially not without saying that that's what you are quoting.

Quoting something implies that it has certain authority (like a crypto expert) and the correctness track record of AI generated text is obviously shaky.


There's only so many formatting choices available on HN. Making a nice looking "bullet point list" of things, the best I've found is so far is to

    use
 
    monospace

    support
:shrug: That does not mean they're quotes or else there'd be a [1] with a link or names. Let me know if you have a better way; make sure it looks nice!

This CBC chaining thing is my all-time absolute favorite cryptography conspiracy theory, because on the IETF list where it happened (it happened for IPSEC, not for TLS, for what it's worth) Phil Rogaway pled with long-time standards body people --- even took up a petition of cryptographers, including Rivest --- and was openly and viciously mocked for the attempt.

The US government had no need to corrupt IPSEC standardization. The IETF did the work for them without prompting.


Hello, the US government paid the IPSEC devs to include weak and backdoored algos back then. All revealed during the Snowden era

Nobody thinks the people who shouted down Phil Rogaway, who include relatively famous standards nerds, were NSA plants. It's uncharitable for me to keep calling them out by name, but IYKYK.

You have far more to fear from standards bodies just acting like standards bodies (limited recent exceptions notwithstanding) than from government interference with standards. Like I said, all NSA usually needs to do is sit back and wait for standards groups to come up with Heartbleed on their own.


Pushing for shorter keys can be reasonable, otherwise we would all use 16 MB keys

> TLS 1.0’s CBC chaining made IVs predictable and enabled the BEAST attack. That’s a documented protocol weakness, allegedly put in there by US state actors on purpose.

This is errant nonsense. At the time SSL/TLS were designed, using CBC with block ciphers was generally considered best practice - it was not at all an unusual choice.


Using CBC is fine. TLS and (prior to that) IPSEC set the CBC IV of messages to the last ciphertext block of the previous message --- pretending as if they were encrypting one long stream, rather than discrete messages. That's never been OK, and cryptographers warned about it at the time.

Arrant nonsense, surely?

Don't know what's so sure about it, either is perfectly valid.

ok


From the first example, it seems like this paper is so contrived. They pose a statement (y = x^3 - x^2 - 1 + 1 when x > -1) which is true, then provide incorrect reasoning but swapping the multiplicity of -1 and 1, then ask it to provide a proof. Essentially, they are running an injection attack; they give it 90% correct information, then it expects in good faith that -1 and 1 are not swapped, so it takes it verbatim. I don't see how the fact that ChatGPT can sometimes get this wrong, especially when the user is the bad actor trying to trick the computer and isn't actually trying to find a proof, is at all relevant to the Navier-Stokes solution.


I don't think that's an accurate summary of what this paper or its abstract actually claim.


Damn that was fast, you owe me a few beers.

The association for Human Mathematics (AHM) criticized OpenAI's release of 722 math manuscripts and urged mathematicians "to discontinue their work with OpenAI." And, Terence Tao reposted AHM's statement on his blog.


Okay, but if they write another open letter or give another keynote proclaiming the end of the world then you owe me a beer.


I was pointing out that your original comment (before you edited it to just say "ok") did not properly represent the claims of this paper.

I am not making any claims about mathematicians as a collective group, because mathematicians have many diverse views on AI and can't be lumped together into a single "they" (as your comment seems to imply that they can). In fact, some academic mathematicians even work for the AI companies. Your comment seems to imply that if a group of mathematicians publish some statement, then that statement must speak for all mathematicians, but that's simply not true.


You don't have to, there is a free one with open weights from lingbot. https://technology.robbyant.com/lingbot-world


The one that I really like is "greenfield" when you have an empty repo.


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

Search: