HN user

honzaik

92 karma
Posts0
Comments32
View on HN
No posts found.

Location: Prague, Czechia (CET)

Remote: Yes

Willing to relocate: Open

Technologies: cryptography (post-quantum, provable security, applied cryptography, security protocols, elliptic curves), PKI, Rust, Java, PHP, Python, Sage, C++, SQL, SAML, AdES

CV: https://files.honza.phd/resume.pdf

Email: joupicky@gmail.com

Security researcher specializing in post-quantum cryptography and applied protocol security. Experienced in designing and evaluating real-world migration strategies for cryptographic infrastructure (PKI, TLS, SAML), with contributions to open-source libraries and standards-related validation efforts.

I am finishing my PhD in cryptography in a month. The focus of my PhD work was to develop a migration plan to post-quantum cryptography for a Qualified Trust Service Provider in Luxembourg.

ChatGPT Images 2.0 3 months ago

I was just wondering about that. Did they embrace it as a “signature look”? it cant be accidental, right?

I am aware that google will take looong time to act. that is why I mentioned that it is LinkedIn (Microsoft) or its contracted fingerprinting/"monitoring" partner who may have more direct ways to report this if they actually investigate malicious extensions.

but that doesn't really matter. for the sake of the argument assume the extensions are not malicious (as evidenced e.g. by the PQC one with ?16 users?) does that change the situation?

well if they have evidence why they dont report it? why are these extensions on the store? im sure linkedin has enough motion to report it directly to google

also, having a PQC enabled extension doesnt seem like a good "large user base capture" tactic.

the source code is as usual obfuscated react but that doesnt mean its malicious...

EDIT: i debuged the extension quickly and it doesnt seem to do anything malicious. it only sends https://pqc-extension.vercel.app/?hostname=[domain] request to this backend to which it has permissions. it doesnt seem to exfiltrate anything else. it might get triggered later but it has very limited permissions anyway so it doesnt seem to be a malicious extension. (but im no expert)

1) yes, everything is affected, but everything else is being migrated to PQC as we speak

2) "256-bit encryption" has different meanings in different contexts. "256-bit security" generally refers to cryptosystem for which an attack takes roughly 2^256 operations. this is true for AES-256 (symmetric encryption) assuming classical adversaries. this is not true for elliptic curve-based algorithms even though the standard curves are "256-bit curves", but that refers to the size of the group and consequently to the size of the private key. the best general attacks use Pollard's rho algorithm which takes roughly 2^128 operations, i.e., 256-bit curves have 128-bit security.

in the context of quantum attackers, AES-256 is still fine although theoretically QCs halve the security; however its not that big of a deal in practice and ultimately AES-128 is still fine, because doing 2^64 "quantum operations" is presumed to be difficult to do in practice due to parallelization issues etc.

the elliptic curve signatures (used in Bitcoin) are attacked using Shor's algorithm where the big deal is that it is asymptotically polynomial (about O(n^3)) meaning that factoring a 256-bit number is only 256^3/4^3 = 262144x more difficult compared to factoring 15. this is a big difference from "standard" exponential complexity where the difficulty increases exponentially by factors of 2^n. (+ lets ignore that elliptic curve signatures dont rely on factoring but the problem is essentially the same because Shor does both because those are hidden subgroup problems)

the analysis is more complex but most of it is essentially in that paper and explains it nicely.

this comment feels so eerie as I am currently reading Zuboff's "The Age of Surveillance Capitalism," which itself is interesting to read now since its written before the huge AI leap.

Also, it reminded me of the following quote, mentioned in the book, from Langdon Winner

The changes and disruptions that an evolving technology repeatedly caused in modern life were accepted as given or inevitable simply because no one bothered to ask whether there were other possibilities.

afaik the "right kind of code" does a lot of heavy lifting for practical implementations, such as Classical McEliece.

correct me if I am wrong as I havent spent much time looking into it, but the security analysis essentially says "we assume the Goppa code is indistinguishable from a random code so the best attack is to do generic decoding for a random code (NP-hard problem)". but there is no reduction to some NP-hard problem that Goppa code (the specific code used in Classical McEliece) is indistinguishable.

the assumption is reasonable as nobody has been able to find a distinguisher for decades. also, if a distinguisher exists, it also doesn't translate into a direct attack against the system, it just means you cannot rule out "structural attacks" and jump to NP-hard problem.

i am no C programmer, but doesnt the first pseudocode make no sense (and others after since they reuse it)?

  address = X
  length = *X
  address = address + 1
  while length > 0 {
    address = address + 1
    print *address
  }
1) length is never updated so while is infinite loop (if length is not 0)

2) the first character is never output since at address 0 (assuming X=0 at the start) is the value length but then the pointer is incremented twice so the first print *address prints the character at address 2?

if I am mistaken I'd be happy if someone explained why it makes sense

I watched the TC interview with Durov (Telegram) and apart from it being a big Telegram ad what struck me is that he told a story about his employee being approached by "an intelligence agency" and asked to reveal information about what open-source libraries they use.

It is kind of strange since their apps are supposed to be open source, maybe he meant the backend? Nonetheless, it seems this has been their modus operandi for a long time.

These solutions are not perfect and typically stop working after a certain time because they patch it/unintentionally break it.

The only reliable solution I found is to VPN to some non-western country where they typically don't have advertisers. Of course, this brings a load of other issues :`).

I mean it highly depends on the CPU so I only posted it to show the relative slowdown compared to ECDSA. I ran this on my free tier Google Cloud server so it is not some super CPU.

However yes, even on this, not so powerful CPU, it doesnt take 500ms so I dont think it explains it.

Another interesting thing regarding the ECC is they use Ed448, compared to something conventional like ECDSA with P-256 or Ed25519, which is way slower (30x-ish slower verification):

(OpenSSL benchmark numbers)

                              sign/s verify/s

   256 bits ecdsa (nistp256)   34642.6 11700.3

                              sign/s verify/s

   456 bits EdDSA (Ed448)   3209.5 409.5
There is basically no incentive to use Ed448 unless you think ECDSA with 256-bit curves is insecure or will become in the near future.

This (and Signal's solution as well) does not protect against active MITM attackers with quantum computers. They would need to incorporate post-quantum signatures into it as well.

The reason why it is missing (but seemingly planned in the future) is because it is not as critical as this change. This change prevents attackers from recording conversations now and decrypting them when (in the next ?? years/decades) they get access to an actually powerful quantum computer. On the other hand, you can do MITM only after you factorized RSA key (or solved discrete log).

The additional reason I presume is that this typically requires a change to the whole public key infrastructure (certificates, OCSP, etc.) which is a lot of additional work.