I am having issues with aws s3 decrypting my file in SSE-C encryption technique - php

i encrypted my file using SSE-C encryption technique from s3 aws.
but when i tried to decrypt it, the following error popups.
i am using the same keys which i used when creating encryption.
the error is as follows:
InvalidRequest
The object was stored using a form of Server Side Encryption. The correct parameters must be provided to retrieve the object.
any suggestions on this please.

Related

Secure PHP & Java (Android) encryption and decryption functions

I'm trying to find a very secure php encryption that can be decrypted in Android and vice-versa to send data securely. I found old functions not compatible with new versions of PHP. Any ideas please?
Possible duplicate SHA1 in Java and PHP with different results
Encryption and decryption functions are deterministic. If you encrypt SHA-256 on Android, and then decrypt it with PHP, it should work fine. They use the same functionality.
If you have tried this and it didn't work, your problem most likely lies in your encoding method.
Current PHP encryption method:
http://php.net/manual/en/function.openssl-encrypt.php
Function to get available ciphers:
http://php.net/manual/en/function.openssl-get-cipher-methods.php

Simple method of securing by php API [duplicate]

I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.

Do I need to encrypt data when exchanging information via SSL?

I’m creating a service where I have the data encrypted in my database, but need to send it to an application (via API requests). My question is: do I need to send the data encrypted throughout the connection (using OpenSSL private and public keys) or does SSL do all that stuff? So can I keep the data safe when interacting with applications and sending the data as it is (non-encrypted)?
Can someone provide more information about it?
Thanks.
SSL encrypts all the payload so you do not need to encrypt your data within SSL. It will be decrypted at the other end of the network.

Easiest two-way encryption to be used both on a PHP server and on iOS client

For private use only, I'm creating and hosting on my web server a PHP application that retrieves all my passwords for various accounts from a MySQL database and serves them to the client that is an iPhone application which should also be able to insert new passwords in the database.
Instead of sending this data over the internet as plain text I would like to encrypt them before sending them but I'm very new to encryption so I'm feeling a little bit disoriented among all the possible encryption algorithms out there.
While the mcrypt function on PHP seems to be very flexible and compatible with many encryption algorithms I couldn't find anything like that on iOS.
What I wanted was some algorithm easy to implement both on PHP and Objective-C that, given some plain text and an encryption key (stored both on the server and on the client), would encrypt AND decrypt the plain text.
For further detail the server/client communication I had in mind was something like this:
Client sends a request containing some client-specific-app-ID and the service
whose password the server should return
The server checks if that client ID is allowed to get that information
If the client is allowed then the server querys the database and
retrieves the password
The server encrypts the password and sends it to the client
The client decrypts the password and shows it to the user
This thing is for personal use only so I don't need unbreakable security because probably nobody will care breaking it.
I'm doing this just for research and to get started with encryption. I know this is not secure at all.
Do you guys know any two-way encryption algorithm that is easy to use both on php and objective-c that I can use to encrypt passwords on the server and decrypt them in iOS?
Don't bother with your own encryption. You just need to use an SSL link, e.g.
https://yourserver.example.com/getpasswords.php
^---
SSL gives you the encryption for free, and as a bonus allows the iOS client to be reasonably sure that it's connecting to YOUR server, and not some malicious fake server.

Secure transmission of file from client to a server

I'm uploading an encrypted file from Android phone to a server and decrypting the same file in the server side.
Client: Used HTTP post to send file to a server
Server: PHP
Encryption: Triple DES
I hard coded the keys and iv in both the client and server side. Is there any idea how to use the keys and iv so that the transmission is highly secured?
Thanks!
No. If you hardcode a symmetric key into a client application that runs on untrusted devices, it's practically no encryption at all. An attacker can just extract the key from his application, and decrypt all other transmissions.
Just use https with a single trusted root public key corresponding to your server.
If android encrypts the file immediately prior to transmitting it and the server decrypts it on receipt, then you should just use SSL/TLS/HTTPS.
Hardcoding either the key or the IV is horribly bad practice. If you hardcode the key in an application, anyone who can get the binary has the key and can read the message. If you hardcode the IV, even people who do not have the key can potentially do something( IV's can be public, but they MUST be random)

Categories