• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

How to decrypt file from server which is sent by the client FTPS

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the following project for homework. Need to create server-client with ftps and upload file to the server. Before uploading the file must be encrypted.The server from the other side, upon receiving the encrypted file, decrypt the file.I'm stuck here. I encrypted the file  and sent file to the server.Server receives the file but it receives it encrypted(obviously).Maybe need to decrypt it manually from server side but how? Any help would be much appreciated.


This is the requirement : Before upload of a file, the client encrypts the file, preserving both, encrypted
and plain file.
The server from the other side, upon receiving the encrypted file, decrypt the
file.
 
Ranch Hand
Posts: 167
5
MS IE Notepad Suse
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if this is what you was given - the one who gave you this don't know the difference between FTP and FTPS
protocols with append S like HTTPS, FTPS, IMAPS, SMTPS indicated the use connection-level encryption - that is, the whole connection is fully encrypted to protect data (instead of starttls wich is started as plain connection and then encrypted data are exchanged)
if your task is to use FTPS - then you only have to implement the connection level encryption - there is no need for encrypting the data again - otherwise you could use plain FTP - wich has the security issue that user credentials transmitted unencrypted - hence wich SFTP (FTP over SSH) is way better, as it provides simple data transfer FTP but the security of SSH
please ask the one who given you this what exactly you supposed to do - and ask this person to read up about FTP, FTPS and SFTP to may correct the question - wich as you stated doesnT make sense
 
Saloon Keeper
Posts: 10308
217
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only reason I can think of wanting to encrypt the file before sending it over a secure protocol, is when you only want the recipient to act as a data store, and don't want them to be able to read your files. You then only decrypt the file after retrieving it again at a later stage.

As Matt pointed out, encrypting when the sender sends and decrypting when the receiver receives is the job of the secure protocol. Encrypting it twice makes no sense.

And welcome to CodeRanch!
 
Yani Mihaylov
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I managed to do it with ftpClient.storeFileStream which returns outputstream. Its working with txt files because they are small. But if bytes are larger (for example 16k) its freezes with decryption. I think it manages to decrypt bytes smaller than x. Any suggestions how to decrypt byte by byte or small portions of bytes?
 
Matt Wong
Ranch Hand
Posts: 167
5
MS IE Notepad Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aside from the time passed since last reply and therfore I guess it doesn't matter anymore - here's some hints how to approach the give exercise - although as already mentioned it dosn't make much sense they way you posted it.

First: If you want to encrypted files, wich usual longer than a RSA key, you need a cryptographic function and key wich support this, for example AES in some block-mode with a random generated key. As AES is a symmetric operation, you only have one key for encryption and decryption, so you have to securely exchange it, for wich you can use RSA as one option. So I would start by generating a RSA keypair, store the private key securly and make the public key open to the public. If we want to keep it all in one eco system I could store it as a file to be downloaded. Of course this file has to be set to read only.
Second: Java has already anything on board to read a public RSA key, generate a random AES key, wrap it with RSA to securely transport it, and use AES to encrypt the data. The server reads the encrypted AES key, unwraps it, read the IV and use this two information together with pre-set algorithm to decrypt the data.

Again: I would highly recommend AGAINST using this as long as you want to use the server only as storage for encrypted data. In this case, its more common to use a passphrase based sheme so no need for RSA at all and the server don't have to know it either.
If you want to transfer files securly, you can use TLS (I'm currently working on a guide fit here how to set up your own PKI with bouncycastle lib. Or, you use already existing protocol security like FTPS or SFTP, wich internal also use TLS but hide it as implementation detail so you don't have to worry about it.

Aside from all that: to help we need code - you only posted "File localFile=encryptFile()" - wich, unless "encryptFile()" do all the stuff and return a refernce to a File already encrypted doesn'T make sense either. "stuck at decryption when file larger than X" isn't really much to guess on, but most likely it's caused by some padding issue as the server waits for more data but the client doesn't send them. Maybe its just some buffer not flushed, maybe it's some way more critical.
If this topic is still relevant to you please update us - otherwise I guess we could let it die here.
 
Yani Mihaylov
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not relevant anymore. Thanks for the clarification.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!