Decoding AES Internals: A Byte-by-Byte Overview of SubBytes, MixColumns, and the Key Schedule
Welcome to a practical overview of modern public key cryptography. Developed by the team at Newsoftwares.net, this article’s specific purpose is to provide clear, actionable guidance on selecting appropriate RSA key sizes and elliptic curves for current deployments. By focusing on 2025 standards, post-quantum planning, and concrete OpenSSL and SSH commands, we aim to enhance your security, privacy, and convenience when facing technical audits or planning long-term infrastructure. The key benefit is clarity: you’ll know exactly what to pick today while keeping a clear path for the future.
Gap Statement
Most “what key size is safe” overviews still talk like it’s 2015, ignore real 2025 standards, skip post-quantum plans, and never tell you which exact RSA size or curve to click in real tools like OpenSSL, Let’s Encrypt, Cloudflare, AWS ACM, or YubiKeys.
Here is the answer up front so you can move on if you want.
Short Answer
- For new RSA keys, 2048 bit is the minimum, 3072 bit is the long-term default, 4096 bit is niche and heavy.
- For ECDSA, use NIST P-256 or P-384. For EdDSA, use Ed25519 where your stack supports it. These give 128 to 192 bit strength with very small keys.
- For anything that must stay secure beyond about 2035, plan a hybrid setup that combines RSA or ECDSA with NIST’s new post-quantum algorithms like Kyber for key exchange and Dilithium or Falcon for signatures.
If all you need is a safe setting for a server or API in 2025, pick:
- TLS web server: ECDSA P-256 (or Ed25519 if your CA supports it). Keep RSA 2048 for compatibility.
- Code signing: RSA 3072 or ECDSA P-256, depending on platform rules.
- SSH keys: Ed25519 or ECDSA P-256. RSA 3072 only if you need ancient clients.
Key Outcome
By the end, you will be able to:
- Pick an RSA size or elliptic curve that is safe for your real use case in 2025.
- Turn those picks into concrete commands in OpenSSL, SSH, and common CAs.
- Spot weak or outdated keys in your environment and plan a post-quantum-aware refresh.
Our single job here: help you choose and run with safe RSA key sizes and elliptic curves today, while keeping a clear path to post-quantum crypto.
1. Prerequisites and Safety Checklist
Before you touch keys, run through this quick checklist.
1.1. Know Your Environment
Server side: Linux, Windows Server, containers, or a managed platform like Cloudflare or AWS. Client side: browsers, mobile apps, embedded clients. Constraints: FIPS, NIST, eIDAS, regional rules, vendor support lists. NIST’s current guidance for federal PIV cards in 2024 allows: RSA 2048, 3072, or 4096 and ECDSA P-256 and P-384. That is a strong hint for everyone else.
1.2. Have a Backup and Rollback Plan
- Action: Export your existing keys and certificates safely.
- Action: Capture a current copy of web server, VPN, or API gateway configs.
- Action: Test new keys in a staging or shadow environment first.
1.3. Ethics Note
Only scan and replace keys that you own or administer. Do not use “weak key” scanners on networks you do not control.
2. RSA Key Sizes in 2025: What is Actually Safe
2.1. Effective Strength and Time Horizon
Key size is only a proxy for work an attacker needs to break it.
| RSA Size | Approx Symmetric Strength | Notes |
|---|---|---|
| 1024 | 80 bit | Broken for new deployments, kept only as legacy. |
| 2048 | 112 bit | Minimum for new keys, good to roughly 2030. |
| 3072 | 128 bit | Aligned with AES-128, suitable beyond 2030. |
| 4096 | ~150 bit | Higher margin, slower, often overkill. |
NIST’s recent SP 800-78-5 draft, aimed at federal IDs, spells this out clearly: through 2030, RSA 2048, 3072, and 4096 are acceptable, with 3072 and 4096 preferred beyond 2030.
Fast Rule
- New deployments that only need to last up to about 2030: RSA 2048 is fine.
- Anything that might still be trusted later: RSA 3072 is a better baseline.
2.2. Performance Impact
RSA cost scales more than linearly with key size. On real servers: Going from 2048 to 3072 often adds around 20–30 percent CPU cost for signatures. Going from 2048 to 4096 can roughly double the cost of handshakes. For a busy HTTPS site, that can mean more cores or shorter certificate life to keep the same budget. In contrast, elliptic curves achieve similar strength with much smaller keys and faster operations.
3. ECDSA and EdDSA in 2025: Which Curves Are Safe
Elliptic curve signatures have become the default in many modern stacks. NIST curves P-256 and P-384 are widely deployed, with P-256 giving around 128 bit strength and P-384 around 192 bit. Ed25519, based on Curve25519, offers similar 128 bit strength, is fast in software, and avoids some structural concerns attached to older NIST curve generation.
3.1. Recommended Curves
| Purpose | Recommended Curve | Why it is safe in 2025 |
|---|---|---|
| Web TLS certificates | ECDSA P-256, P-384 | Widely supported, NIST backed. |
| SSH keys | Ed25519, ECDSA P-256 | Strong, compact, easy to deploy. |
| Hardware tokens (FIDO2) | P-256, Ed25519 (on some) | Fits token limits, supported by major vendors. |
| Internal APIs and services | P-256 by default, P-384 for high value services | Performance and strength balance. |
Curves to avoid for new work: Obscure or home made curves, old curves with weak parameter generation stories unless a regulator forces them. Safe curves work by design and by long public review, not just by marketing.
4. How Post-Quantum Changes the Picture
Large fault-tolerant quantum computers will break both RSA and ECC with variants of Shor’s algorithm. NIST has already selected and is standardizing new algorithms: Kyber for key exchange, Dilithium, Falcon, and SPHINCS+ for signatures.
You do not need to drop RSA or ECDSA in 2025. What you need is a plan:
- Use strong RSA and ECC now.
- Turn on hybrid modes as your stack supports them.
- Track vendor timelines for pure post-quantum later in the decade.
5. Use-Case Chooser Table
Here is a simple chooser you can skim during a design review.
| Use Case | Time Horizon | Practical Choice in 2025 | PQC Plan |
|---|---|---|---|
| Public TLS website | 1–5 years | ECDSA P-256 cert, RSA 2048 backup | Enable hybrid TLS when available |
| Bank or fintech API | 5–15 years | ECDSA P-256 or P-384, RSA 3072 CA | Track Kyber + Dilithium in vendor roadmap |
| Long-term signed documents | 10–20 years | RSA 3072 or ECDSA P-384 | Add PQ signature or timestamp later |
| Internal microservices | 3–7 years | ECDSA P-256 everywhere | Use service mesh that supports hybrids |
| SSH for fleet admin | 5–10 years | Ed25519 keys, fallback RSA 3072 | Plan rotation when PQ SSH appears |
| Firmware or code signing | 10–20 years | RSA 3072 today, PQ pilot next | Run early PQ code signing pilots |
This is where “geo” meets crypto: banking rules in the EU, federal rules in the US, and telco standards in Asia all point toward the same set of sizes and curves, plus PQ on top.
6. Hands-On: Safe Key Generation Recipes
These are concrete commands and settings you can paste into terminal or config files. Adjust paths and lifetimes for your environment.
6.1. TLS Web Server on Linux with OpenSSL
Goal: Front public site with both RSA and ECDSA certificates so old clients and modern ones are covered.
Step 1: Generate ECDSA P-256 Key
- Command:
openssl ecparam -name prime256v1 -genkey -noout -out site-ecdsa-p256.key - Gotcha: Curve name prime256v1 is the OpenSSL label for NIST P-256. Some guides still use secp256r1, which maps to the same curve in recent builds.
Step 2: Generate RSA 2048 or 3072 Key
- Command:
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out site-rsa3072.key - Gotcha: Do not go below 2048. Many CAs reject 1024 now, and browsers treat them as weak.
Step 3: Create CSRs for Each
- Command:
openssl req -new -key site-ecdsa-p256.key -out site-ecdsa-p256.csr - Command:
openssl req -new -key site-rsa3072.key -out site-rsa3072.csr - Action: Fill in CN or use SANs through your CA portal.
Step 4: Upload CSRs to CA
Pick a CA that supports both RSA and ECDSA chains. Many commercial CAs and services like Cloudflare do this already.
Step 5: Configure Web Server
In nginx style:
ssl_certificate /etc/ssl/certs/site-ecdsa-p256.crt;ssl_certificate_key /etc/ssl/private/site-ecdsa-p256.key;ssl_certificate /etc/ssl/certs/site-rsa3072.crt;ssl_certificate_key /etc/ssl/private/site-rsa3072.key;- Gotcha: Order matters in some versions. Put the ECDSA pair first so modern clients pick it.
6.2. SSH Keys for Admin Access
Step 1: Ed25519 Key on Client
- Command:
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 - Gotcha: The -a flag sets KDF rounds, which slows down brute force on stolen keys.
Step 2: Add to Servers
Action: Append ~/.ssh/id_ed25519.pub to ~/.ssh/authorized_keys on servers.
Step 3: Keep RSA 3072 as Fallback
- Command:
ssh-keygen -t rsa -b 3072 -a 100 -f ~/.ssh/id_rsa3072 - Action: Use only on old gear that cannot handle Ed25519.
6.3. Code Signing Key on Windows
In a FIPS style environment, use a hardware token (HSM, smart card, or USB key) that supports ECDSA P-256 or RSA 3072. Many toolchains and CAs still default to RSA, so a 3072 bit RSA signing key is a safe middle ground aligned with NIST tables.
Gotcha: tools that still default to RSA 1024 or 2048 for signing long-life binaries are now out of step with current guidance; push those vendors to update.
7. How to Verify Your Setup
Once keys and certs are live, confirm they match your plan.
7.1. Check TLS Certificates
- Command:
openssl s_client -connect yoursite.com:443 -servername yoursite.com -showcerts - Verify: Look for lines:
Public-Key: (256 bit)andid-ecPublicKeywithprime256v1for ECDSA, orPublic-Key: (3072 bit)andrsaEncryptionfor RSA. - Gotcha: do not confuse leaf key type with intermediate CA key type. Both matter for security reviews.
7.2. Check SSH Host Keys
- Command:
ssh -v yourserver - Verify: Scan for:
server host key: ecdsa-sha2-nistp256orssh-ed25519. If you still seessh-rsaonly, schedule a host key upgrade.
7.3. Proof-of-Work Bench Table
On a staging box, you can benchmark handshake cost with a tool like wrk or hey while switching between key types and record:
| Setup | Requests per second | CPU at peak | Notes |
|---|---|---|---|
| RSA 2048 only | 10000 | 60 percent | Baseline |
| RSA 3072 only | 8300 | 75 percent | Extra handshake cost |
| ECDSA P-256 only | 11800 | 55 percent | Faster handshakes on modern clients |
Your numbers will differ, but this style of table is what engineers and managers understand quickly, and it usually shows why ECC keys are attractive in 2025.
8. Share Keys and Secrets Safely
RSA and ECDSA are only as strong as your key handling.
8.1. Simple Safe Pattern for a Shared Secret
- Action: Share the encrypted file or signed update link by email or ticket.
- Action: Share the passphrase or one-time decryption key by Signal or another secure messenger, with an expiry.
Never paste private keys into chat tools, docs, or issue trackers. For admin teams, use a dedicated password manager with per-secret access controls and audit logs.
9. Common Errors and Quick Fixes
Here is a symptom to fix table based on real strings you are likely to see.
| Symptom or error text | Likely cause | Fix |
|---|---|---|
| “key size 1024 too small” from CA portal | RSA 1024 request | Regenerate CSR with at least 2048 bit RSA |
| Browser shows “ERR_SSL_KEY_USAGE_INCOMPATIBLE” or similar | Wrong key type for certificate purpose | Ensure key and cert use correct usage flags |
| “unsupported elliptic curve” in TLS handshake logs | Client does not support chosen curve | Keep P-256 as primary curve |
| SSH warns “ssh-rsa key type disabled” | Client disabled old signature algorithm | Add Ed25519 or ECDSA host keys |
| HSM or token refuses to create 4096 bit RSA | Device limit reached | Use 3072 bit RSA or ECC key instead |
| Performance drop after switching everything to RSA 4096 | Too heavy handshakes | Move to ECDSA P-256 and shrink RSA role |
| Security team flags “RSA 2048 not enough for long term signatures” | Long expiry or archive use | Move signing keys to RSA 3072 or ECDSA P-384 |
| PQC pilot fails due to handshake size | No tuning for larger PQ messages | Use hybrid modes and tune MTU and TLS record size |
9.1. Root Causes
Root causes in most environments: Old defaults left in place. Copy-paste from outdated blog posts that still suggest RSA 1024 or “AES + 1024 bit RSA” as a pair. No clear separation between short-term TLS keys and long-term signing keys. Always try non destructive tests first: enable new curves or sizes alongside old ones, then remove the weak ones when monitoring tells you that stragglers are gone.
10. When Not to Use a Given Choice
Do not use RSA 4096 for a busy web frontend unless you have measured and accepted the cost. Do not use obscure curves that only one library implements. Do not pick ECDSA only in an environment where many old clients lack ECC support. Keep an RSA leaf or intermediate to bridge the gap. Do not ship long-life firmware signed only with RSA 2048 if you expect that firmware to run for 15 years in the field.
11. Verdict by Persona
11.1. SaaS Founder with a Busy Web App
- Certificates: ECDSA P-256 primary, RSA 2048 backup.
- Internal services: mutual TLS with ECDSA P-256.
- Plan: ask your CDN or load balancer vendor about hybrid TLS with Kyber over the next two to three years.
11.2. Enterprise Security Architect
- CA: issue RSA 3072 and ECDSA P-256 intermediates.
- TLS: modern cipher suites first, RSA only for legacy.
- Code signing: RSA 3072 tokens today, PoC for Dilithium or Falcon with vendors.
11.3. DevOps Engineer in a Mixed Fleet
- SSH: move everyone to Ed25519, phase out ssh-rsa.
- Config management: store keys in a central vault, not in Git.
- Monitoring: add checks that flag 1024 bit keys or unknown curves.
11.4. Solo Developer Shipping Desktop Apps
- Code signing cert: RSA 3072 from a mainstream CA.
- App updates: signed manifests that you can swap to PQ signatures later without breaking clients.
12. Structured data snippets
You can adapt these blocks for your site.
HowTo: choose a safe key size and curve in 2025
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "How to choose safe RSA key sizes and elliptic curves in 2025",
"description": "Practical steps to pick secure RSA sizes and ECC curves, verify them in tools, and plan a post-quantum migration.",
"totalTime": "PT20M",
"tool": [
"OpenSSL",
"SSH",
"Certificate authority portal"
],
"step": [
{
"@type": "HowToStep",
"name": "Decide your time horizon",
"text": "List which keys are short-lived TLS keys and which are long-lived signing keys. Use 2048-bit RSA for short term TLS and 3072-bit RSA or ECDSA P-384 for long-lived signatures."
},
{
"@type": "HowToStep",
"name": "Generate modern keys",
"text": "Create ECDSA P-256 and RSA 2048 or 3072 keys with OpenSSL or your HSM management tools, following current security guidance."
},
{
"@type": "HowToStep",
"name": "Deploy and test",
"text": "Install the new keys and certificates on your servers, then verify key sizes and curves with OpenSSL, browser tools, and SSH."
},
{
"@type": "HowToStep",
"name": "Plan for post-quantum",
"text": "Track vendor support for hybrid RSA or ECDSA plus Kyber or Dilithium and schedule a migration window before 2030."
}
]
}
</script>
FAQPage and ItemList shells
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": []
}
</script>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "ItemList",
"name": "Safe public key choices in 2025",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "RSA 2048 and 3072",
"description": "Standard RSA key sizes for TLS and signatures through at least 2030."
},
{
"@type": "ListItem",
"position": 2,
"name": "ECDSA P-256 and P-384",
"description": "NIST-recommended curves for high-strength signatures with small keys."
},
{
"@type": "ListItem",
"position": 3,
"name": "Ed25519",
"description": "Modern Edwards-curve signature scheme commonly used for SSH and secure protocols."
},
{
"@type": "ListItem",
"position": 4,
"name": "Post-quantum hybrids",
"description": "Combinations of RSA or ECDSA with NIST-selected post-quantum algorithms for future security."
}
]
}
</script>13. FAQ: RSA Key Sizes, ECDSA, and Curves in 2025
13.1. Is RSA 2048 still safe in 2025?
Yes. RSA 2048 is still considered secure for most short and medium term use, and NIST tables and industry guidance treat it as acceptable through about 2030. For long-life signatures or systems with slow refresh, RSA 3072 is safer.
13.2. Should I jump straight to RSA 4096 for everything?
Usually not. RSA 4096 adds a lot of CPU cost for handshakes and signatures while giving less extra benefit than many people expect. Most experts suggest RSA 3072 plus ECDSA and a post-quantum plan instead of a blanket move to 4096.
13.3. Is ECDSA P-256 enough, or do I need P-384?
P-256 gives around 128 bit strength, comparable to AES-128, and is fine for most cases. P-384 pushes that closer to 192 bit strength and is better for high-value or long-life signatures but also slower. NIST allows both in current guidance.
13.4. Where does Ed25519 fit into this?
Ed25519 is a fast, modern signature scheme on Curve25519. It offers 128 bit strength, great performance, and a clean design and is widely used in SSH, Tor, and secure messaging. It is a strong choice any time your tooling supports it.
13.5. Are NIST curves still trusted after the old controversy stories?
There has been debate around the way some NIST curves were generated. That said, P-256 and P-384 have stood intense public analysis, and NIST regularly reaffirms them in current standards. Many teams pair them with safe curves like Ed25519 to balance assurance and ecosystem support.
13.6. Will RSA and ECDSA be broken by quantum computers?
Yes, large fault-tolerant quantum computers will break both RSA and ECC. That is why NIST is standardizing Kyber, Dilithium, Falcon, and SPHINCS+ and why vendors are testing hybrid modes now. There is still time, but the work must start this decade.
13.7. Should I stop using RSA and move only to ECC?
Not yet. The real world still has a lot of RSA-only clients and systems. A practical plan is to keep RSA 2048 or 3072 support for compatibility while preferring ECDSA or Ed25519 wherever possible and adding PQC hybrids as vendors deliver them.
13.8. How do I explain 2048 vs 3072 RSA to a non-technical stakeholder?
Say that 2048 is today’s standard lock and 3072 is a heavier version that is better for doors you never want to replace. It costs a little more CPU, so you pick it mainly for long-life secrets or high-value systems. Use a short bench table to back that up.
13.9. What is a reasonable plan for a medium-size company in 2025?
Refresh all 1024 bit RSA keys, move TLS to at least RSA 2048 plus ECDSA P-256, use RSA 3072 or ECDSA P-384 for long-term signing keys, and start an inventory of all crypto so you can add PQC in stages.
13.10. What is the biggest mistake people still make with key choices?
They focus only on key size and ignore rotation, storage, and future migration. A 3072 bit RSA key in a shared folder with world read access is weaker in practice than a 2048 bit key guarded by hardware and strong process. Get the key type right, then put most of your attention on how it is handled.
14. Conclusion
The biggest mistake people still make is focusing only on key size and ignoring rotation, storage, and future migration. A 3072 bit RSA key in a shared folder with world read access is weaker in practice than a 2048 bit key guarded by hardware and strong process. Get the key type right, then put most of your attention on how it is handled.