New answers tagged

0

Usually signature algorithm, (that includes how the message is hashed) is assumed to be known by attacker when we make such analysis. Generally, signature keys are long term keys used many times. If you can perform second pre-image attack on hash function you can forge another message with the given message signature pair without knowing anything about the ...


0

Your SOAP message indicates the algorithm used to encrypt the key was kw-aes128, which uses NIST's AES Key Wrapping algorithm. You'll need to decrypt it using -id-aes128-wrap instead of -aes-128-ctr.


0

You can use OpenSSL rsautil to encrypt the AES key with RSA key. You need to change the RSA key into valid format which OpensSSL can accept. (OpenSSL also supports raw encryption without padding. Use only if you know what you are doing) To encrypt: openssl rsautl -encrypt -inkey pubkey.pem -pubin -in aes.key -out AES.enc.key To decrypt: openssl rsautl -...


1

Generally you'd just use RSA with OAEP padding if you want to encrypt a key. Your question however talks about exchange a key. That could also be performed using RSA-KEM. Note that RSA was often used with TLS to provide key exchange using the RSA_ cipher suites. That RSA key was part of a trusted certificate, so it also performed entity authentication. ...


0

RSA is the signing (not encrypting, despite what the text says) algorithm, and it operates on a hash of the content to be signed. SHA1 is the hashing algorithm (it produces a short, one-way non-reversible version of the full certificate) that is used to produce the string which RSA then signs. If the hash is weak to pre-image attacks - that is, if it is at ...


0

Here's the answer I was looking for myself, and could not find until I experimented with both having and not having a passphrase: When the private key is encrypted, then you have to enter the passphrase every time you need to use it. Then I learned about the "ssh-agent" daemon/service that can cache the credentials once per login. When I went ...


0

The core idea here is that with RSA key transport the client generates a session key, encrypts it for the server using the server's RSA public key, and sends it. If an attacker gets a copy of the server's RSA private key, then they can passively sniff future traffic, decrypt any TLS handshake and extract the session key. With DHE or ECDHE cipher suites, the ...


1

Generally, the integrity wouldn't be impacted. Usually it can't be, really, since the communication was presumably recorded some time ago. However, the symmetric key used for integrity (HMACs or AEAD modes) is exposed, and that could be a meaningful impact in some specific cases. The attacker has a man-in-the-middle position on an ongoing TLS channel, and ...


0

You have proxychains configured to do proxied dns lookups. So, proxychains provided a "fake" ip address for github.com, so that the proxy could look up the ip address. Unfortunately, it reuses these fake ip addresses. You've used the proxy to ssh to other hosts, and it assigned the same fake ip address to github.com that it had previously used ...


Top 50 recent answers are included