Tag Info

New answers tagged

0

RFC4346: The goals of TLS Protocol, in order of their priority, are as follows: Cryptographic security: TLS should be used to establish a secure connection between two parties. Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters ...


3

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 ...


3

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 ...


0

There are several libraries that allow for authenticated encryption in .NET. Bouncy Castle, mentioned in an earlier answer, is not. Microsoft itself offers an open source library that is quite low-level, just wrapping the CNG APIs that offer authenticated symmetric encryption in Windows, called CLR Security. The CLR Security library is going to be the ...


2

A big reason for knowing outdated ciphers is so you can decrypt older documents that were made before the advent of modern cryptography methods. As a famous example, we have Kryptos, a sculpture by Jim Sanborn that's found outside the CIA offices in Langley. Kryptos has 4 different encrypted texts, 3 of which have been decrypted already, the 4th being one of ...


2

If you're doing reverse engineering, penetration testing, or generally involved in looking at things someone else has built, for some strange reason, folks always try coming up with their "own" encryption schemes, which are either flawed or embarrassing mis-interpretations of old ciphers, or just vanilla implementations of old algorithms. Beyond that, you ...


0

Seems that most agree that regarding maths, Horse method is superior--to what extent seems to be mostly about limitations like how uniform the choices are, or what are these "easy to remember" or "easy to type" phrases. Fair enough, but I'll teach you a magic trick how to make these limitations a "bit" less relevant: Use Horse method as platform for ...


0

You could literally chain the encryption by double-encrypting the file: cat FILE |gpg -er alice@example.com |gpg -er bob@example.com > FILE.alice+bob.gpg.gpg This would require Bob to decrypt FILE.alice+bob.gpg.gpg into FILE.alice+bob.gpg, which then requires Alice to decrypt. Alice won't be able to do anything with the double-encrypted file and Bob ...


0

OpenPGP actually defines (or at least indicates) a way to do so, RFC 4880, 5.2.3.21. Key Flags knows the option flag 0x10: 0x10 - The private component of this key may have been split by a secret-sharing mechanism. To do so, you'd have to split up the key on your own and put things together again. An easy way might be to separate "physical" ...


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 ...


0

Try this site . You can upload a file and then they can provide a private key that could decrypt it https://www.fireeye.com/blog/executive-perspective/2014/08/your-locker-of-information-for-cryptolocker-decryption.html


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) ...


2

What matters is entropy. What makes a PRNG cryptographically secure is the inability of attackers to predict the next bytes. Precisely, there are three "security levels" that define the security, in the following model: The attacker is given s bits of consecutive output from the PRNG. The attacker's computing abilities are limited to 2k elementary ...


2

What should be the size of the seed that I initialize a CSPRNG with? Seed Length and other requirements for approved block cipher algorithms are summarized here: How often should I reseed it? The seed is secure as long as it remains unknown to the attacker. I think I can not explain better than this answer. CSPNRG entropy is calculated using ...


0

AFAIK there is no such functionality. If you need such two level of password database, you should merely just use two databases. As mentioned by Neil Smithline in his comment, your second database may be on a separate partition protected by deniable encryption. However, be conscious that deniable encryption proved to be often counter-productive. Initially ...


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 ...


1

I agree with abligh. Undertaking "Homebrew_Crypto(AES(plaintext))" will likely not add a great deal to the security of the system -- but what it WILL do -- even against a state-level attacker -- is simply slow them down. (It will slow down unsophisticated attackers a lot; for No Such Agencies it will force them to use a few more cycles of supercomputer ...


1

There are several usable Broadcast Encryption(BE) schemes. The most popular of them is the Subset Difference(SD) scheme by Naor-Naor-Lotspiech(NNL) that was proposed back in 2001. Here is a link to the full version of the paper describing the scheme: http://eccc.hpi-web.de/report/2002/043/. It was suggested for use by the AACS standard for digital rights ...


0

There is another reason why this might help. Rather than doing AES(Homebrew(Plaintext)), let's assume you do Homebrew(AES(Plaintext)). Let's also assume the worst case, and though you think you are crypto genius, your Homebrew algorithm is no more useful than ROT-13. In this case, today you have a combined scheme which is no worse than AES alone (save that ...


2

There are several improvements that can be made to the functions you've given, based on my knowledge. Obvious threats First, and most important, keep your private key secure, and make it external to the function definition (e.g., a second argument). I would recommend spending significant effort solving this problem. Is this per-user encryption, or ...


-1

Standard encryption that is proven to be good Unknown algorithm "just in case" that even in case of leaking will not provide much to attacker unless they know how to break AES Except you now have TWO standards to maintain, and a weakness in any ONE of them will weaken the second, because two ciphers in tandem effectively produce a third cipher which is ...


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 ...


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 ...


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 ...


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 ...


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 ...


1

In the case of a know ciphertext attack (the most likely one) the attacker would have access to the cipher text. He can make any number of copies of the cipher text now and run his bruteforce attack with multiple keys in parallel if he so chooses to. In fact when specifically speaking of Block Ciphers (in symmetric encryption) the block cipher itself does ...


-4

NO it is not possible to guess a randomly generated bit, with 100% accuracy, you will be right on average half of the time. Edit: I agree I'm wrong, I read the question as only owning one of the programs. If you own both, each will be correct half of the time, thus on average always.


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 ...


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 ...


1

The required information are information about the owner of the domain and have nothing to do with the location of the server. This is similar to the registrant in DNS. This means if you own the domain as an individual there is no organization.


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 ...


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 ...


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 ...


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 ...


-4

Since this is information warfare, I wonder if scenarios with "cheating" are allowed. There may be a system level artifact which the programs can check after the random number is generated or one of the programs could hook into that process, monitor it. The requirements say the programs are isolated from each other, but are not necessarily on separate ...


-4

You are correct. The closest you could get would be a 75% chance of at least one of them being correct, with both computers always guessing the negation of the other.


1

For Shamir's secret sharing, the only possible method for validating a share is rebuilding the shared secret with enough shares, and see if the result makes sense. There cannot be any other method that does not involve sufficiently many shares to reach the threshold, because that would contradict information theoretic security of the scheme (basically, if ...


1

Of the top of my head: One raw RSA message can be at most as long as the modulus. One cooked RSA message needs padding to be secure. RSA PKCS#1.5 padding needs (at least) 11 bytes of padding. And I'm going to assume rsa2048. 2048 bits is 256 bytes raw. Minus 11 for the padding gives 245 byte useable. The CryptoPP site gives: RSA 2048 Signature 6.05 ...


0

I'd say most of your arguments are valid. Typically certs used for signing have different key usage, for example "non repudiation". Many legal requirements (in various countries for example in EU) exists for digital signatures, if they shall be valid in court etc. These requirements do no exist on authentication certificates. All what you state as ...


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 ...


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 ...


1

Knowing the timestamp would help an attacker only if it affects any of the other token parts. If your IV is dependent on the timestamp, then you've failed already. Getting the entropy of the IV from something that is not dependent of the time it was created is the best way to solve this. On a higher level knowing the creation time of a token could help the ...


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 ...


1

RC2 is a currently "unbroken" block cipher; the best known attack is a "related-key attack", i.e. something which does not really apply in practice (related-key attacks are about specific properties when the victim uses two distinct keys, that the attacker does not know, but with a difference between them that the attacker knows). RC2 still has some ...


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 ...


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 ...



Top 50 recent answers are included