New answers tagged

0

For the plaintext/ciphertext version, place the ciphertext pairs in the boxes corresponding to their plaintext counterparts. This will let you reconstruct the table. a|b|c|d|e | | | |y f|g|h|i|jk | |g| | l|m|n|o|p | | | | gy==he q|r|s|t|u | | | | v|w|x|y|z | | | | a|b|c|d|e | | | |y f|g|h|i|jk | |g| | l|m|n|o|p m| | | | mm==ll ...


1

Serval other softwares using AES 256 encryption support any key length such as a 10char insted of the 16. how is that possible (such as winzip's aes encryption)? the same way the other way. how can the encryption depend on the key strength when the key has to be 16 chars what i was thinking was if the passharse was less than 16 then fill the remaining ...


1

A point not previously mentioned: Double encryption. I.e, you first encrypt your message with your favorite secure non-backdoor method, then send the message encrypted again using the government-sanctioned escrow system. This will look no different than using the escrow system to encrypt plaintext, so as far as the government is concerned, you are an ...


0

Yes, it is internally being done by the doFinal method. According to the Javadoc for Cipher class: doFinal(byte[] input) If an AEAD mode such as GCM/CCM is being used, the authentication tag is appended in the case of encryption, or verified in the case of decryption. So, you don't have to explicitly append/verify the auth tag during the ...


6

Either you give the public key to Bob when you physically meet him and mutually verify identities (as at a key-signing party), or Bob verifies your public key through a trusted introducer (e.g. a Certification Authority) This is the "Infrastructure" part of PKI.


4

Assuming all of the above is feasible, what problems can arise from this system? No one has yet mentioned one of the biggest problem with key escrow systems and backdoored crypto, so I will. User adoption. No one is actually going to use a system that allows an unauthorized 3rd party to decrypt their traffic. It's been tried. The Clipper chip was a ...


5

Some disclaimer-like thingy. Others have made very good points which were partly repetitions of the ones others made before and I don't want to repeat them. So I'm just going to add a little extra which happens to be too long for a comment. Also, I realize that this answer doesn't included a whole lot of technical details. That's simply because the ...


1

I'm not extremely familiar with this topic, but it seems like the "tamper-proof" database could actually hinder this scheme. Once the key arrives, it is stored in an offline, airgapped database that can only be accessed in a single room with rigourous safety. In addition, the database and the machine it is located have tamper protection, similar to ...


15

I think that a word combo "Safe Backdoor" needs medical attention ;) There's NO "GOOD NGO" and NO UNCORRUPTED GOVERNMENTS - Ed Snowden proved it in depth and in full. The answer to this question is an old Apple's official statement, that said : "it's technically impossible to create a key that will work only in a hands of good guys and in a rightful ...


13

When a legitimate law enforcement organization has need of a key to decrypt, it sends a formal request to the NGO. The NGO first analyzes the request based on the importance of the request. the NGO allows decryption when the suspect is strongly incriminated by other evidence, and only in the case of terrorism, murder or abuse of a minor (which are ...


3

Assuming all of the above is feasible, what problems can arise from this system? The problems that arise from the system that others have described all lead back to a single thing. The definition of "safe backdoor" has never been given. Both in your question and in the current discussions that are on-going in the United States and other nations, the ...


55

In addition to the points mentioned by Lucas Kauffman I would elaborate on point two: 2.This algorithm generates one extra unique decryption key when used. This key is then sent via a secure channel (i.e. HTTPS or equivalent) to an NGO with the sole duty of guarding these keys. As soon as the tool gets confirmation that it is delivered, the tool ...


33

Would an encryption scheme that generates an extra key to be securely stored offsite be a safe backdoor? No. Simply no. A backdoor is never considered safe. What you are describing is commonly known as a key escrow. Note that there have been issues with key escrows: On a national level, this is controversial in many countries due to ...


6

They are standards for encryption of mails, notable S/MIME and PGP. There is defined how the encrypted message gets encapsulated so that the mail client knows that it is encrypted. These encapsulations have a very specific Content-Type headers or at least specific markers in the content, i.e. markers like -----BEGIN PGP MESSAGE----- or Content-Type's ...


4

Encrypted data should have a relatively uniform distribution of randomness, so if notable portions of it fed through tests such as a chi-squared test don't end up showing as random, then it's unlikely it's encrypted. Since you have multiple messages, close attention to the first bytes of each message is also relevant because it'll give a chance to detect a ...


3

Take a look at this technical white paper from WhatsApp, they recently moved to the Signal Protocol for e2e encryption. Public Key Types Identity Key Pair – A long-term Curve25519 key pair, generated at install time. Signed Pre Key – A medium-term Curve25519 key pair, generated at install time, signed by the Identity Key, and rotated on a periodic timed ...


1

For encrypting data, it's generally recommended to store a random key and encrypt this with the appropriately salted password. This means that if/when the user changes their password, you only need to decrypt and re-encrypt their key, and not all their data.


4

Do not use SHA256 to hash passwords. SHA256 is a message digest algorithm. It is designed to be very fast. Use an algorithm which is intentionally designed to be slow and hard to implement in specialized hardware. Why? Because fast algorithms allow an attacker to brute-force a large number of passwords until they found one which works. "They'll still have to ...


1

I assume that you're only worried about the ISP of the computer you're physically sitting in front of as obviously the ISP of the server you're RDPing to "sees" everything you're doing from there. The ISP on your client only sees a connection to you RDP-Server and he can easily find out that you're using RDP. However, since RDP is encrypted, it's very ...


2

You can wait until the syndicate finishes their reign of terror and releases the key. For example, all the keys for TeslaDecrypt are now available, so ALL versions can be decrypted now without having to pay. I just recovered some files for a friend who kept his encrypted files from when he was attacked, and can now decrypt them all. ESET Releases Decryptor ...


1

Well, the clue is in the name "Remote Desktop" ;-) The answer depends on the security configuration of your Windows Remote Desktop, but basically its as secure as any encryption you have configured and the implementation of that encryption. However you may wish to think about the security implications of leaving Windoes Remote Desktop exposed to the ...


0

Ok, so you're doing a one time pad - but it's actually a multi-time pad because the key is finite (< 100kb) and derived from a passphrase. Breaking (aka cryptanalysing) this would be fun! Here's some things I would start with: You say the key is derived from a passphrase. You don't tell us how in your question, but if I had access to your binary then I ...


1

Yes. It is relatively trivial to break this cipher without the key or passphrase being sent, given enough intercepted traffic.


4

Well if you're really really really serious about the security of your keys then there's only one answer. HSM Encrypt your data at rest using a symmetric algorithm and encrypt the keys used for the symmetric algorithm using asymmetric keys, the private key for which is stored in the HSM. HSMs are carefully and purposefully designed so that once on them, ...


2

Your problem is less about places to put things, and more about whom to trust. No matter what, the password is going to be stored somewhere that someone has access to. You have to trust that person or persons. The most logical choice is to limit access to just the environment where the code runs. That means a limited set of system-admins. These people ...


3

it depends, but - generally - no. AES is a block cipher, so you're breaknig a thing by 256 bit blocks in your case. And 100KB is more than enough to guess a type of "what's inside", by MIME, for example, after that a task is a way more simplier


1

It is a bad idea to generate the key for asymmetric cryptography totally on predictable data (i.e. user chosen password) instead of secure random data. By basing the key completely on predictable data the key gets the same predictability as the password used as input. Still, asymmetric cryptography can be used for authentication/login but not in the way you ...


1

In its plain form, CBC-MAC is vulnerable to "length extension attack", where you just add some blocks at the end. So in order to stop people from doing that, you need to somehow mark the final block as indeed the final block. And not treat it like any other block. Wikipedia lists two ways: either prefix with block count, or encrypt final block with ...


2

I wouldn't do this and don't understand what problem you are trying to solve (unless this is a purely academic question). Encrypt-then-MAC where we define ciphertext=encrypt(K_enc, msg) and sending ciphertext||MAC(K_mac, ciphertext) will detect any transmission errors or malicious tampering by someone who doesn't know the secret MAC key K_mac with ...


1

This will not harm the encryption, but it doesn't really add anything either. What you've described is just encryption. You've only changed what the payload is by making it a little bit larger. This is just as safe. However a mac also contains a check in it that if it was mangled in transmission in either part(encrypted message or the mac) it wouldn't ...


1

If you believe Apple, FaceTime traffic is end-to-end encrypted using AES-256. This is secure, in the sense that somebody intercepting the traffic can not decrypt it (as far as is publicly known). However, crypto is hard and the security could be compromised if Apple has made an implementation error. I.e. because of a programming bug the traffic may not get ...


2

You are reinventing the wheel. I don't think the state of art really warrants creating a new app from scratch (OTOH if you want to do so for other reasons, like practising creating an app, then go for it). Note that with secure encryption, the third-party server wouldn't be able to snoop on the conversations (albeit it would be able to record metadata). And ...


2

There is a reason for encrypting the data where its stored - that being the storage may be compromised (directly or from a backup copy). If we agree that maintaining the data in an encrypted form is a good idea, then access to the decryption key must be restricted. You didn't specify if the encryption was symmetric or asymmetric. In the case of the former, ...


1

Since the communication between web and app servers are secured through SSL/TLS, the data's already being encrypted in transit by the session key - so I think your two options are very similar. There might be a slight advantage for encrypting for the application server's HSM key right off the bat so that the data's plaintext is never on the application ...


5

Yes, like all block ciphers, DES is a PRP. That is a Pseudo Random Permutation. A permutation is a reordering of all possible input values. In the case of DES there are 2^64 possible input values as the block size of DES is 64 bits. If you have a key and DES in encrypt or decrypt modus then the key will indicate a reordering of all 2^64 possible values. In ...


0

There are some annoying realities about storing anything on a public cloud. The only safe way to decrypt/encrypt anything is on the local client itself, and all the issues of handling private keys locally - phone theft, key theft, etc. Using the public cloud means you have to trust that, on a multi tenant system, the other tenants are not able to scrape in ...


4

As @schroeder recommended, you should share the key between applications/servers using Public Key Infrastructure (PKI). It's not recommended that you implement this yourself. There is a great article called Choosing the Right Cryptography Library for Your PHP Project. This is worth taking a look at. It recommends the following libraries: Halite Libsodium ...


1

I can answer your first question. It's not recommended to use the same RSA key pair for signing and encryption. The reason for that may be differences in expiration or key-escrow (e.g. sometimes organizations will want to back up your encryption key (confidentiality), but you do not want them to have your signing key(non-repudiation)). There's also a long ...


0

If GOST would be used in a chain of several algorithms, i.e. AES-TWOFISH-GOST, would there be a risk of weakening AES and/or TWOFISH assuming GOST had known vulnerabilities like the one described earlier? Assuming that the keys for each of the encryption operations are secure random numbers that are chosen independently from each other, then a flaw in ...


0

Generally speaking, storing that information in the DB, encrypted is the better choice. Is there any reason you are not doing this? I would be less worried about an attacker trying to attack the Laptop via a leaked Local IP since most laptops don't allow incoming connections, I would be more concerned about a person clicking a link which compromises the ...


0

I think the reason for the downvotes is that the result of a file encryption is a new file. Consider this example: openssl enc -aes-256-cbc -in $HOME/somefile -out someEncryptedFile.enc In a command line, this would tell openssl to encrypt somefile and output someEncryptedFile.enc. You can choose the name for your output file however you want. I ...


6

Probably the best low-impact solution is to use multiple disks. OSX supports it already. You could keep a regular disk plugged in, and use the second disk on a weekly basis (keeping it unplugged and in a safe location). If your backup gets compromised you only risk losing a week's worth of work. Also, keep your backups encrypted!


0

In contrast to Polynomial's suggestion, I don't like exporting to DropBox or Email, since most end users use 3rd party applications that have access to the entire datastore using linked apps. DropBox in particular makes it too easy for an app to gain full access to the entire storage (keys and everything). I am presently leaning towards iCloud, where no ...


0

Some good answers here. But what might make this all simpler is to just say that the encryption is linked to the current account that you are logged into when you encrypted. Try creating a new account on that machine. (even an admin account) Log into the new account and now look at the file (in place, without moving it off the system). You can't read it now ...


0

The actual meaning of that is how many bits will constitute the desired key to proceed with the encryption or decryption algorithms. Suppose the key size is 256 bits meaning that, if you take an integer which is grater than the 2^255 and lower than 2^256. In between the integer you have to take it as a public or private key.


0

To play MITM with HTTPS, your ISP would need to create fake server certificates on the fly for the domains you visit. Your browser would flag these certificates as security probems, since they would not be signed by any trusted CA. That is, unless you imported the CA certificate used by the ISP as a trusted CA. In that case your browser will think everything ...


5

Effectively they can see everything you do that's not encrypted or sent through a tunnel and in many cases they can see what type of traffic that is too via DNS. I'll list a few examples: What sites you frequent. When you're active on-line. What operating systems you use and in many cases what software you use. How often you patch your computer. The ...


8

The first rule of crypto is do not roll your own crypto. You are trying to come up with a new solution to an old problem where established best practices already existst. That is a bad idea, since even if you are a security professional as a human you are likely to make mistakes, and your untested solution will go through much less review than already ...


0

You don't really describe this step very well: If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database. Exactly how is that 128-bit key created? That should be a very ...


9

Key size was reduced to 56 bits because IBM wanted to fit LUCIFER on a single chip. LUCIFER then became DES. Because of the promising results produced by the LUCIFER project, IBM embarked on an effort to develop a marketable commercial encryption product that ideally could be implemented on a single chip. The effort was headed by Walter Tuchman ...



Top 50 recent answers are included