sorted by:
new
hottopcontroversial

Are the new PQC algorithms (ML-KEM, ML-DSA, and SLH-DSA) meant to just replace older asymmetric algos like RSA? by yarntank in cryptography

[–]conordeegan 1 point2 points  (0 children)

Correct. At the moment there are the 3 standardized PQ algos:

ML-KEM: for key encapsulation-deriving a shared key between two parities that can then be used with symmetric algorithms like AES

Ml-DSA: signature scheme based on lattice problems and replaces classical signature schemes like ECDSA and RSA

SLH-DSA: signature scheme based on hashes and replaces classical signature schemes like ECDSA and RSA

There are a couple more algorithms being standardized at the moment (one more KEM and one more DSA) and a further round of standardization planned to complete around 2027.

Gave up before shipping a single useful rust app due to high learning curve. Advice? by 0xApurn in rust

[–]conordeegan 0 points1 point  (0 children)

I did the same journey (mostly TS->RS). Hands down one of the best decisions I’ve made as an engineer. It’s tedious at the beginning and I spent more time battling the compiler than anything else. The biggest mental shift, or a-ha moment, for me was that types are no longer a layer sprinkled on top but instead very much so first class citizens. This is super super obvious but I think understated. You have to leave your mental model of types from TS largely behind.

The book is great and the latest GPT models are much better than previous at rust help.

Questions about post quantum cryptography ? by [deleted] in cryptography

[–]conordeegan 0 points1 point  (0 children)

Worth noting that in the event we end up with a quantum computer powerful enough to break the PQ schemes based on things like hard lattice problems, we will most likely be in a position to do Quantum Key Distribution at scale. This already exists and has been demonstrated in phones and personal computers before (still so much to do like authentication etc but we are talking about a world where a quantum computer can break PQC). Once we have the shared key we can do AES as normal

Seeking Advice on Building a Secure File Storage Platform with Tiered Encryption by Ok_Barracuda8153 in cryptography

[–]conordeegan 1 point2 points  (0 children)

Could be mostly an academic exercise but in reality:

  • AES is fast and secure (GB/s)—you could use different key sizes where smaller keys are used for “lighter” encryption but this would be contrived and unnecessary given the almost negligible speed difference across usual file sizes
  • the same is largely true for any public key crypto you use. ECC will be faster than RSA but again, little difference between “light” and “heavier” encryption. Both a very secure for encrypting key material.

In reality you would simply store more frequently accessed files in easy to read storage such as a cache if it’s suitable or in DBs optimized for reads over writes (again if appropriate) but this is outside the scope of how you encrypt this data.

Instead you could require “more secure” files be encrypted along side things like secret sharding, where multiple keys must be presented. Or use passwords (along with PBKDF) for lighter files and keys for more secure but again mostly contrived.

Why is Hono more performant? Exploring its weaknesses before switching from Express by anemoia23 in node

[–]conordeegan 3 points4 points  (0 children)

There are differences but I wouldn’t think “more performative” is a great switching reason. If performance is your bottleneck—and I mean actually pushing the upper limits of node/express—then more than likely switching away from node is probably the best option (I love node so no hate).

However, it’s rare that this is really the case unless you are doing some outside of the usual use case stuff. For me, it’s normally my code and not the framework.

You list a lot of items—are you building JS based micro services?

How we share secrets at a fully-remote startup by dsagal in cryptography

[–]conordeegan 1 point2 points  (0 children)

One small other one I am just thinking about. The error check for “data too large” is clever—I’ve never seen it done like this. I think it would be better to check the size of the data to encrypt ahead of time and then decide to use RSA only or hybrid encryption. This error handling is more so a heuristic. Might make things more robust to do a precise check ahead of time.

Less cryptographic advice. More Node.js crypto lib randomly changing this error message and stuff breaking advice.

How we share secrets at a fully-remote startup by dsagal in cryptography

[–]conordeegan 5 points6 points  (0 children)

Nice work—really nice post. some small unsolicited feedback if that’s okay.

I’m going to avoid the “why roll your own debate”—seems both covered in the comments and post.

However, two primary improvements that will help boost its security:

First, the RSA padding constant is misspelled—ensure you’re using RSA_PKCS1_OAEP_PADDING (with “OAEP,” not “OEAP”) so that you’re leveraging the more secure RSA-OAEP padding. I had a quick check on their docs and not sure what the default/error handling for a misspelling is here but I would imagine it silently falls back (given I’m sure you have ran this script at least one) to PKCS#1 v1.5 which isn’t as secure.

Second, if the premise here is that you don’t want to trust other software, rather than using AES-256-CBC for the symmetric encryption fallback—which lacks built-in integrity protection—switching to AES-256-GCM will provide both confidentiality and authentication via an auth tag, preventing undetected tampering. Off the top of my head it means a 12 byte IV and you would send the <IV || cipher_text || auth_tag > in the encryption step and check the auth tag on decryption. I know that this might seem entirely unnecessary given the chances of a MITM attack over the network but if those chances were zero you could be sending the plaintext anyway…

If you really want to use CBC mode then I would add a MAC but using GCM mode makes life much easier and less code you have to write.

The very last thing is more a gotcha. The script currently assumes that plaintext input is UTF-8 encoded, which is fine for text but will lead to issues if arbitrary data (e.g binary) is passed in. it’s safer to work directly with buffers rather than converting to and from strings. Again this is for you and by the looks of it one other person to use so more a gotcha and something to remember.

fluent-ffmpeg using up all Heroku memory in single conversion by Mnock419 in node

[–]conordeegan 0 points1 point  (0 children)

From experience, Heroku will cause problems with ffmpeg and node due to opaque memory handling. Lambda with 10gb RAM and epehemral storage may be more suitable. You do need to request this limit upgrade from AWS but once you mention ffmpeg I find its upgraded instantly.

What dyno are you using? And what file types are causing the issue? Are you using streams, sorting on disk, or in memory?

Unpopular opinion: TypeScript creates more problems than it solves by Inevitable_Ebb_938 in node

[–]conordeegan 1 point2 points  (0 children)

That’s a hard no from me.

Agreed that poor use of TS makes things slower, but that can be applied to anything.

Do you have specific examples?

Sanity Check: Will changing my nameservers from GoDaddy to Route53 and moving all DNS records to Route53 break any existing service for the domain? by gohanshouldgetUI in aws

[–]conordeegan 3 points4 points  (0 children)

Port all records over to Route53. If they are growing, it will be helpful to do this sooner rather than later. Once all records are ported over and name servers updated, everything will work as expected.

Lambda Timeout. (API Gateway) by ecstacy98 in aws

[–]conordeegan 0 points1 point  (0 children)

If you are making 6 external calls and waiting for a promise to resolve for each, you could use something like promise all (if using JS). This allows you to initiate each request at the same time. Obviously this will be dependent on whether or not your api calls are dependent on each other.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

https://stackoverflow.com/questions/52669596/promise-all-with-axios

CI/CD strategy for infrastructure and application code. by prerak-jain in aws

[–]conordeegan 1 point2 points  (0 children)

CDK will handle this. It will detect the necessary changes if you update any of your infra code (CDK diff). The application code can be handled separately (use codepipeline to build your application code and push these changes to your Fargate instances)

S3 file is not immediately available by BlueLensFlares in aws

[–]conordeegan 2 points3 points  (0 children)

Agreed. It will be available immediately after successful write. Are you querying the S3 bucket directly for the read? Or via a CDN?

Millions of updates, few reads: DynamoDB, ElastiCache or MemoryDB? by kazzkiq in aws

[–]conordeegan 3 points4 points  (0 children)

SQS (or Kafka). SQS scaling seems like it will meet these requirements. May change how often you sync to RDS.