Encryption resources / programmers?

[JCBiggs]

Hey folks.  I am trying to put a simple encryption scheme together.   What im trying to do  is send an  end user an encrypted payload (encrypted with Key pair 1) , without them every knowing whats it in.   Once they get possession of it, I want them to then encrypt the  already encrypted data using a different public key (key pair 2) and send that data back to me.  I will then decrypt the sent file first using 'key pair 2,'   then further decrypt using 'keypair 1',  at which point  I will verify the contents of the file, and respond to the end user with either a "yes you have the original package"    or "no its fraudulent"    

its not important that the end user ever know what the package is, just that they have authenticated possession of an original and unique payload..

 

Does anyone have the slightest clue on how i can implement this, or where to go to look for dev's that can.  I want to use standard encryption like SHA256.  

 

Thanks!!!

[zwirek2201]

2 minutes ago, JCBiggs said:

Does anyone have the slightest clue on how i can implement this, or where to go to look for dev's that can.  I want to use standard encryption like SHA256.  

 

Thanks!!!

I believe SHA256 is a hashing algorithm rather than an encryption one meaning if you encrypt something using it, you will never decrypt it (unless using brute force).

 

Rather than trying to encrypt something and then decrypt it, you could hash it (using for example SHA256), store the salt somewhere and when it comes back, hash the original data (using the same salt) and compare hashes. If they're the same, the contents are the same. 

 

User will have no way of decrypting the data so they will not know what's inside.

[JCBiggs]

^^^^ perfect proof that i know zilch about encryption.  

 

ok, so to elaborate on my first post.  the "encrypted data"  is 'known values' (several hundred different ones, that i will refer to as a "packet")  as the very beginning of the trust chain requires it.  The end user will not know exactly  which one they have or be able to find out through brute force or some other means (since its encrypted with a private key using aes or something)  

 

 

so to clarify Im following you correctly:

1) I still have to encrypt it first with my own private key, to permanently protect the data.

2) Then for distribution security,  I must encrypt the packet using the end users public key. (ie not relying on https)

3) Then the end user will decrypt the packet  using his private key, and is left with  the orginal encrypted data.

4) At which point he will run the hashing algorithm 

5) He will get a hash, then encrypt that with my public key for transmittal security,  and send that result back to me for verification.  

 

 

Im stuck at how to verify it.  i dont think this will work because i have to be able to turn that hash back into the original  encrypted payload for verification of the value inside.   which you said is impossible with SHA256. for that to work,  I would have to maintain a list of owners and which packets the have and then run through all they own in order to find one that matches. they also have to send back some kind of identifier along with the hash.    all that sounds like a giant security risk that could undermine the entire process, and not anonymous. 

 

 

 

 

 

man what i thought was simple tuned into like 5 layers of encryption already.  thank god its less than a mb of data. Im already confused. 

 

 

 

 

[leodaniel]

5 hours ago, JCBiggs said:

^^^^ perfect proof that i know zilch about encryption.  

 

ok, so to elaborate on my first post.  the "encrypted data"  is 'known values' (several hundred different ones, that i will refer to as a "packet")  as the very beginning of the trust chain requires it.  The end user will not know exactly  which one they have or be able to find out through brute force or some other means (since its encrypted with a private key using aes or something)  

 

 

so to clarify Im following you correctly:

1) I still have to encrypt it first with my own private key, to permanently protect the data.

2) Then for distribution security,  I must encrypt the packet using the end users public key. (ie not relying on https)

3) Then the end user will decrypt the packet  using his private key, and is left with  the orginal encrypted data.

4) At which point he will run the hashing algorithm 

5) He will get a hash, then encrypt that with my public key for transmittal security,  and send that result back to me for verification.  

 

 

Im stuck at how to verify it.  i dont think this will work because i have to be able to turn that hash back into the original  encrypted payload for verification of the value inside.   which you said is impossible with SHA256. for that to work,  I would have to maintain a list of owners and which packets the have and then run through all they own in order to find one that matches. they also have to send back some kind of identifier along with the hash.    all that sounds like a giant security risk that could undermine the entire process, and not anonymous. 

 

 

 

 

 

man what i thought was simple tuned into like 5 layers of encryption already.  thank god its less than a mb of data. Im already confused. 

 

 

 

 

So first of I want to clarify, I m not a security expert. Tho I can not emphasise enough, that you should use Standart Solutions and not make your "home grown" solution. If you have really critical data, get professional aid. 

 

Against what would you like to protect your data? I don't really get that at all from your post. Transmission?

Cryptography is not easy and can be implemented badly on so many levels.  

 

RSA (Asymmetric, Public and Private key, one used for encryption, one for decryption!)

AES (Symmetric, Same key for de- and encryption)

 

Why can't you rely on SSL/TLS for transmission?

 

I think from a security standpoint you should not implement something like this. Why not just let the end user generate a Key Pair, using their public key (sent over https) to encrypt your data (or AES key, for large Data) and you sent this back to the user. 

 

If the data passes only on the Internet, you have to trust a 3. Party (like a Certificate Authority), so why reinvent the wheel? In your solution, there is no trust, that there is no men in the middle, this is basically what SSL solves using a trusted 3. party.

 

Also, when the data is encrypted with your private key, it is save (or at least I would consider it as that). So how will the end user decrypt it? Are you sharing your private key ??? If yes, so why are you using RSA (KeyPair, not made to encrypt data files / large data) if you could simply use AES (which is symmetric) for a task like this?

 

Next question, why would you encrypt a hash? It basically says nothing about the data. If you care about transmission safety, just use SSL. It is so much better than implementing your own home made encryption, which probably has some flaws.  

 

If you just want to check the validity of the sent data, take a look at HMAC (message authentication code). For that you basically need a shared secret with the end user. You then sign your data with that secret and sent it to the end user. He then generates the same HMAC (with the shared secret) and compares them. So he can tell if the data you sent is valid. 

 

 

[JCBiggs]

Each step of the process would use standard tools and algorithms.  Im trying to outline a scheme rather  than implement technically correct solutions  right now.  The only reason i would encrypt the hash is to ensure p2p security without relying on http/ssl/etc. 

 

The end user is never supposed to know what the original encrypted payload is. Thats part of the trust. 

 

Lets put it this way.    You are having the party of the century.  You have 1000 unique (important they are all unique) tickets to give out.   So you give them away and the new owners can do whatever they want with them,    some decide to sell them.  The buyer then sells it to another and another and so on.  

 

The question is how do you ensure ONLY the 1000 original tickets are allowed into the party.  How do you make sure someone along the way didn't copy thier ticket and sell it 50 times.  And you have to assume there is no way to ask the party planner if its original until you actually get to the doorman at the party.  (Where the first to show would be the only let in)

 

That's what I'm trying  to accomplish.  So I'm trying to protect against copying/fraud. Its critical someone can't be fooled or scammed  into buying junk.  The 1000 tickets would be made with a secret key then that key destroyed so no one includng me can make more. The private key decrypts the payload, checks the list to make sure is not already inside and green or redlights  people into or away from the party. 

 

This is not for a decentralized system. 

 

[leodaniel]

23 minutes ago, JCBiggs said:

The only reason i would encrypt the hash is to ensure p2p security without relying on http/ssl/etc. 

No it simply does not. This ensures you nothing at all. You can't assume that there is no man in the middle. This is basically what SSL solves with the Certificate Authority. 

--> USE SSL for that.

 

If you only need to check the validity of the data, use HMAC with a shared secret.

 

23 minutes ago, JCBiggs said:

 Im trying to outline a scheme rather  than implement technically correct solutions

A scheme is as important as the technical solutions. If your scheme has flaws, the hole process is unsafe.

 

23 minutes ago, JCBiggs said:

The end user is never supposed to know what the original encrypted payload is.

So use AES to encrypt the Data. No use of RSA cryptography here.

 

23 minutes ago, JCBiggs said:

The question is how do you ensure ONLY the 1000 original tickets are allowed into the party.  How do you make sure someone along the way didn't copy thier ticket and sell it 50 times.  And you have to assume there is no way to ask the party planner if its original until you actually get to the doorman at the party.

To solve this problem, you need either a central checking system or a decentralised ledger (blockchain). There is no trust in the Internet!

 

What you are basically trying to achieve is like a currency. You can't spend it twice / replicate it. So a lot of people have spend a lot of thoughts about this and there is a centralized system or a decentralised (blockchain).

 

[leodaniel]

32 minutes ago, JCBiggs said:

And you have to assume there is no way to ask the party planner if its original until you actually get to the doorman at the party.

In my eyes this is impossible. You get some data and need to tell from it if it's fake or not without asking someone?!? 

 

You will always need like a central system which has records of who owns the ticket or a decentralized system (blockchain). Cryptography does not change that.

 

Look at it like this. If every ticket has a unique ID, someone can copy that 100 of times. The first one will get in, all the others not. How can you solve that? You keep a record of which name belongs to which ticket. You can't solve that by simply checking the validity of the ticket ID. 

[JCBiggs]

In other words, you would have to validate every transaction...which is exactly what i don't want to do.  I guess this is basically the same problem rfid chips have.  

[leodaniel]

30 minutes ago, JCBiggs said:

In other words, you would have to validate every transaction...which is exactly what i don't want to do.  I guess this is basically the same problem rfid chips have.  

Yes RFID Chips are also replicable. You basically sell tickets wich correspond to an ID. Now if someone replicates this ID, the ticket is valid.

 

Now with just 1 ID, you can't check if it's the first sold ticket or if it's a copy. You can only tell if it's a valid ticket you gave to someone.

 

So to get around this, you can bind tickets (IDs) to a Name (User) or some other Unique Data from the actual owner. This way they are not replicable (or at least not so easy if you check for official documents on entry), but need a centralized place where you can check the validity / keep record of who owns which ticket. But this also makes them harder to resell or even doesn't allow resells, once they are sold.

 

Instead of given tickets away, you can give promises (some token or some amount of tickets they can create with their credentials) away, which enables the reseller to create a ticket with your API. This ticket is then bound to a user and not resellabel. A promise can only be used once. So the user can buy a ticket on the resellers page which gives him a personal ticket.

In other words: When selling, the reseller registers the user and requests you to create a unique Ticket for that unique user. So now that ticket is active and belongs to a unique user.

This doesn't fix the fact that you can replicate those promises, but the end user will most likely not get fraud. 

[JCBiggs]

Ok so lets back up a second.   This isn't really for a cryptocurrency, but maybe you could use the same  sort of 3rd party validation without relying on a central issuer.    Again the primary Motive is to keep the payload hidden, and to prevent replication.   So maybe a  ledger similar to the blockchain to record the current owner, but you only validate with the issuer  once you actually decide to use the ticket.   At which point that history of the block chain would be dissolved, preventing any real record of transactional history.  

[SCHISCHKA]

9 hours ago, JCBiggs said:

The question is how do you ensure ONLY the 1000 original tickets are allowed into the party.  How do you make sure someone along the way didn't copy thier ticket and sell it 50 times.  And you have to assume there is no way to ask the party planner if its original until you actually get to the doorman at the party.  (Where the first to show would be the only let in)

 

you have just described crypto-currency.

7 hours ago, JCBiggs said:

Ok so lets back up a second.   This isn't really for a cryptocurrency, but maybe you could use the same  sort of 3rd party validation without relying on a central issuer.    Again the primary Motive is to keep the payload hidden, and to prevent replication.   So maybe a  ledger similar to the blockchain to record the current owner, but you only validate with the issuer  once you actually decide to use the ticket.   At which point that history of the block chain would be dissolved, preventing any real record of transactional history.

crypto-currency again.

 

Every time a block is transferred it records the previous block so it is not hard to conceive putting a limit in how many times it can be transferred and recording a copy of the block before the first transfer

[JCBiggs]

Yes but cryptocurrency is based on trust of a ledger and that no one can forge the ledger.   Im talking about basing it on a physical entity (encrypted payload on a ubs drive), i have 0 interest in the ledger as a record of transactions, but onlyas a tool to completethetask.

 

So lets say Every time its passed on it gets a new hash and the merkel tree gets bigger, just like a bitcoin, causing a reliance on, and increase in complexity of the block chain and u need an internet connection.  Id like to see proof of ownership passed around on the block chan, but that  then can be verified againsit the central database. At which point all those transactions of chaging hands are disapeared and your left with a single hash of the current owner and the start of a new merkel for the next 10 rounds or so when the proccess would repeat. 

 

 

So the block chain would def fix the duplication problem. (Double spending in cryptocurrency terms) so in my case, id just need a private blockchain on my factory floor. Unfortunately that still doesn't solve the problem i have as the user could just share his password.   Im starting to think there isnt  a way to do what i need, 

 

 

[DXMember]

https://msdn.microsoft.com/en-us/library/system.security.cryptography(v=vs.110).aspx