New answers tagged

1

In its plain form, CBC-MAC is vulnerable to "length extension attack", where you just add some blocks at the end. So in order to stop people from doing that, you need to somehow mark the final block as indeed the final block. And not treat it like any other block. Wikipedia lists two ways: either prefix with block count, or encrypt final block with ...


0

I was able to sign with private key and verify the signature with public key, and I want to share with you. In SignXml() function I exported public key from private key: Dim publicKey as String = tmpRsa.ToXmlString(False) Then in the same function I call verifyXml() function: Dim verifySign As Boolean verifySign = VerifyXml(doc, publicKey) In ...


0

Contacted Peter Todd directly, this is his response: Basically, you guys are quite right to recognise that this isn't timestamping a PGP signature, but rather weakly proving the signature was created after a certain point in time. But that's a rather weak proof, as what exactly prevents you from recreating the signature with a different blockhash? Not ...


2

He can make his own private key derived from public-key of sender. No, he cannot. At least unless the crypto (or implementation thereof) is horrifyingly bad in some way. Public key cryptography as used today is generally based on one of two mathematical problems. For example RSA relies on the difficulty of factoring the product of two large prime ...


0

That depends on what you mean by "really". ‚Äč A computationally-unbounded adversary can break all digital signature schemes, along with most other cryptography too. However, there's not publicly known to be a feasible classical algorithm with a non-negligible probability of finding a compatible private key for an inputted RSA public key, and one can build ...


4

Assuming the cryptographic algorithm is strong and the key used does not have any weakness, the attacker will NOT be able to generate the corresponding private key from a public key. That is the whole point of Public Key Cryptosystems. The attacker would usually be needed to solve a computationally impossible problem in finite time (Factorize a huge number ...


0

The actual meaning of that is how many bits will constitute the desired key to proceed with the encryption or decryption algorithms. Suppose the key size is 256 bits meaning that, if you take an integer which is grater than the 2^255 and lower than 2^256. In between the integer you have to take it as a public or private key.


3

Possibly, sometimes. What's exchanged in the initial handshake is not just a symmetric key, but rather a "master key" for the session from which the client and server implementations of the selected cipher suite can extract keys for various purposes. A cipher suite is split into a number of algorithms for different functionality: Key exhange Bulk ...


0

You cannot sign large data blocks using any of the commonly used asymmetric signature schemes. For signing larger data, you would have to split it in blocks and sign, but if you just do that without nonces/padding/etc, it is very insecure. If you use some high-level library for your signatures, it most likely already hashes the data you give it to sign so ...


3

This is a great question, I'm not 100% sure, but my guess is that it's a proof of age that the PGP key is newer than 2013-10-19. My reasoning is as follows: What makes blockchain mining computationally hard is fiddling with the nonce until the hash of that block has a specific number of leading zeros (16 hex zeros, or 64 binary zeros in this case). Once you ...


4

You have got that wrong, at least the encryption. Asymmetric Encryption is done using public key of the receiver. Therefore it provides Secrecy (nobody without private key can not read the message). But it does not provide Integrity -- anyone can encrypt any message and send it to you with your public key. Wikipedia is a good friend: Digital signature ...


1

For TLS 1.2 the signature should be over the two hello nonces plus the ServerDHParams portion of the ServerKeyExchange message. See rfc5246 section 7.4.3 which shows the input to the digitally-signed construct from section 4.7. But note earlier protocol versions are different for RSA signature. Two hashes, MD5 and SHA1, are concatenated, but are NOT ...


0

First of all, block-type (BT) '00' and '01' is padding for private key operation, i.e. signing. Standards define that 'data' for signature should be hash (DER DigestInfo structure) of the data that is signed. Block-type (BT) '01' padding adds fixed padding data up to the length of the modulus: 00 | 01 | FF .. FF | data Block type (BT) '00' padding means ...


1

I don't believe this would provide any more protection then the normal double submit cookies. If an attacker can overwrite one cookie using an unsecured (https) subdomain, they could just as easily overwrite 2 cookies. The attacker in the senario would get a legitimate token and signed token value, they would embed both of those in the request, and write ...


2

A cryptographic signature can only assert trust on the data it is signing. Unless there's a way to validate the validity of the unsigned fields based on the validity of the signed fields, then no you can't trust the unsigned fields.


1

The problem with naive double submit is that if the attacker could insert an attacker controlled cookie he could also set the CSRF token to this cookie and this way defeat the CSRF protection - because token and cookie match. This can be defeated if the attacker is not able to create a CSRF token and guess the matching verification cookie. This can be ...


0

Well, in the final PKCS12 you should encrypt the private key. The pkcs12 utility allows you to specify how you want to encrypt the private key. -aes128, -aes192, -aes256 use AES to encrypt private keys before outputting. -camellia128, -camellia192, -camellia256 use Camellia to encrypt private keys before outputting. I would consider aes256 very secure ...



Top 50 recent answers are included