New answers tagged

1

I think that the other answers are wrong or at best impractical. In order to protect data in the database and have it accessible only by user request we can do the following. Upon registration of the user we generate two hashes. Hash A: Our password, bcrypt hash, stored in the DB Hash B: Our encryption key, not the same password hash, not stored anywhere ...


0

Encrypting your files might not stop them from being encrypted once more. However it does stop ransomware from uploading anything useful, rendering at least some of their threats useless.


13

There is two ways this can be "more-or-less" achieved (as the other answers pointed out, there is no 100% safe way, as there is no 100% security in general): Software obfuscation: it relies on the fact that the execution flow of a program is voluntary and artificially made so cumbersome that it becomes very complex to grasp its logic and understand what is ...


8

Your question is essentially the requirement of pretty much every Digital Rights (or Restrictions) Management (DRM) scheme out there. See Are there DRM techniques to effectively prevent pirating? for more information why the answer to your question is ultimately "no". DRM can make it difficult to access information the folks who implemented the scheme don't ...


1

The ability to create software that can hide information from a user without deleting it and without external access to encryption keys is ... well ... subjective. First, yes its possible to hide files/folders from normal users, however, this is very dependent on the technical skill of the user. If a very advanced user is looking ... they are going to find ...


1

There is no absolute way of doing that as the encryption key would be needed for the computer application that uses the file, so someone sufficiently knowledgeable with time to waste on it could theoretically reverse engineer the application and figure out the encryption key or get the file contents. That said, it is not an easy task and would probably stop ...


1

Even though the connection between user agent and servers are secure, the user agent may not be fully protected. Since authorization code flow ensures the user agent is not privy to the tokens, security is improved by reducing exposure of tokens to between servers only.


1

What version of Excel are you using? Since Office 2007, the encryption used in MS Excel is 128 bit AES with at least a 50,000 interation SHA-1 hash. If you use the built-in encryption with a sufficiently hard password you should not have to worry about offline attacks. How to define "sufficiently hard" will probably change slightly every few years, but if ...


0

I will need to explain some things before answering your questions. Okay, so password can be 2 things, by that I mean it can be just Authentication or it can be Authentication with Encryption. Just Authentication: just Authentication means that there is just one wall of defence between files and the user who is trying to access it. Just Authentication ...


0

Another situation if you store your encrypted password file in the cloud is in the rare situation where your cloud provider gets shut down, like https://en.wikipedia.org/wiki/Megaupload did for copyright infringement; some legitimate companies had data on that site in addition to all the illegal movies, etc.


0

If I understand your question rightly then you are mostly right, dealing with OSI layer encryption/decryption usually happens in the upper layers which are session, presentation and application. These layers are most often merged within the actual software logic (they will all be part the same single software), where you will find TLS tunneling right at the ...


-1

Your sha1 password simply becomes the plain password for an eyedropper. What I do is the following: On the database, each password is encrypted with bcrypt and a salt. The salt is "public". When the user log in, the following happens: -> client send username -> server reply with "salt" -> client generate a random nonce -> client send "bcrypt(nonce+bcrypt(...


3

What is the most and least secure way of going about encrypting emails? There is no difference in security: both use the same cryptographic principles, they just use another method of embedding OpenPGP into e-mails. I am looking for security and have no idea which to use, though I do know HTML will not work with PGP Inline but will with PGP/MIME. PGP/...


3

Others have already mentioned that it sounds like you're looking for a digital signature. There's another part of your question that is important: how to actually distribute your public key (which users will use to verify your signature). A few common methods (in no particular order): Meet up in person with whomever you intend to send messages to, and ...


3

What are some reasonable/interesting ideas of ways to address this issue practically? GPG encryption, with steganography to hide the fact that you're using encryption in plain sight. The basic idea you need to avoid mandatory compromise to encryption, is find any data channel that is not blocked and use non-compromised encryption over that data channel. ...


0

You can try to create a SSH tunnel to tunnel HTTPS through it. I guess this post explains how to perform this in an effective way, otherwise you can find a lot of guides on the web explaining how to create a SSH tunnel.


2

First of all, as @WhiteWinterWolf points out, this is a digital signature scheme. Digital signing is specifically for the purpose of making sure that the message is from you, not somebody else, and hasn't been modified since it was signed. Without going into the math, here's how it works: You have a message that you want the world to know came from you You ...


2

As tim wrote, it could help mitigating the effects of password reuse for users in a few cases, but if what you're thinking of is hashing it client side instead of on the server side, this would be a major design flaw. https://en.wikipedia.org/wiki/Pass_the_hash This problem plagues the NTLM authentication, where it's actually even worse than in the common ...


9

I'm assuming that you are talking about additional hashing. So it would look like this: Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database I think you are aware of this, but just to make it explicit: the transfer needs to happen via SSL to defend against eavesdroppers, hashing client-side would be no help against them at all. ...


0

Supposing you had infinite time... Bitlocker by default uses AES-CBC-128, so you could stage a crib attack (aka "known plaintext attack") against some sector containing well known data. NTFS should have several of those. You would need to look for efficiently implemented GPU or ASIC crackers in order to delay as much as possible the heat death of the ...


1

Well you have to brute-force the 48 character recovery key (https://blogs.msdn.microsoft.com/si_team/2006/08/10/bitlocker-recovery-password-details/) As I remember it visually shown when 6 character sub-key is successfully entered so I guess it is possible but if there are tools available I'm unaware of. Good luck


2

When based on a standard, especially those as stringent as FIPS 140-2, you have to go through the following processes (which are time consuming and expensive): Design Testing Certification If you take a look at the NIST Implementation Guide for FIPS PUB 140-2, along with the other documents, you can search for the Level 4 implementation which detail that ...


0

Use a key derivation function (e.g. PBKDF2) to create an encryption key for a cipher (e.g. AES) used to encrypt your password file. It provides protection against brute force attacks (admittedly PBKDF2 isn't the best KDF, but it's widely available). BUT beware of things like the data finding it's way into the page file or in a temp file somewhere.


0

Relying all your security in a single file is dangerous. The file can be easily decrypted even if you use strong passwords. The reason is because the amount of attacks that can be done per second is incredibly high (more if you consider that a copy of the file can be attacked by multiple computers at the same time). As Alexander pointed out, there is ...


4

To add to the excellent answers already here, I'll focus on this point: If I want to securely speak with a mate on the Internet with a program I made specially for this, which only we have. This is problem #1. Somebody else could acquire a copy of your program. Even worse, do it without your knowledge. This is why in cryptography there's a ...


4

Is that a bad method? Yes, this method is bad for many reasons. First, it does not really gain you anything. If you are already using RSA then using your own on top of that does not gain you anything. If you are not using RSA or another publicly accepted encryption ... then rolling your own is a terrible idea. can this be easily encrypted by spying on ...


3

Even though an answer is already accepted, I'm going to add another because I actually believe the exact opposite of the accepted answer. Basically, you are rolling your own obfuscation, and then using RSA encryption on top of that. Is that a bad method? No, but it's pointless. Strong RSA encryption is sufficient without your additional obfuscation. Can ...


11

Is that a bad method? YES. Can this be easily decrypted by spying on the data? YES. How? Standard cryptographic analysis as been done in wars like WW2 and before. Essentially what you got is a variation on the Caesar cipher. Simple statistical analysis will quickly identify your 'letters'. and as soon as that is done, its only a matter of getting ...


6

The IV is a random non-secret value. Its sole purpose is to prevent two similar blocks from yielding the same ciphertext as it could give information away about the structure of the plain text. In general you just generate the IV randomly and concatenate it to the ciphertext. The IV must be of the same length as the block for AES-CBC, which is 128 bits. You ...


2

Yes, this can be broken, but no, I'm not going to do it. Your friend's system is based on the principles of Hebern rotors. Such schemes were first broken in the 1920s. The most famous break of these was the Bombe, used to crack the German Enigma codes in WW II. The Enigma was a three-rotor system and looks quite similar to this algorithm, the principle ...


2

The plain text of first ciphertext is: Encryption is the most effective way to achieve data security. To read an encrypted file, you must have access to a secret key or password that enables you to decrypt it. Unencrypted data is called plain text ; encrypted data is referred to as cipher text. I was able to break this with a simple brute force because ...


3

You should not deploy your own encryption scheme for this, neither share symetric keys with multiple parties. To protect data on transit between each client and the server, you should use TLS to protect those connections. TLS will take care of symetric key agreement and encryption decryption to each client the right way, avoiding many many things you are ...


-1

This thing should be simple. First you need a crypto library like openssl. If there is a registration phase, you could have the clients generate a pair of private/public keys, (DH or RSA, using openssl) then announce the public part on the server, also called client certificate. And that's it. On every new client-server connection, a symmetric key ...


0

Your understanding about AES is correct, it came into PDF in version 1.6 (see section 3.5 of PDF Reference v1.6 for details). PDF 1.6 and 1.7 (and ISO 32000-1) support AES in 128-bit mode. Adobe's ExtensionLevel 3 for PDF 1.7/ISO 32000-1 introduced AES in 256-bit mode but should be avoided because of weaknesses in the password mechanism. Better support was ...


0

You could consider FDE (full disk encryption) of the [ server | SAN | NAS ] that the data is resting on. If it's a Windows server, consider BitLocker: https://technet.microsoft.com/en-us/library/cc732774(v=ws.11).aspx


0

Another problem not mentioned yet: you mentioned the JavaScript is served over plain HTTP. This means that a "man in the middle" (MITM) attack can modify the JavaScript enroute, removing the encryption, or even doing more nefarious things. You CAN do encryption client-side (there are some cases this makes sense) but it CANNOT replace HTTPS, only supplement ...


0

Send the key to the recipient over different channels. Send from different accounts, to different accounts. The recipient's first job is to assemble the pieces. The second job is to replace the key.


1

Your premise is incorrect, but conceptually I think the problem you're alluding to has been solved by server based password managers using password based key derivation functions (e.g. PBKDF2). Reason your premise isn't right is that symmetric encryption and decryption (e.g. AES) is fast even in JavaScript. These days the cost is low especially when many ...


1

So in building the private key for rsa it will use ssh_host_rsa_key, username, MAC Address, and /dev/random as a seed for my local private key for the user." No. It is not true. The private key is generated only based some bytes from /dev/random, which are formed into the private key inside OpenSSL. Host keys are not used, because normal user who ...


7

Let me try to sum up what the landscape of end-to-end encrypted messaging protocols for group chat looks like: Protocols like PGP have been around for some time and offer "group messaging" by simply encrypting the content with a randomly generated symmetric key and then encrypting that key asymmetrically with the public keys of each of the recipients. ...


0

I need to pass some data securely What do you mean exactly by "securely", do you mean that: You do not want the user to be able to read the content of the protected data (ie. you want to ensure the data confidentiality), You do not want the user to be able to tamper or forge the data (ie. you want to ensure the data integrity)? By simply encrypting the ...


3

Update in response to your edits in the question You are correct that validating a cert up to the trusted root is not 100% foolproof. What it guarantees that a trusted CA issued this cert to the domain that you are communicating with (because you can check that the URL in the cert matches the URL that you are establishing the SSL connection with). This was ...


5

WhatsApp will re-encrypt the message with the new credentials bound to the same number and re-send it. WhatsApp protects from passive interception, but it does not protect against a man-in-the-middle or someone who hijacks the phone network. Sad, really. Ref: How WhatsApp Needs to Improve Its Encryption ss7 attack leaves whatsapp and telegram encryption ...


0

Given that you say this is not a real application, I'll only comment on a couple of points here. The first is an implementation detail that you might have already considered, the second is more of a theoretical "is this worth while?" question. 1. Password changes. It is generally considered good practice to require users to change their password every so ...


0

Using bad, untestable encryption to send secret messages isn't the only risk of this scheme. Like any other computer program, at one level your key becomes an algorithm that tells someone else how to compute it. Even if you were able to come up with an algorithm as good as AES (sorry, you're not), you would need a language to express it so you could share ...


1

It is not a viable encryption method for the technically inclined. 1) All parties that you will give the ciphertext to will need to know the encrypt/decrypt steps. This already ensures that it's not just you who knows the algorithm. 2) You will not be doing this by hand. You will need to turn your algorithm into a software product, that will be distributed ...


8

The flaw in your thinking is here: You have just taken an input, turned it into gibberish in a certain way that only you know how to reverse... Compare that to using a tried and true strong encryption with a long decryption key that only you know what it is. It's possible that your algorithm is equally as secure as the tried and true algorithm, but it ...


3

The algorithm in your example is basically a really simple Caesar Cipher with a fixed key (1), and no, that's definitely not secure. An attacker could determine what algorithm you used rather easily just by analyzing the ciphertext. Other schemes you might come up with could very well have similar vulnerabilities which would let a cryptanalyst reverse ...


1

In theory, it is possible as a sealing operation needs a Storage Key, and a SRK is a Storage Key. In pratice, it is not implemented as usually the SRK is given the WKS(Well-known-Secret = 20 bytes of 0x0) or an empty password, so concerning the security dimension, it is not a good idea. EDIT: I just checked in TrouSerS, tpm_sealdata creates a key ...


-2

The question: Why would you even use a one-time pad if the key distribution is 100% secure? Why not simply send the plain-text message since you are sure that distribution is 100% secure? This assumes that at the time of the key distribution there is information to be sent which may not be the case. Other answers given here have addressed this point. ...



Top 50 recent answers are included