Tag Info

Hot answers tagged

119

Diffie-Hellman is a key exchange protocol but does nothing about authentication. There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, ...


47

Tom has provided a good explanation as to why Diffie-Hellman cannot be safe against man-in-the-middling. Now this answers the OP's original question but probably leaves some readers with the (reasonable) follow-up question: Why don't we just use public-key (asymmetric) cryptography to ensure the confidentiality of our messages, and drop D-H altogether? There ...


17

Your quote describes symmetric key strength, but your counter examples (1024, 2048 bits) reference keys used for asymmetric cryptography. The number of bits required for strength is different between the two. Your quote is from section 7.1 of Applied Cryptography; if you move ahead to section 7.2, for example, you'll see Schneier's predictions on what ...


13

JavaScript cryptography is not a good idea JavaScript cryptography is not bad per se, it's just ineffective against most commonly considered threats. If you consider a man-in-the-middle (MITM) to be a threat then SSL/TLS is a much more effective control as otherwise the attacker could substitute the JavaScript for a version which doesn't use ...


7

There are a few reasons to use larger keys. Your quote only mentions brute-force attacks against symmetric keys. If there is a weakness in the algorithm, then there are faster attacks than brute-force. That is a good reason to design algorithms with some safety margin such that it doesn't get broken as soon as somebody finds a little weakness in the ...


6

Reasonable Defaults for s2k You can tune multiple parameters. The s2k-mode should generally stay on it's default value, 3: this uses both a salt and repeats salt and passphrase during application of the digest function. Further parameters are the symmetric encryption algorithm (s2k-cipher-algo), the digest algorithm (s2k-digest-algo) and (if mode 3 is used) ...


5

The problem is probably not so much algorithmic security. The problem is that if there is a security problem with one of the applications that you also have a security problem the other application. Furthermore, it may be that some kind of attacks on the protocol may be made possible because you share keys. In other words, this is not a good idea with ...


4

I'm going to ignore the horrible usability issue in this answer and just focus on the title question here. -- One idea is to generate a visual fingerprint like OpenSSH visual fingerprint. OpenSSH Visual fingerprints produce blotch of ASCII characters that are supposedly somewhat memorable can be quickly compared visually. If you want to be slightly ...


4

The problem you are asking about is called the Socialist Millionaire problem and has been discussed in research before; as far as I know there is a protocol to do this comparison without disclosing any of the two secrets and without involvement of a third party. I will edit my answer with a full explanation as soon as possible.


4

PBKDF2 is a password hashing function(*); it uses a configurable number of iterations (to make it as slow as is appropriate) and a salt (to deter all kinds of parallelism in attacks). To verify a password, the hash is recomputed, and should yield the same value. To perform this recomputation, you need to use the same number of iterations and the same salt ...


3

There are a few ways to do this. You can come down to the following statement: For authentication you can only use something the user knows, has or is. As you're in a file-encryption scenario, this should rule out most points concerning "what a user is", because they involve biometrical data, which needs to have tolerances. A password or passphrase. ...


3

Key with a strength of 128 bits or higher are currently considered impossible to break. However, that doesn't necessarily mean that the key itself is 128 bit. The key size is related to key strength, but it doesn't even have to be linear with the key strength. Take for instance RSA; you need a 15K bit key to be near 256 bit security. The best way to see how ...


3

SSL/TLS is the encryption layer between browser and server. As long as you have properly configured your SSL/TLS on the server, any additional javascript type encryption is redundant. If you are trying to create a secure application, and your team does not understand what SSL/TLS does, you might want to consider bringing in a security consultant to help ...


3

As far as I do understand, you want to convert an authentication subkey to an SSH key, and authenticate using this. If I generate a PGP subkey that only has the authentication capablity and use this to generate an SSH keypair to authenticate Git for example, does this pose a security threat? Whether this is reasonable or not depends on what you're ...


3

This sounds like the perfect use of an HMAC. You create a secure random secret S. Then the ticket for each page will be ID + HMAC(S, ID). When you get a ticket you extract the ID, redo the HMAC and then compare your result with that in the ticket. While this is likely be simpler and faster than an encryption solution, it will only work if you don't mind ...


3

Why is there des-ede3-cbs in my rsa private key? Because your private key is encrypted with that. As far as I know "DES" is an encryption standard from the seventies and it's considered broken. Yup. Pretty much. Consider reencrypting it with AES like so: $ openssl rsa -in desencryptedprivkey.pem -out aesencryptedprivkey.pem -aes128 EDIT ...


2

There is a trivial answer: decide of a daily password, print it on a pass and you have exactly the system you're describing: a "pattern" that is printed on a physical medium, that can be check by a human being without any extra device or hardware. If you're willing to rfelax requirement a bit, there is a technique called "visual cryptography" that does ...


2

Have you think to use SSL/TLS on server side. So the data will traverse over secured channel. And on server side later you can encrypt ti and store it in such form in the database


2

Basic password hashing with salts only involves the password and a random salt that are joined together before creating the hash. You don't mention that joining process in your explanation and it's important because otherwise the salt doesn't add any security. The example you've linked to is using a more advanced type of password hashing using PBKDF2 which ...


2

In CBC mode, the IV is ALWAYS the same size as the block size used by your encryption algorythm. Thus, if you use AES, your IV will have to be of exactly 128 bits, regardless of the size of the data you have to encrypt. So, the proper way to encrypt your data in CBC mode is to: Divide your data in blocks of the appropriate size (128 bits for AES) bits If ...


2

TL;DR: Generate a data-key pair, encrypt the private part with the public key of all users that have write access, encrypt the public part with the public key of all users that have read access. Let's tackle this one by one: Data must be securely encrypted in the database This is to secure against attackers, and mainly for the users to know ...


2

The generic methodology for this kind of problem is reasoning in terms of knowledge and indirection. You want each user to be able to do some things that other users, or the "tech people", cannot do; therefore, each user must know a secret value that other people do not. The user's password can be such a secret; otherwise, you would need something stored on ...


2

After a DH key exchange, both parties know what key they've computed. If no man-in-the-middle has infiltrated the connection, both parties will have the same key. If the connection has been breached, they will have different keys. If there is a means by which one party can ask the other what key it is using, the man in the middle will only be able to ...


2

Your private key is encrypted with Triple DES. While DES is easily broken, Triple DES is safe for now, especially in this context. AES was made to replace Triple DES not so much because Triple DES was broken, but because it was way too slow. In the context of private key encryption, a non issue.


1

As of today, India does not have any clear and well established laws and policies regarding encryption or encryption techniques to secure electronic communication. The extant laws only prescribe for use of such encryption standards or algorithms which are well established and in conformity with the international standards. As per Rule 5.2(6) of the ...


1

For a cipher each key defines a different permutation, but that doesn't mean that there cannot be identical 1:1 relations. Take AES-256, which maps 2^128 values to another 2^128 values using a 256 bit key and you encrypt one 16 byte plaintext, say all zero's. The output will also have 2^128 values. So there must be keys that map the same plaintext to the ...


1

According to CryptDeriveKey() documentation, upper WORD of dwFlags parameter specifies desired key size in bits. In your case it should generate 40-bit (0x28) keys, effectively discarding all but first five bytes of the MD5 output. To achieve similar behavior with CommonCrypto you can try this: CCCryptorCreate(kCCDecrypt, kCCAlgorithmRC4, 0, ...


1

DH is not generally resistant to Man in the Middle attacks. If Alice and Bob (A<->B) can set up a shared secret. Then Frank can setup a shared secret with Alice (A<->F) At the same time Frank can set up a second (different) shared secret with Bob (F<->B). Frank can then decrypt A-> F messages and re-encrypt and send to bob F-> B & vice versa. ...


1

Apple uses such a mechanism on iCloud. I believe this is how it works (if memory serves me right), and slightly different from what others have suggested. As far as I understand it, it involves only asymmetric encryption. 1) The device (iPhone, iPad etc.) generates a key pair (device key). 2) For a new iCloud account, the device generates a second key pair ...


1

This is an interesting problem but has actually been solved in various open-source applications at this point. I would recommend, for your use case, borrowing from ownCloud's encryption model (which has the benefit of being open-source). The general application of this model on your software would look like: 1) Of course this can be done in many ways, ...



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