Tag Info

New answers tagged

0

If you were to really think about it, having multiple sites to host your downloadable content, together with the hash keys would stop most run of the mill replacement attacks. Once again the assumption is the threat model where the attacker would have to replace in situ as opposed to in transit. Even with a single source, the copies would stop anyone from ...


0

Well, ever wonder where the web of trust model came from? Look no further than notaries. In any case, not everyone wants to remember a huge chunk of non comprehensible strings, apply them as rounds in some kind of XOR blocks and be able to compute the ciphertext in the amount of time it takes to do a john hancock.


1

Ok, so you want authenticated transactions, so why not just sign each transaction message together with the time. Use asymmetric encryption - my assumption is symmetric encryption is used by multiple users. Once again it's a toss up between computational power and convenience. So symmetric might be a good idea if you're on a low powered system. Then again, ...


2

A couple of pitfalls with ECC: Invalid curve attacks: Attacker encodes a point which is not on the curve and has low order. Deadly attack on Diffie-Hellman. I don't think this can be exploited with ECDSA since there is no attacker controlled point. Point on twist on a non twist secure curve: Same as above, but works for compressed points as well. Incorrect ...


0

The general situation looks like this: A signature relies on some certificates, that assert the ownership of public keys. Certificates are primarily designed to be validated now (e.g. the certificate's date of validities are compared with the current date). These objects tend to degrade over time. CRL expire (usually rather fast). Certificates expire; when ...


0

Regarding CRLs: CRLs are issued regularly. They don't need -- nor should they have -- long durations between updates. They are regularly reissued. (I just checked Facebooks certificate and they use http://crl3.digicert.com/ca3-g29.crl -- This CRL lists 7 days as the maximum time until the next update.) So you can just sign them with the signature of your ...


1

Signing will be done by the key only, so as long the key is not changed all signatures done by this certificate are still valid. But, when building the trust chain for a certificate it will look at the certificates issuer field and then search for a certificate having this issuer as the subject. Only after it found a certificate (or multiple) having this ...


0

So, how does an Intermmediate CA change one field, without having to reissue every single cert? It does a cross signature with it's old key (--placeholder -- would love to see a great answer on how cross signing works, or I'lll plainly and clearly ask that)


5

Recently, our clients want to encrypt their files for one reason: " They don't want FTP server admin has access to their files". With this requirement the encryption should not be done at the server side. Otherwise an administrator could just grab the content before it gets encrypted. And of course the management of the passwords/keys should also be ...


4

My suggestion is to have your clients manage their owns encryption password or certificates. Certain FTP clients will allow the use of encryption, as an example: http://www.coreftp.com/docs/web1/FTP_Encryption.htm. I want to make sure though that you're actually using some type of encryption for the transit of their data. You don't mention it and since ...


1

Some CAs will not allow two certificates with the same SubjectDN, so the new one would supersede the old one. If there is no reason to believe the previous certificate had its PrKey compromised, it does not need to be revoked prior to signing and installing the replacement. Speak to the operators of your CA, especially the personnel acting as an RA, since ...


1

Is it a must-act-immediately-because-attacks-are-feasible-now? No. That said, when working with PKI, you must have a long vision, so start planning now. It is estimated that by the end of 2017, precomputed hash-collisions to create imposter certificates (and hence imposter CA certificates) may drop below 100,000$ in computation, using cloud computing ...


2

Is this a hot issue for mostly security reasons [...] Not yet. There is no practical published attack yet. But it's in the post. The gradual transition now is better than the transition from the earlier MD5 hashing algorithm to SHA1. Back then there was no explicit deprecation strategy AFAIK and there actually were evil attacks that used ...


0

I'm no expert but I believe to suppliment what user2316037 stated I believe javax.xml.crypto.dsig which allows you to sign and validate an XML digital signature.I believe that is what you are looking to use. Retrieved from: http://www.oracle.com/technetwork/java/javamail/dig-signature-api-140772.html


0

Signing or not? No, you don't need to sign your packets. TLS's MACs will take care of that for you. See: https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity Passwords over the wire? Regarding not wanting to send a password over the wire: you may want to look in to mutually authenticated TLS. This uses certificate/key-pairs on both ends of ...


0

TLS provides both encryption and, in so far as you can trust the certificate authority process, origin integrity. TCP/IP itself provides message integrity in the form of checksums and acknowledgments. That should be plenty for most applications. I hedged a little bit about certificate authorities because there have been valid-but-rogue certificates issued ...


1

Stringify the sent information in a standard way, take the SHA256 hash, sign it with the private half of the key-pair that is genned for the handset when the application is installed (the public half is sent to the server at enrollment time). Most importantly, HMAC is easy to do wrong because it is crypto and crypto is really hard to do right (even Ron ...


2

The .sig file is a detached signature. You use your key to sign a file to certify its authenticity. If the file is changed in any way, the verification process will fail and the party that received the file will know that it has been tampered with after you sent it out. I believe the .asc.sig you received is a certificate of that guy's public key certifying ...


2

The need for a "safe prime" is a piece of old lore that is now obsolete, but is still taught, because of what can only be described as generalized apathy. Historically, the "safe primes" are called "safe" because of Pollard's p-1 factorization algorithm. The core idea of Pollard's algorithm is the following: when we compute things modulo n (n = pq for two ...


0

Salts and secrets serve different purposes when you're creating a MAC. The secret (the key) is used to prevent existential forgeries, or in other words, to prevent an attacker from creating an equally valid MAC on a tampered message. Without the key, you have no integrity, and you've essentially turned the MAC into a hash. So, you need the key. A ...



Top 50 recent answers are included