Changes between Version 11 and Version 12 of security/electronic_signatures

Timestamp:

Mar 1, 2013, 1:08:32 PM (11 years ago)

Author:

Sam Habiel

Comment:

--

security/electronic_signatures

@@ -281 +281 @@
 Please note that while the above conversion can be made rerun-safe, this is not taken into consideration here. This code can only be run once without it proving to be harmful. However, if it is ran again, the reverse operation can be performed to correct the action of the second run.
 
-I didn't write example code for Radiology/Nuclear Medicine as I don't have test data in that package.
+I didn't write example code for !Radiology/Nuclear Medicine as I don't have test data in that package.
 
 Once the new algorithm is in use, to reuse an example presented above, here is what to expect if the document is tampered with:
@@ -306 +306 @@
 
 === Impact of the new encryption algorithm ===
-This area is far more problematic for two reasons: the output of the hash is random data (which Fileman cannot store), and with block ciphers input is padded to achieve block size. Both of these issues mean that to achieve proper encryption, you will need to base64 encode output from a block cipher so the result can be stored in Fileman. In the end, it means that the encrypted data is much longer than the original data (but not quite double the size). This means that we need to expand the Fileman fields where the encrypted data is stored. The KIDS file accompanying this article expands the 4 TIU fields that store encrypted data to 120 characters each from 60 characters. It's anticipated that other fields (especially field 10 in File 74) will need to be expanded depending on the number of packages you are using. The alternative is to change the encryption algorithm to something much weaker (even rot5) to be able to retain the current sizes.
+This area is far more problematic for two reasons: the output of the hash is random data (which Fileman cannot store, as it cannot store bytes which Mumps considers to be control characters), and with block ciphers input is padded to achieve block size. Both of these issues mean that to achieve proper encryption, you will need to base64 encode output from a block cipher so the result can be stored in Fileman. In the end, it means that the encrypted data is much longer than the original data (but not quite double the size). This means that we need to expand the Fileman fields where the encrypted data is stored. The KIDS file accompanying this article expands the 4 TIU fields that store encrypted data to 120 characters each from 60 characters. It's anticipated that other fields (especially field 10 in File 74) will need to be expanded depending on the number of packages you are using. The alternative is to change the encryption algorithm to something much weaker (even rot5) to be able to retain the current sizes.
 
 The following is an analysis of all the impacted area in VISTA:
@@ -384 +384 @@
 
 == Future Direction ==
-In-MUMPS encryption can be decrypted by anybody who knows Mumps well enough. Since the application needs to decrypt data for ALL appropriately authorized users, it makes it difficult to design password or token based encryption systems. This is the reason that public/private key encryption will not work smoothly here without compromising security: if you are a different user, how would you decrypt a document encrypted using another user's or a machine's private key? Would you then make a public/private key accessible to everybody? What's the point in that?
-Casting these issues aside, there is one way in which encryption can be strengthened: basing it on a hardware token. You will need one of these for each server, but this ensures that the encrypted data will be unreadable outside the machine at which it was encrypted.
-
-It's best to know what attack vectors to protect against. The encryption system here is not designed to hide the data; rather only detect if it has been tampered with outside of the official APIs.
+In-MUMPS encryption can be decrypted by anybody who knows Mumps well enough, since the application needs to decrypt data for ALL appropriately authorized users. This is the reason that public/private key encryption will not work smoothly here without compromising security: if you are a different user, how would you decrypt a document encrypted using another user's or a machine's private key? 
+
+However, it is best to emphasize that the encryption system used in VISTA is not there to encrypt data; rather it's there to assure its integrity.
 
 = Appendix 1: How does TIU encrypt the signature blocks =