New answers tagged

2

Timestamping is a special kind of signature already. TS = Sign(Hash(info | X) | time) The renewal is : TS' = Sign(Hash(TS | info) | time) Of course, you could sign the original info with the new certificate and not using this technique. But this sometimes might not be possible or practical. For example when dealing with a contract, you would want to ...


3

This is why Microsoft recommends to never remove expired code signing certs from CRLs. An alternative scenario: attacker signs their malware before cert expiry. If they can remain undiscovered past cert expiry, then the cert won't get added to the CRL even on discovery, and their malware will never get blocked. Thus the revocation status of code signing ...


3

None will protect against a replay attact. In the first case, all the attacker has to do is adjust the timestamp. In the second case, since H() is not supposed to be secret and since the timestamp is known, and attacker can also adjust the request by creating a valid H(timestamp). There is also the problem that you need to synchronize the client and ...


0

The disadvantage would be that the TCP sequence could wrap. This is a risk on very high speed networks. You can randomize the initial timestamp, however, just as you asked. It's a very simple patch, so any rejects will be trivial to fix. It requires the grsecurity patchset to already be applied. From https://grsecurity.net/~spender/random_timestamp.diff: ...



Top 50 recent answers are included