Tag Info

New answers tagged

4

During the handshake, the client and server send each other "random values", which are sequences of 32 random bytes. The "client random" is part of the ClientHello message, while the "server random" is part of the ServerHello message. In both cases, the first four bytes of the random value encode the current date and time (number of seconds since January ...


1

TLS as a protocol does not depend on a the system time. The only point where the system time is used is in the Random field of the Client Hello and Server Hello handshake messages. From RFC 5246 (TLS 1.2): Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements ...


0

So basically, the server will generate a key-pair for each user that signs up. It will give the user the private key, and keep the public key to encrypt anything that it receives for the user. When information is sent to the server (in plaintext) for the user to obtain, the server will encrypt the data with the public key, and when the information is ...


1

Before I give my answer, lets first go over the subject of HMAC. Hash-based message authentication code (or HMAC) is a mechanism for calculating a message authentication code involving a hash function in combination with a secret key. This can be used to verify the integrity and authenticity of a a message. Now HMAC authentication guarantees the ...


1

The one-time pad sounds pretty much exactly what you are doing. It would look something like this: Generate a string of random numbers (base-10 or hex) large enough to encrypt your entire plaintext. Convert your entire plaintext into base-10 or hex. You can do simple digit to digit subtraction (no carry) to encrypt your plaintext. To reverse it, you would ...


6

3DES is a fine block cipher. The best known attack has academic cost 2112, which is way beyond the technologically feasible. The main issue with 3DES is that it works on too small blocks (8 bytes, instead of 16 like AES), but that is not necessarily a problem in a specific situation. 3DES is still an encryption system, so if it is used as MAC then this must ...


2

The exact answer depends on the nature of the data you handle and how you go about it. 3DES has been considered weak for some years now: machine have existed for several years that can break a single DES encryption in about a day. Still, in the current state of affairs as publicly known, the best attack against 3DES (using keying option 1 which means 3 ...


0

In my opinion, it is not so safe. 3 rounds with 56b key gives us algorithm strength equal to 192b, but when we consider "Meet in the middle" attack strength decreases to 112b.


0

According to http://en.wikipedia.org/wiki/Triple_DES it's probably more than acceptable. You can always choose something else if you feel the level of security is not acceptable.


11

There have been some discussions about mitigating issues with some record splitting. Namely, what makes Poodle efficient is that padding may use up to a full block (8 bytes with 3DES or RC2, 16 bytes with AES). When this happens, only the last byte of the block is checked by the recipient, which is why the alteration from the attacker gets through with ...


8

SSLv3 protocol is flawed. This cannot be fixed. Generally, an attacker would exploit this by forcing the victim to connect to a server using SSLv3 by forcing connections using higher protocols to fail. TLS_FALLBACK_SCSV attempts to stop the browser/server from falling all the way back to SSLv3 if a higher protocol has already been tried. As you can ...


0

If you want a "safe" solution, one where Windows does not offer to format the disk when you try to mount it, you need to use a format that is recognized by Windows. You could install Ext4 drivers on Windows, but this will only work for those machines with these drivers installed. You could use FAT32 or NTFS for the disk, and use Encfs or Truecrypt or ...


1

Be careful, you should not confuse keys used for encryption/decryption and keys used for signature, since there usage is different. So the key couple A-pub/A-priv is used for signature only, while the key couple B-pub/B-priv is used for encryption only. Be also careful that you should sign the ciphertext and not the plaintext, otherwise having the hash of ...


1

I don't think you understood what Windows did when it formatted the disk. When you plugged in the external drive, Windows couldn't read the filesystem (because it's encrypted) it therefore assumed the drive had no filesystem and offered to format the drive. You selected yes. Windows then deleted everything on the drive and overwrote it with a clean NTFS ...


3

I'm not aware of any specific and popularly reviewed encryption systems. While you may be able to roll something more specific, I recommend using common ciphers to achieve your needs: Use a password based key derivation function (e.g. Scrypt) to derive a key from a random number. Use a common encryption cipher such as AES, Blowfish, etc to encrypt the ...


2

Probably somebody is calling you with voIP phones... you can make it seem as if you are calling from any number or even make it appear as is "xxx bank" or whatever. So no biggies on that part. It is very popular nowadays to call people from voIP systems with fake caller info. On your second question, being called from only known people... Look for a ...


1

If you always receive the calls from the very same person, then it might be a trojan on THEIR phone that calls you. However, if theres calls from multiple persons, then it might be the thing that people call "pocket calls", basically, the phone sits in pocket along with keys, wallets, and other objects that push buttons and/or touch touchscreen which in ...


1

Another option is to look at truecrypt's successors, like Veracrypt (https://veracrypt.codeplex.com/). They use Truecrypt as a base but claim to add some additional security improvements. Of course since they're new it still remains to be seen whether these projects will be able to support themselves in the long term and whether they'll remain secure, so ...


0

If you do decide to use asymmetric crypto alone, you must include some randomness in each message. If you don't: Suppose an eavesdropper captures a military communication and he knows the message will be one of two things: Attack from the East Attack from the West Although he can't decrypt the message, he knows the public key, so he can try encrypting ...


3

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


1

You can use dm-crypt drives, which have windows support as documented here: http://superuser.com/questions/584883/how-can-i-access-volumes-encrypted-with-luks-dm-crypt-from-windows


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


0

An algorithm is considered secure if it is resistant to every known algorithmic attack. An implementation of an algorithm is considered secure if it correctly implements the algorithm, and additionally is resistant to side-channel attacks. In short, a "secure" algorithm is one where the fastest attack is brute force.


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


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.


0

By principle (whether you are encrypting the disks with LUCKS or whatever), once you type in your passphrase the disks are decrypted and your security will no only depend on the security of your network.


0

To decrypt your data the person would need to compromise your system. If the person who compromised your system managed to run a keylogger or another program with admin rights on your system he could preform a memory(ram) dump and extract encryption keys from your computer. Keylogging your system or preforming a memory dump would lead to decryption of your ...


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


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


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


4

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


0

You are correct in that contacts may receive a "certificate expired", if they attempt to encrypt an email to you first and attempt to use the expired, cached certificate (this doesn't apply to signed-only emails). Their email client may allow them to proceed if they persist. Additionally, there's a small chance that the certificate chain may have changed ...


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


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


-1

Right from the project maintainer ... (credit to this thread) VeraCrypt not only enhances security over the original TrueCrypt through an increased iterations count, but it also solves all the serious security issues and weaknesses discovered so far in the source code. A good list of these weaknesses can be found in the ...


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.


1

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


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


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


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

So if I have your goals correct - you want to protect user data and you want their data to be recoverable if they lose their login password. The basics: There is stuff you know; stuff they know; and stuff you both know. Preferably for encryption of their data on your system to really make any sense, it needs to be protected by something you don't know - at ...


0

There are essentially only two real versions of the SSH protocol, SSH-1 and SSH-2. SSH-1 SSHv1 had several iterations. Each iteration fixed certain security issues, but the protocol itself is vulnerable to several attacks. It uses RSA to encrypt 32 bytes of session key. It uses both the server's key and the host key; as in it RSA encrypts the session ...



Top 50 recent answers are included