Tag Info

Hot answers tagged

6

Your notation seems to relate to hybrid encryption. The message is encrypted with a symmetric key KAB; that key was probably generated randomly by the sender. For the recipient to know it, it is necessary to send it along with the message, but not as clear text, of course: KAB is encrypted with the recipient's (Bob's) public key. Thus, Alice does the ...


5

To answer your questions: {K_AB}**K_B_E is prepended to the message so that the receiver has the symmetric key to decrypt the message. Because the key K_B_E is used only Bob can decrypt the symmetric key and only he can therefore read the message. The next is the hash {h} which is encrypted/signed by the key K_A_D. I assume that K_A_D is the private key of ...


4

The resulting secret value (the list of filenames to show the concatenation order) would take up more space than the original file. You'd be better off simply using a one-time pad, and keeping that secret... or even keeping the original file secret directly. Your method would work in most cases, in the sense that anyone who possessed the randomly-named ...


3

Only the last line is the actual message sent. Symmetric encryption is generally much faster and potentially more future proof than asymmetric cryptography. It requires far shorter key lengths for security. Since it is the intent to share the entire message with Bob, Alice doesn't have to encrypt the entire message (long) with Bob's public key. Instead, ...


3

Statistical tests like the one you use cannot detect whether /dev/urandom is good or bad on a specific machine. Specifically, /dev/urandom runs a cryptographically secure PRNG. From a given initial internal state (the "seed"), it produces an arbitrarily long stream of seemingly random bytes. The PRNG being cryptographically secure means that for an attacker ...


3

The AES competition received 15 candidates, two of which suffered from "academic breaks" (weaknesses that are only theoretical, but still demonstrate that the underlying block cipher is not "optimally secure"). The remaining 13 are, to my knowledge, still unbroken to this day. Therefore, the choice of Rijndael had to be done for reasons other than security. ...


2

Considering that Lock-a-folder is no longer supported by its developers, I would definitely say NO, it is not a safe option for securing data. Developer have abandoned this Project and will not reply to any queries. You can use this code at your own risk. Anyone interested in further development of this project can clone or contribute. ...


2

It forces clients who report that they support TLSv1.2 to use it, and causes all other client connections, those who only support a maxium of TLSv1.0 or TLSv1.1, to fail. At this point, unless you know exactly who your clients are and that they do, in fact, support TLSv1.2, (if this is in any enterprise Intranet environment, for instance) I would not ...


2

Theory is that everything works automatically. Practice sometimes differs. I suppose that you are talking about S/MIME and X.509 certificates. With S/MIME, when you send an email: The email is encrypted with the public key of the recipient, so you have to know the current recipient's certificate. The email is signed with your private key and the signature ...


2

Only through code review and testing. Changes in iterations may indeed make those areas of the code more resilient to brute-forcing, but iterations are only a part of the overall architecture that needs to be considered.


2

In the perspecive of online-attacker, then FDE is nothing. FDE is designed to protect against a offline attacker who copies your drive or steals your computer. Once the FDE is "unlocked", it will be accessible, regardless of if the computer OS is locked (Win+L) or whatever. The only thing that can protect against online attacker is good security in the form ...


2

As long as the key is converted back into the binary format before use, the bit-dilution caused by the base-64 encoding will be undone. However, if you're passing keys around an application be careful of how you do it. Wipe text buffers, minimize transits between methods and applications, etc.


2

If you have messages to send, and you use an asymmetric encryption algorithm, and that algorithm happens to be able to process each message wholesale because the messages are small enough, then indeed you can design the protocol without any recourse to extra symmetric encryption. However this may lose some flexibility, and have a non-trivial performance ...


2

Given the constraints in your question, yes, it can be predicted. For symmetric-key encryption algorithms, the answer is "never". Assuming Moore's Law is valid for the next century (an extremely optimistic assumption -- such a computer would be drawing much of the energy output of the Sun to power itself) and that current computers can test a million keys ...


1

Although you are not explaining what the verification process is, it looks like the .sig file is a digital signature, guaranteeing data integrity, authentication and non-repudiation: it means that, as long as the verification is affermative, anybody knows that the file hasn't been changed by a third party, and that the signer signed the file, with no ...


1

The answer to the first part of your question is the current Gmail spam filters would not be as effective, they could read the header information and block certain sender addresses but they could not read the actual message. Your assumption that all the encrypted spam message bodies would be identical is incorrect, every individuals public key would produce ...


1

Since all decent cryptographic algorithms are defined to operate on sequences of bits or bytes, there are only two possibilities for your "encryption library": either it internally converts character strings back to bytes; or it uses some custom algorithm based on characters. In the first case, the library has a sloppy API; it should not be artificially ...


1

There is no way that a modern encryption library operates on characters. All modern ciphers are defined to operate on bytes (some are defined to operate on bits, but most libraries will assume a byte is the minimum unit of data). If your library accepts character strings then they will be converted to bytes within. Note that e.g. std:string does not have to ...


1

Yes, you can use RSA with a good padding scheme for this. I would recommend OAEP, even if it requires more overhead (up to 130 bytes for SHA-512). No, your private key is safe. The contents of the cryptographic messages is safe as well, even if the plaintext is known (the random padding added before encryption will make sure that you cannot distinguish ...


1

Android 4.1 (API 16), according to this: http://developer.android.com/reference/javax/net/ssl/SSLSocket.html


1

Took a while to wrap my head around the bizarre syntax your lecturer is using, but basically the symmetric key is a "session" key generated per message and not reused. Hence the need to include an encrypted copy of it in the final message. I'm assuming H**K_A_D is Alice encrypting the message digest with her private key.


1

On software encryption vs hardware encryption, read this comparison on Kingston's website, and your choice may be easy, but this is marketing language. I'm quite sure that Open Source software encryption like GPG is more secure. See this question: Is hardware based disk encryption more secure that software based?. The basic question is: from who do you ...


1

You seem to talk about two different things: retrieving mail and encrypting mail. From reading the question I think encryption is not what this is about. So for now I forget about it. When you login to Hotmail or Gmail via your browser, you use your login. It looks like you have more email addresses and possibly popboxes. Now it depends on how you setup ...



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