Hot answers tagged

102

This is a good question. The dedicated page from OpenSSH only says: OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. which is no more detailed than the "inherit weakness" from the announce. I did not find any published explanation about these weaknesses except some ...


38

since it's known that the NSA infiltrated RSA and made their key generation algorithm weaker If you know that, then you know wrong. You are confusing two things which have no relation whatsoever: RSA, the asymmetric cryptographic algorithm. Dual_EC_DRBG, a PRNG algorithm of poor quality and amenable to backdooring. RSA can be used for asymmetric ...


25

DSS is simply a document that describes the signing procedure and specifies certain standards. The original document is FIPS 186 and latest revision in 2013 is FIPS 186-4. DSS is a standard for digital signing. DSA is a cryptographic algorithm that generates keys, signs data, and verifies signatures. DSA, in itself, can use any hash function for its ...


16

What are these files for? These are your host keys uniquely identifying your host. When OpenSSH is started for the first time, it will generate these keypairs. When an SSH client connects to your server, it will advertise that it wants to authenticate the host using a particular algorithm. As several are supported, OpenSSH simply generates one of each type. ...


12

https://bugzilla.mindrot.org/show_bug.cgi?id=1647 has the reasoning behind the restricting DSA keys to 1024 bits, but basically: RFC4253 section 6.6 requires the SHA1 hash (160 bits) for ssh-dss (ie DSA) authentication. FIPS 186-3 section 4.2 requires DSA keys >1024 bits to use a hash stronger than 160 bits. the only way to comply with both is to allow only ...


10

OpenSSH's decision appears to be motivated by some sort of confusion that originates from their own code base; see this answer for an analysis. In SSH, DSA keys are deprecated because the people who get to decide what is supported and what is not (the OpenSSH developers) said so. On a more general basis, there is no newly discovered vulnerability on DSA. ...


9

Traditional implementations of DSA choose a random nonce for each signature operation. This leads to a different signature, even when signing the same data. The problem is not that the signature is different each time, it's your wrong expectation that it should be the same. Check Wikipedia on DSA for details: Signing Generate a random per-message ...


8

"ECDHE" means that the key exchange will use the Diffie-Hellman algorithm (over elliptic curves) with freshly generated DH elements; the last "E" stands for ephemeral. So while DH produces a shared key, it will work with randomly produced values, and nothing in DH will ensure authentication: the client has no way to know whether the DH public key it sees ...


8

To our knowledge, DSA keys of adequate size cannot be broken with existing technology. There are, as usual, details. A DSA key lives in a group which is incarnated by three big integers, called p, q and g. These are called the "DSA parameters" and may be shared between public keys from distinct people; however, Tradition is that everybody has his own ...


8

RSA-2048, ECDSA (on a 256-bit curve), SHA-1, SHA-256 and AES-256 are all "equally" uncrackable in that they are all in the wide category of "we don't know how to break them with existing or foreseeable technology". (SHA-1 resistance to collisions, but not to preimages, is not in that category. That one we know how to break -- it would be quite expensive, ...


6

The problem isn't that these algorithms might have their keys/inputs brute-forced. Given large enough keys and/or input sizes, they almost assuredly won't. The problem is that there exists no crystal ball with which to assert whether or not a particular algorithm will still be considered strong through the next two hundred years of cryptanalysis. We ...


6

Cheap, one-sentence answer: The Digital Signature Algorithm (DSA) is published in the Digital Signature Standard (DSS) by the NIST in FIPS 186. The SSH version 2 standards apparently preferred "DSS", though more recently they've used "DSA" as well. I don't know what the differences are in the definitions of the two terms, which is more correct in a given ...


5

The DSA private key file has a structure to it, it's not simply a random number (or two). Within the PEM encoded data (base64 + delimiters) is a DER encoded ASN.1 binary structure. ASN.1 is a system independent way to encode data (think of it like a "binary XML"). Strictly, only the first two bytes of a DSA key encoded this way are fixed, but for a given ...


5

DSA is not a variant of RSA. If anything, DSA is a variant of the Schnorr signature scheme, modified in order to make signatures shorter, and, more importantly, to make DSA out of reach of the Schnorr patent (which has long expired). DSA itself was promoted by NIST as a US Federal standard because RSA was also covered by a patent at that time (this one has ...


4

No, you're not missing anything. Current processors for desktops and laptops are just ridiculously fast. OpenSSL is a native application that can make most of that. In general CPU speed on laptops is not much of an issue. It can be an issue on embedded devices of course. Or on higher level languages. Or when latency is very important (e.g. authentication of ...


4

I do not observe this behaviour here. I use ssh-agent from the openssh-client package of Ubuntu 12.04, i.e. "OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012". I modified the Python script to select my DSA key instead of my RSA key (did you do the same ?) and I get, as expected, randomized signatures (no need to even restart ssh-agent, two successive ...


3

If there are configuration files for ssh server, they are probably server host keys and you are not able to log in with then anywhere. Only to perform Man in The Middle attack, if you would be able to spoof DNS/DHCP.


3

Trying to brute force either a RSA or DSA key would be a losing proposition, there are far too many possibilities and there are far better attacks known. For properly implemented RSA the best-known attack is factoring the modulus. For properly implemented DSA the best-known attack is solving the discrete log problem. For a given key size the discrete log ...


3

DSA is the Digital Signature Algorithm, and exists next to the RSA Signature and ECDSA (Elliptic Curve DSA) as Digital Signature Standard. Both DSA and RSA are based on public key cryptography, although RSA was rather an asymmetric encryption method. While you can not encrypt using DSA, you can sign using DSA quite fast, although you need longer to verify ...


3

If the site with the instructions is compromised the attacker can replace all instructions. This means that he can specify a different key to use for verification or omit the verification information completely, that he can specify a different URL for download etc. That such a compromise can happen shows the hack of the Linux Mint site in 2016 which was ...


3

Just let the SSHD create some random keys for you. If either of the server software or the protocols reveals to be vulnerable in a way that could leak the private key, that would compromise both SSH and HTTPS. You don't benefit from using the same private key and certificate as SSH doesn't provide public key infrastructure like TLS in browsers. The SSH ...


2

The short answer is no or yes, depending on how you look at it. With RSA, as specified in PKCS#1, the message to sign is first hashed, and the hash value is "converted" into an integer modulo n (where n is the modulus, a part of the RSA key pair). In the old versions of the standard, that conversion is indeed a kind of padding (extra bytes are concatenated ...


2

DSA is a signature algorithm; its keys are not usable for asymmetric encryption. In the OpenPGP format, algorithms for encryption are RSA and El-Gamal. Normally, when you create your keypair, you are actually producing several key pairs: a "master" key, and some "sub-keys" for signing and for encrypting. The master key signs the sub-keys. When you say that ...


2

It's really pretty much irrelevant. Message digests are done using a preimage-resistant hashing algorithm, which means that knowing the hash doesn't help you find anything that hashes to that value faster than brute force. But the attacker could also do the brute-force attack directly on the signature -- with both RSA and DSA, an attacker can see if the ...


2

You need to activate the --expert mode to select arbitrary combinations of algorithms and capabilities (inside given technical limitations, DSA keys will never be able to have signing capability). $ gpg --expert --edit-key [key-id] [snip, key-listing] gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5)...


2

For the hash: Crossdupe https://crypto.stackexchange.com/questions/15051/why-does-openssh-use-only-sha1-for-signing-and-verifying-of-digital-signatures and https://crypto.stackexchange.com/questions/39983/which-hash-function-is-used-for-signatures-ssh-rsa-and-ssh-dss but probably better here. A recent answer there links to https://www.openssh.com/txt/...


2

What's important in this situation is that devices must not share RSA keys with each other -- each device should have its own RSA keys. This way, extracting the key material from one device will not compromise the keys used by any other device. Sharing RSA keys between an SSH server and a web server is unusual, but I don't believe there's any inherent risk ...


1

For DSA, ECDSA using OpenSSL and using different functions and structures than for RSA. It won't work for ed25519 keys, because their operations are implemented in the openSSH itself. But you can again reuse OpenSSH code and check how the sing & verify works there. You would also need to use OpenSSH parser, because the ED25519 keys are stored in the new ...


1

If they are in fact private keys with the corresponding public keys on the server setup for a user for SSH access, then you should be able to SSH presuming that public key access is enabled. If you wish to use the private key directly then you would use the -i parameter to specify this: ssh -i private_key_file root@192.0.2.102 The above assumes you know, ...


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