# Tag Info

67

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 ...

32

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 ...

11

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 ...

8

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 ...

6

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 ...

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 ...

4

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 ...

4

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 ...

4

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 ...

4

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 ...

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

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), ...

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 ...

3

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 ...

3

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 ...

2

As for the conspiracy theory issue. You should consider that the NSA deemed AES fit to protect National Security Systems and National Security Information. http://www.nsa.gov/ia/programs/suiteb_cryptography/ No one knows if AES will ever be broken apart from the people who actually broke it already so either the NSA believes AES is secure or they know it's ...

2

In the common configuration of SSH, the session keys (and a session ID) will be negotiated using the Diffie-Hellman key exchange, and then authenticated by the server, using its private key to sign all the exchanged data (which is then checked by the client). The public key authentication of the client happens after that, when the actual connection is ...

2

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 ...

2

It is critical to combine both the key exchange and the secure channel, otherwise someone can mount a man-in-the-middle attack. The way we prevent a man-in-the-middle attack is to do a key exchange, to exchange a session key that both endpoints know but no one else (including the man-in-the-middle) can know, and then authenticate both endpoints. You seem ...

2

Your example is missing something: your two calls to the OpenSSL library are entirely entirely independent, but your calls to the mcrypt library reuse an existing handle. CBC has the property that identical plaintext blocks are exceedingly unlikely to encrypt to the same value due to chaining of the previous output into the next input. Your OpenSSL calls ...

2

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, ...

2

I don't think there is a dedicated name for this. If I had to find a word, it would probably be "stateful" or "with explicit state". What you observe is actually the usual case: The user initializes an encryption system with a key, resulting in some state of the system. Then, each time the user wishes to encrypt some data, he has to pass the current state ...

2

Is this approach (deriving a password from a signature) cryptographically sound? Not in general. There are signature algorithms that are completely deterministic and signature algorithms that aren't. With the latter kind you would be unable to reproduce the password later. With a deterministic algorithm, yes, the basic idea of using the signature as a ...

1

Oh, I have found an answer. PEM here is PKCS#1 (RSA) key. Not sure why ssh-keygen used this terminology. And PKCS#8 could be used for Public keys as well since RFC-5958 which obsoletes RFC-5208. A very good article is https://tls.mbed.org/kb/cryptography/asn1-key-structures-in-der-and-pem and this question is also good: ...

1

In ssh-keygen.c of the OpenSSH source code, there is the following call: if (prime_test(in, out, rounds == 0 ? 100 : rounds, generator_wanted, checkpoint, start_lineno, lines_to_process) != 0) ...and a comment for the function prime_test says: * perform a Miller-Rabin primality test Therefore, it does indeed use a ...

1

I think you overlooked some words in section 9: Key re-exchange is performed using whatever encryption was in effect when the exchange was started. Encryption, compression, and MAC methods are not changed before a new SSH_MSG_NEWKEYS is sent after the key exchange (as in the initial key exchange). Note that it is better to keep to the ...

1

In addition to yyyyyyy's answer, there is also probabilistic encryption, in which the encryption process incorporates some randomness. That allows many identical messages with the same key to be encrypted differently; it doesn't necessarily encrypt the same text differently in the same message (it might encrypt $a+a$ as $E(a)+E(a)$), but it does let you send ...

1

How do cryptography in SSH(2) work? This is a very broad question. If you're interested in the details, then read the relevant RFCs that describe the SSH protocol. In particular: RFC 4253 - The Secure Shell (SSH) Transport Protocol RFC 4252 - The Secure Shell (SSH) Authentication Protocol Does key authentication in SSH(2) protect from MitM by ...

1

I am sorry that I can not comment your post, and have to write this as answer... But maybe you want to move this question to security.stackexchange.com. And the security goal of key authentication is that both enities can be sure that the public key of the other person actually does belong to the other person. This should prevents a potential attacker ...

1

Enhancements: @Thomas' answer said …OTP is very weak to a known plaintext attack… I recommend that you still compress your message before sending. There are many options for that, each with varying benefits. related: http://blog.alivate.com.au/improve-security-with-compression/ It doesn't eliminate the plaintext attack risk but does reduce it, ...

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