V5.0.1

New Features

Verification Storage

The verification store behavior has been improved. Please note the breaking changes regarding the verification store below.

  • When given a path to the verification store, the Client instance uses a default IStore implementation.

    • An additional ProtectionScope parameter can be passed, specifying whether the verification store should be protected on a per-machine or per-user (domain) basis. When no ProtectionScope is specified, the ProtectionScope.LOCAL_MACHINE is used, allowing different domain users to protect and unprotect the store contents on a single machine.

    • Alternatively, the Client constructor is able to accept an additional IStore parameter instead of a path to a verification store. This interface describes the general notion of setting, getting, removing key-value pairs and persisting its contents.

  • A parameterless version of Client.checkCompatibility has been introduced to perform a Cryptshare Server compatibility check against the minimum required version which is defined internally by each version of the API.

  • The Client now supports storing the verification for a single user email address in combination with different Cryptshare Server URLs. This change makes it possible to persist multiple verification tokens of a single user, depending on the specified Cryptshare Server URLs.

QUICK

The API has been extended by several methods and properties related to QUICK Technology.

Revoke a transfer

It is now possible to revoke a transfer such that its files are no longer accessible by the recipients. In order to revoke a transfer, call either overload of Client.RevokeTransfer and, if necessary, specify whether the sender/recipient should be notified about the transfer revocation via email. Optionally, you may pass a message parameter to override the default notification message with a custom text.

Provide custom IProtectionService implementation

It is now possible to provide a custom implementation of IProtectionService when protecting the contents of the client store. We also provide the reference implementation AesProtectionService which allows the protection of a store using AES encryption with a chosen IKeySourceProvider. We also offer an IKeySourceProvider reference implementation.

New upload callbacks

New callback parameters have been introduced to Client.performTransfer and Client.beginTransfer. These handlers are called when the transfer’s status changes. In summary, the server performs various processing tasks such as file encryption between the calls to UploadFilesFinishedHandler and UploadCompleteHandler.

Breaking Changes

Existing client.store files are not compatible anymore!

Due to several internal changes to the verification store behavior, existing client.store files are not compatible anymore! Before utilizing the Cryptshare Java API v5, please make sure to remove the client.store so it can be recreated by the API and perform the client or sender verification again.

  • The namespace com.befinesolutions.cryptshare.aping has been renamed to com.cryptshare.api.

  • The minimum Cryptshare server version is 4.5.0.