Knowledgebase: PresSTORE White Papers
PresSTORE Security Features and Facts
Posted by Sven Koester, Last modified by Sven Koester on 19 October 2017 15:21

This white paper informs about security mechanisms like encryption and authentication

PresSTORE Security Features and Facts

Keywords: security encryption authentication login communication password XTEA RSA PKI

(537 vote(s))
Not helpful

Comments (2)
Alex Tayts
22 September 2013 22:25
Recently started using encryption on tape archives and was surprised that compression does not work any longer. This article is the answer. Why on Earth PresSTORE does encryption before compression!? Of course, encrypted data does not compress because it is random by definition of encryption! All sane applications encrypt after compression, unlike PresSTORE. Inexplicable design decision.
Ibrahim Tannir
20 November 2013 9:27
Perhaps I can shed some light into the matter and help you understand this "insane" and "inexplicable" behavior which is a result of modular design, the hoistorical development of the product and of functional complexity. The problems and deisgn decisions are easily overseen in a simple backup environment. There are design trade offs that have to made to maintain backward compatibility and meet the requirements of complex environements.

There are three distinct modules and mechanisms to consider:

1. Encryption - which has to maintain privacy and can only be done at the source.
2. Tape or storage compression - which is a hardware mechanism of the tape drive.
3. Compression on the transfer channel - which is independent of and agnostic to any information passed through the channel.

The product was initially designed to employ the hardware compression offered by the tape drive, which is also a means of reducing processor load while making better use of storage. We have never considered or intended to compress the payload at the source, but have used the available hardware mechanisms for that purpose.

Transfer compression was later introduced to reduce network load, especially for slow networks. Since the traffic between the client and the server also contains control information that is passed throught the same channel, the entire traffic is compressed before transfer and decompressed at the receiving end.

Encryption was the last module added. It is the module closest to the source of the data and henceforth it is the operation that takes place before any other in the pipe.

And finally to consider, there is also the complexity of the highly parallel data multiplexing during simultaneously writing data from multiple source and clients, where some may be encrypted, others not, some compressed other not and where the tape drive is ultimately handling the compression.

So, yes, it would be possible to add yet another (software) compression layer into the pipe that takes place before encryption - but that would be adding to the complexity of the product and to the already high processor load in order to meet the need of a single customer (up until now). Frankly, we have not seen customers using encryption all that often and none observing this "small inconvenience". However, we always have an open ear to your needs and take them seriously - that is why we will add your comment to the customers' wish list and consider implementation in a future release. We thank you for your comment and time.

Post a new comment
Full Name:
CAPTCHA Verification 
Please enter the text you see in the image into the textbox below (we use this to prevent automated submissions).