So I’m trying to start a Matlab WebApp Server with authentication. I have an SSL digital certificate (a .crt file) and a key (.key). But when I give the matlab server config the path to the certificate and the key, it won’t start (it works otherwise).
This is the error I get in the log:
std::exception::what: The input data corresponds to a key of size 4096 instead of the expected size 2048
When I check the .crt file it says this:
Does this mean that I need a new certificate which has a 2048 bit key, since Matlab server doesn’t support it?
I have no idea what I’m doing here - I’m using Matlab for science, and this networking stuff is beyond me. Help me!
I believe you’ll need to re-generate the certificate signing request (CSR) with a 2048 bit key and re-submit to the CA for issuing.
Normally cert issuance goes like this:
machine you want to the cert on generates a CSR/key pair - private key never leaves the machine
CSR submitted to CA
CA approves and issues the cert
cert installed on original machine
if the CSR/key is the wrong size you’ll need to start over.
I think.
I gather you’re trying to re-use a cert obtained for something else. well, looks like your app is incompatible with the cert you have been issued.
If you just generated that cert… bigger keys aren’t always appropriate. 2048 is standard for an end machine, 4096 typically only used for root CA servers at the moment. Re-generate your CSR for 2048 bit
I see, I see. This is most illuminating. I lack the basic terminology, so your short explanation is very useful.
It seems our IT department made a mistake when they got the CSR/key. Why would they ask for a 4096 bit key though? Would they have to specifically ask for it? Most puzzling.
To be fair, they had no way of knowing that the Matlab WebApp Server was incompatible with a 4096 bit key. I just find it strange that Matlab doesn’t say this anywhere in the documentation.
Still, thanks a lot for this. I’ll update on the situation as it develops - although I find it unlikely anyone will find themselves in my situation…
I know less than you. My knowledge of cryptography doesn’t extend beyond Caesar cipher. (which, mind you, is excellent when you want to confuse your DnD players)
There’s a lot to learn and many people in the industry as paid professionals don’t know much about PKI/cryptography either, so don’t feel too bad about it.
RSA-1024 is considered broken because botnets and large organizations can factor it. It takes 2^80 operations to do that (large integer multiplications or divisions).
So if a core is running at gigahertz per second (2^30), and 2 weeks has about a million seconds (2^20) then you need about a billion (2^30) cores for two weeks to crack RSA-1024.
So like 200k GPUs or some other custom silicon… or just wait for longer.
RSA-2048 is interesting because of quantum computing. To factor numbers that large you need a 2048 qubit quantum computer (largest one today has 53 cubits), or you need some other advance/breakthrough to happen in number theory. All quantum computers so far have a 2d lattice/matrix, currently 53 qubit computer has a 7*6 lattice with 3 wonky qubits. So, a working 50x50 lattice/matrix would do it.
Some people are not comfortable with that, they believe 10years worth of safety from script kiddies and large commercial entities is worth going with RSA-4096.
Google uses RSA-16384 for signing/checking firmwares on Chromebooks with the idea that if NSA or SSSI or 3PLA had scientist enslaved somewhere building quantum computers and developing algorithms in secret for a decade or two, that such information would leak or ripple out in time to replace Chromebooks using RSA-16384 in their EC (embedded controller) with something stronger. (would need a few months head start at replacing stuff)
I suspect this is for internal, not-over-the-internet connectivity between a client and an app server.
2048 bits will be plenty. And even if it could be factored for an affordable cost by a non-nation state actor, they’d need to be on the local network to get to it anyway is my bet so…
