not required

Decryption works as expected for any type and size of data. Tested up to file-sizes of 200GB

Fix: Set encoding output for decryption result.

ASCII above 127 are encoded as triplets of values "239,191,189" (=UTF8 65533). From 128+ information is compromised.

Individual decrypted blocks (chunks) are "glued" together.

back in action ... Implementing the decryption routine >1 year after coding the related encryption method. Just to keep myself busy, encryption and decryption is done with different APIs *sarcasm" :D

At least for XNAT this was recently resolved in T26449: XNAT connection failes due to missing OpenSSL connections.

Closed because of very long inactivity and drift to current code.

Deleted branch T23244-XNAT-nrrd-convenient-upload-feature.

This is also already on the TODO list of the packaging rewrite.

@nolden https://github.com/NVIDIA/ai-assisted-annotation-client/issues/57

I am re-opening this since I think this will also become more relevant with the foreseeable use of other REST APIs from MITK , e.g. how did the nvidia segmentation tool resolve this issue for the windows installer? @kislinsk could you comment?

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

There are two approaches:

1. Encrypt file and split it into blocks of max size 1MB
2. Split file into blocks of max size 1MB and then encrypt each block

encryption works as expected

1. encoding File/Blob object to ArrayBuffer (needed as input for AES encryption) crashes browser (tested on Chrome) if file is bigger 1GB:
   • check chunking

ToDos

• implement final caseID socketbased
• port encryptData to socketbased
• distinguish between uploading sites (such as CSI, E010, etc.)
• when decrypting, differentiate between files and string
• include IV of encrypted file
• include client PublicKey
• can formData be transported by websockets
  • compile needed socket.emit statement. emit supports Buffer

First initialize a TLS based websocket connection between browser and server. In addition encrypt the files using AES-GCM 256. Key to encrypt files is computed using ECDH P-384. Private/Public Key for ECDH is generated independently from the TLS secured websocket connection.

Koa.js is the way to go in this case

First initialize a TLS based websocket connection between browser and server. In addition encrypt the files using AES-GCM 256. Key to encrypt files is computed using ECDH P-384. Private/Public Key for ECDH is generated independently from the TLS secured websocket connection.

cannot be accomplished using cornerstone, since errors are thrown if non-dicom filesize is below "proper" DICOM file. Therefore we implemented our own routine to check if incoming filesize is below 132 bits, otherwise check if bits from 128 to 132 represent "DICM".

Keep in mind:

Updated Section C

check naming consistency:

Since it seems to be quite a hassle to establish a working connection with the sftp server, a more sophisticated approach is planned.