# Tag Info

85

An ASN.1-encoded SSH private key contains the following integers in order: The public modulus $n$ and exponent $e$; The private exponent $d$; The prime factors $p$ and $q$ of $n$; The "reduced" private exponents $d_p=d\bmod(p-1)$ and $d_q=d\bmod(q-1)$; The "CRT coefficient" $q_{\text{inv}}=q^{-1}\bmod p$. The observation that the value of $d$ in such a key ...

71

SSH not using TLS is mostly historical; see for instance this answer (on security.SE). In practice, one could perfectly define a sort-of SSH that would use TLS for the data transport part; but, of course, it would not be compatible with existing SSH servers and clients. From a pure cryptographic point of view, SSH actually has some shortcomings with its ...

56

The public key blob doesn't consist of just the numbers that make up the public key: it begins with a header that says “this is an SSH public key”. The repeated prefix encodes this header. RFC 4254 specifies the encoding of public key in SSH key format. The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e ...

43

If by TLS, you mean specifically the series of protocols that is named "TLS", then the answer to why SSH wasn't designed to use them, is quite simple: they didn't exist when SSH was designed. TLS was released in 1999, SSH in 1995. If you are referring to the whole family of protocols that is now known as TLS but used to be known as SSL, then the answer is ...

27

I'm assuming you mean a base 64 encoded key file, since removing the newlines from a binary file would obviously break things. The RSA standards (e.g. RFC 2459) only define a binary representation for keys. In practice, like OpenPGP keys (RFC 4880), they are often encoded in base 64 using the otherwise obsolete PEM standards (RFC 1421). The PEM printable ...

13

Because the RFC says so. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186-2] using the SHA-1 hash [FIPS-180-2]. It says the same for RSA half a page down. Apparently the signature algorithm is a defined part of the public key method's specification, rather than being negotiated separately ...

12

Only two people can communicate with each other with the chat program. No group conversations. This is fairly limited, but let's admit. The people will be communicating over the internet. So, an insecure channel. OK. The chat program will just handle basic characters, numbers and symbols that are on a standard US keyboard. This is to keep things ...

11

The article is surely wrong. Nowadays, the sole purpose of client-side private key in SSH is to sign messages (as their algorithms are typically ECDSA EdDSA, etc), the server doesn't encrypt the challenge, it almost certainly verifies it with the public key(s) in the authorized_keys file

11

The server sending an encrypted challenge has a few advantages over the signature-based method you described: 1) It is more efficient for the client in the case that authentication is rejected outright. If the server doesn't recognize the client's public key, there's no reason to have the client waste time and energy generating a signature. 2) It is more ...

9

Other advantages of CTR are: easier to decrypt from a certain offset within the ciphertext no randomness requirements for the nonce nonce can be calculated, e.g. be a simple counter nonce can be a message identifier $E = D$: encryption is the same as decryption, which means only encryption or decryption required from the block cipher less logic required ...

8

I did also tried to find a good value for the -a flag, in a MacBook Pro Mid14 (i7), trying to login in to a Debian 8.5, I had this results: -a 1000 Took about ~20s. -a 100 Varies between ~3.5s to ~6s. -a 64 (4x default value) ~3 to ~9s. -a 16 (default) ~2s ~2.5s. In the end I just stick with the default since I'm not a paranoiac and I don't like to wait, ...

7

As far as we know, it is totally infeasible for anyone to create an RSA private key with a public key that has a specific 32 character fingerprint. This remains true if you give the adversary a budget of a few billion dollars; the best approach for an adversary would be to try to break in and steal (or purchase) the private key (and the second best approach ...

7

What is the main difference of the three? Can I use only one of them for everything (e.g. GPG for SSH authentication) GnuPG is an free and open-source implementation of the OpenPGP standard. Symantec PGP is a proprietary implementation of the OpenPGP standard. The OpenPGP standard defines ways to sign and encrypt information (like mail, other documents and ...

6

Both the AES key size and the RSA key size matter, because it's no use adding security beyond the weakest link. Here the weakest link is 2048-bit RSA, which is considered roughly equivalent in security to 100-128-bit symmetric keys (depending on who you ask). So having a password with much more than 100 bits of entropy would be fairly useless. In practice, ...

6

Based on skimming the relevant RFCs, I can't find any outright problems. Key derivation from the password is performed via PBKDF2, and best I can tell, the choice of cipher is left up to the implementation. As long as a good cipher is chosen, a truly random 30-character passphrase consisting of uppercase letters, lowercase letters, and digits should have ...

6

There seems to be an attack on SSH when using CBC: Plaintext Recovery Attacks Against SSH. I have just scanned the paper and they state, that this will not be possible when CTR mode is used. I don't think that en-/decryption parallelization is need or even utilized in SSH. Update: Link to CERT concerning the topic: Vulnerability Note VU#958563 SSH CBC ...

6

I am interpreting your question two ways: (1) "Why doesn't the client generate their own signed message to send to the server?" and (2) "Why doesn't the server send an unencrypted nonce for the client to then sign and send back?" To answer (1), such a scheme would be susceptible to replay attacks. An adversary need only collect one of these signed messages ...

5

It appears that based on your description, the server has a 2048 bit key pair and the clients logging in have 4096 bit key pairs. In this case, do I have the brute force protection of 2048 or 4096 bits? For someone to impersonate one of your users, they would have to break the 4096 bit key. For someone to impersonate the server, they would have to ...

5

Currently, your protocol has a fatal design flaw by only considering an attacker who could manipulate the communication. You mentioned the two security properties confidentiality and integrity and you implicitly expect some kind of deniability by using a OTP and its properties. But your protocol ensures no entity authentication or perfect forward secrecy so ...

5

This has been specified by the standard, steps 4 and 5 of the protocol described in RFC 4253: S generates a random number y (0 < y < q) and computes f = g^y mod p. S receives e. It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), ...

5

Yes OpenSSH's fingerprint is a hash of the publickey, and (except SSHv1 keys aka -t RSA1 which is long broken and should never be used) specifically of the publickey format stored in base64 in (usually) /etc/ssh/ssh_host_${alg}_key.pub which is the wire encoding in the relevant KEX-reply message depending on key type (currently RSA, DSA, ECDSA, ED25519). See ... 5 Slower is better, as slow as you can tolerate. Timing for different -a values, each measured 20 times: -a 16 takes on average 0.24675 (seconds) -a 32 takes on average 0.5862 -a 64 takes on average 1.20625 -a 100 takes on average 1.9618 -a 150 takes on average 2.664 The time is linear, so you can expect a doubling of the -a value to take twice as long. The ... 5 SSH over TLS isn't just an overkill, it's a software bloat / design creep. Both protocols provides confidentiality, integrity, and authenticity guarantees, so using two is redundent. And coding for both of them would increase the size of the software, making it harder to maintain software quality, efficiency, and security. Benefit of SSH SSH is already ... 4 What you have here is indeed a structure called SubjectPublicKeyInfo. It's usually part of an X.509 certificate, but it is often also used separate from a certificate. It's, for instance, the default encoding for RSA public keys in Java and - if I'm not mistaken - OpenSSL. You can view the complete structure here and compare it with the SubjectPublicKeyInfo ... 4 Is there an option/param like when creating RSA keys that may influence the length of the key, or by design will always be 80 (68 removing the ssh-ed25519) characters? No, there can't be any such option. First note that only the last 43 characters of your sample public keys are variable. As this is Base64-encoding, they can at most encode$43\cdot 6=258$... 4 There's a general principle in cryptographic protocols that every message should contain a value that depends on previous messages in the protocol. (This isn't an absolute rule, but it's usually the case.) Otherwise a man-in-the-middle might be able observe multiple runs of the protocol and combine parts of messages from different runs in unexpected ways. I'... 4 However, I couldn't find any information on how that sequence number is validated. What happens if some messages get dropped or corrupted during transit? SSH, similar to TLS, assumes that it is running over a reliable [1] transport protocol (such as TCP). If something goes wrong (e.g. some message is corrupted or dropped), then the system assumes that the ... 3 So, you have several requirements. Multiple parties share ownership of a part of the key. Parties will use human memory to store their parts. The passphrase must be a minimum of 30 characters. The first requirement definitely sounds like a job for Shamir's Secret Sharing algorithm, where you have to bring together at least$m$of$n\$ shares in order to ...

3

The MAC is NOT redundant. As alluded to by Paŭlo Ebermann's comment, the word authentication has a different meaning in the two scenarios you mentioned. In the key exchange phase of SSH, the purpose of authentication is to ensure to both parties that they are indeed talking to the right peer (if using mutual authentication). Typically, the server ...

Only top voted, non community-wiki answers of a minimum length are eligible