Tag Info

Hot answers tagged

69

There is actually a solution that will always succeed: Program A will guess the opposite of the value it receives, program B will guess the same value as the one it receives. You can also think of that as such: A guesses that they will receive different numbers; B guesses they receive the same. One of them is bound to be correct. If you look at the ...


37

Well "impossible" is impossible to prove which is why in the linked answer I said "almost impossible", maybe even that is overstating it. By using a secure hardware device the attack vector goes from "malware installed remotely on host steals secret," to "attacker needs to physically gain access to the hardware device and destructively remove the private ...


30

All of the weaknesses in your protocol can be summed up as "use SSL" or even "use SSL, dammit !". In more details: All the protocol is of course vulnerable to impersonation, specifically the double impersonation that is also known as Man-in-the-Middle attack. Similarly, if any of potential attackers that can eavesdrop on the line decides to do a ...


28

Mostly, yes, this is about writing code and remembering not to do anything bad. At its core, the crypto-code writing process really is a combination of understanding and updated knowledge. To write crypto code, you have to fully know how the code you write gets translated into assembly, then machine code, then electric signals; it can help to have some ...


19

Hardware crypto modules like this are regulated by a set of standards called FIPS 140-2 which specify the ridiculous lengths that the devices must go to in order to protect the private keys inside them. There are four levels of FIPS 140-2, briefly summarized as: Level 1: It does basic crypto-y things. Level 2: "Tamper-evident"; it's impossible to extract ...


12

No this protocol isn't safe. As already mentioned in the comments: Don't roll your own crypto. Chances are you're getting it wrong. Especially if you admit that you don't really know what you're doing. First, you seem to have standard problems for which there are already standard protocols, which have nice properties and security proofs. The protocol for ...


11

Kerckhoffs's principle states: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Therefore if AES is broken, your homebrew algorithm is likely to be much easier and would have been broken already. I realise part of your original question stated: provided they do not have the algorithm ...


10

The normal mechanism for a password manager is to have some sort of "master key" and encrypt the data (symmetrically) with that key. The master key, in your case, being derived from the master password through proper password hashing (so it becomes, in this case, password-based key derivation). So use bcrypt or PBKDF2 to turn the user's master password into ...


7

In TLS, neither the client nor server signs any content. The cryptographic signatures that are used in the initial handshake are meant for authentication: the client obtains some guarantee that it talks to the right server, and (if client certificates are used) the server obtains some guarantee that it talks to the right client. However, neither of these ...


6

Looking at OpenVPN's source code, this appears to be a cosmetic quirk of OpenSSL. When using --show-digests, OpenVPN calls OpenSSL's EVP_get_digestbynid() with, as parameter, all integers from 0 to 999. For some of these values, EVP_get_digestbynid() returns a non-NULL pointer that identifies the corresponding hash function implementation, and then OpenVPN ...


5

Generally speaking, in the certificate request, these values do not matter. What matters is what appears in the resulting certificate, and the certificate contents will be chosen by the CA, not by you. The certificate request is a vessel to convey your public key to the CA; that request uses a format (normally PKCS#10) that includes a space of a "subject ...


5

Since this looks like a trick question, here is a trick answer (i.e. it is "cheating"). Let program A do the following: If it receives a 0, then output "1" and exit. Otherwise, loop forever, until a "Ctrl-C" signal is received, in which case the program outputs "0" and exits. Let program B do the following: If it receives a 0, then output "0" and ...


5

Device generates private RSA key, and sends the public key to server. Server generates unique to user AES key and uses the RSA public key to encrypt it and send it back to device. Device gets the AES key. Uses it to encrypt password and username and sends it to the server. Anonymous key exchange. There is no authentication. Your key exchange ...


5

No. Not with the key alone. If you have a known plaintext and a known cipher text then the problem of getting the key from that is known as a "known plaintext attack". And any modern crypto system, including AES, is hardened against this. Several terabytes of plaintext/cipher text pairs will still not allow you to get at the key within reasonable time. ...


4

By itself, your home-brew algorithm is a form of security through obscurity. However, when applied in combination with a known good encryption, your home-brew algorithm may be considered a defense in depth strategy. Quoting directly from Wikipedia, A system may use security through obscurity as a defense in depth measure; while all known security ...


4

From a mathematical point of view: when you cascade two encryption functions f and g in that order (you encrypt with f, then encrypt the output of f with g), then g cannot make the data less confidential than with f alone, provided that an important condition is fulfilled: the secret key used for g must be unrelated to the secret key used for f. It is not ...


4

Are TLS session keys cached in a browser? Yes, sometimes, but not as you're describing. The simplest bottom line answer for you is "Yes, sessions are cached until the browser is closed." That's not absolutely true, or true in all cases, but it's a reasonably secure belief for you to base your actions upon. when authenticating to a TLS protected ...


3

What you presented is not an encryption scheme, you just took a number and modded it by 7. This can not be an encryption scheme because there is more than one "message" which will produce the same "cipher text", for example: the message 22 produces the cipher text 22 % 7 = 1 the message 29 produces the same cipher text 29 % 7 = 1 the message 36 produces ...


3

The CA/Browser Forum Baseline Requirements (PDF) specifies that these fields in the Subject of the certificate should be filled in accordance with the validation of the identity and address of the requestor by the CA. This validation shall be done with a document or information provided by: A government agency in the jurisdiction of the Applicant’s ...


3

You should provide the information of the company (postal address being the HQ's location) or your own information if you're an individual. Truth is, for an automatically-issued DV (domain validation) certificate, nobody is going to check and all you really care for is that the CN (common name) matches the hostname of the server you're getting the ...


3

It does make sense, even if you use ROT13, since you will add a layer of security. AES(HomeBrew(openText)) will always be more secure than AES(openText)... ...unless this algorithm of yours will add some weakness to AES that will make cryptanalysis easier. Which I doubt. But I'd personally stick with known algorithms and use something like ...


3

not exactly answer to your question but : I think the most important of don't run your own crypto isn't that some other people are more competent (even if it is probably true) but mostly that everytime you do something you can make mistakes (being good or not don't change that). A most correct form should be don't run not reviewed crypto. Writing crypto ...


3

In all generality, no, you cannot use such a scheme with a storage based on hashing and still expect the same kind of security as with full-password hashing as it is normally practised. Here is the demonstration: the point of storing the hashed password, and not the plaintext password, is that you just assume that attackers may obtain a (possibly read-only) ...


3

Out of the box with GnuPG/PGP, there is no way to encrypt a file with the method you suggest. There is a "group" encryption or ability to encrypt to multiple recipients, but that allows each recipient to individually decrypt the message rather than rely on anyone else's key. What you can do, and is commonly done, is to split the PGP private key and require ...


2

In a PGP setup, encryption occurs with the recipient's public key. In SSH authentication, this is (internally) a signature with the client's private key. If Alice sends a message to Bob and also connects to Carol's server, then Alice will use Bob's public key to encrypt, and here own private key (from a distinct key pair) to sign. No problem here. A ...


2

Block ciphers like CBC require an input as multiple of the block size. In this case P would need to be padded to be one block long. Another thing to notice is that the first block of P is being XORed with the IV which is also one block long - this will also ensure that you start with an input data of size which is at least one block long. Being a block ...


2

Dieter Vandenbroeck wrote an article on when security through obscurity makes sense: Usually, the principle of security through obscurity is just utterly wrong. The idea behind this principle is to have obscurity in your solution as the principal means of security. Of course, this is not a valid substitute for real security: once your obscurity ...


2

What you are essentially trying to do is build a pseudorandom number generator (with salt + Key0 as the seed) and use the output of it as a key stream to construct a stream cipher. Some comments: Consider that if the first block is all 0, then all subsequent keys can be recovered. This follows from the fact that the first block is XOR-ed with Key1, and ...


2

It could work, and would be security-in-depth instead of security-by-obscurity, but there are a few ways to mess this up catastrophically: Using a HomeBrew algorithm that is vulnerable to side-channel attacks. Now the attacker can do a simple timing or cache analysis, for example, and bypass the AES part entirely. Are you that secure in your ...



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