2 ms·

The first line of defense and encryption is provided by the MUMPS system itself. Both Cache and GT.M provide encryption of the database on the disk. I am not as

by whitten 10y ago

The first line of defense and encryption is provided by the MUMPS system itself. Both Cache and GT.M provide encryption of the database on the disk. I am not as familiar with Cache's methods recently, but as I recall, GT.M has stated they are encrypting the dynamic data in memory as well. GT.M also allows changing the encryption key for a database and re-encrypting the whole database with a new key dynamically. (i.e. while the system is actively being used (read and write) for financial or healthcare data.) Other common issues in healthcare involve using ssh and TLS to encrypt TCP/IP data being transmitted over the network, as well as use of PGP or one-way encrypting for login passwords, such as VistA's ACCESS CODE and VERIFY CODE.

tcpipcowboy 10y ago
A hypothetical example would be a routine that calls another routine and passes information to the child process. Can one programmatically encrypt that information to make sure it retains PHI security? This is asked understanding that at the server level the information should technically be secured (as you noted, including transmitted data), but with the desire to work in "paranoid mode" and ensure extra layers of patient confidentiality at the code level. Just in the tutorials for MUMPS and M I've reviewed so far I've not seen any clear examples I could test out. In reviewing $TRANSLATE()closer, it's not exactly what I'm looking for, either, although this and $ZTRANSLATE() may be as close as I can get for my example from what I've read thus far. Appreciate the reply!
- whitten 10y ago
  So, calling another routine in M doesn't create a child process. Nor does calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-Processing" and you expresses that you can start another "JOB" that calls another bit of code that starts in another process using the JOB command rather than the DO subroutine call command. (I'm trying not to be pedantic, but rather to increase knowledge about this obscure programming language) You can pass data to this other process, but the ANSI MUMPS standard does NOT require that the data passed by inter-process communication channels be encrypted. Since GT.M is open source, it is an interesting idea to encrypt this data and decrypt it when receiving it. I'll bring it up to some friends. Another idea worth examining might be to use the Foreign subroutine interface both in Cache and GT.M systems. Thanks for suggesting this.
  - tcpipcowboy 10y ago
    Thanks for the terminology clarification. Still getting used to M so please bear with me here. I'm using GT.M-amd64-Linux/V6.3-000A. Just in the research I've done so far, I'm looking at something along the lines of the below, but I would love to see more advanced and complete snippets. ;-- ; New, define variables ;-- N cryptKey,derivedKey,cipher,plainText S cryptKey="Private Encryption Key" S derivedKey=$$zderiveKey(cryptKey,1,1) S plainText'"Hello, Crypto World!" ;-- ; Encrypt plainText ;-- S cipher=$$zaesenc(plainText,derivedKey) ;-- ; Display decrypted text ;-- W # W !,"Encrypted: ",cipher W !!,"Decrypted: ",$$zaesdec(cipher,derivedKey) Q I'll look into the Foreign subroutine interface. Anything like Haskell's FFI?

by whitten 10y ago

tcpipcowboy 10y ago

A hypothetical example would be a routine that calls another routine and passes information to the child process. Can one programmatically encrypt that information to make sure it retains PHI security? This is asked understanding that at the server level the information should technically be secured (as you noted, including transmitted data), but with the desire to work in "paranoid mode" and ensure extra layers of patient confidentiality at the code level. Just in the tutorials for MUMPS and M I've reviewed so far I've not seen any clear examples I could test out. In reviewing $TRANSLATE()closer, it's not exactly what I'm looking for, either, although this and $ZTRANSLATE() may be as close as I can get for my example from what I've read thus far. Appreciate the reply!

whitten 10y ago
So, calling another routine in M doesn't create a child process. Nor does calling a routine in M create a new thread. The "MP" in MUMPS is "Multi-Processing" and you expresses that you can start another "JOB" that calls another bit of code that starts in another process using the JOB command rather than the DO subroutine call command. (I'm trying not to be pedantic, but rather to increase knowledge about this obscure programming language) You can pass data to this other process, but the ANSI MUMPS standard does NOT require that the data passed by inter-process communication channels be encrypted. Since GT.M is open source, it is an interesting idea to encrypt this data and decrypt it when receiving it. I'll bring it up to some friends. Another idea worth examining might be to use the Foreign subroutine interface both in Cache and GT.M systems. Thanks for suggesting this.
- tcpipcowboy 10y ago
  Thanks for the terminology clarification. Still getting used to M so please bear with me here. I'm using GT.M-amd64-Linux/V6.3-000A. Just in the research I've done so far, I'm looking at something along the lines of the below, but I would love to see more advanced and complete snippets. ;-- ; New, define variables ;-- N cryptKey,derivedKey,cipher,plainText S cryptKey="Private Encryption Key" S derivedKey=$$zderiveKey(cryptKey,1,1) S plainText'"Hello, Crypto World!" ;-- ; Encrypt plainText ;-- S cipher=$$zaesenc(plainText,derivedKey) ;-- ; Display decrypted text ;-- W # W !,"Encrypted: ",cipher W !!,"Decrypted: ",$$zaesdec(cipher,derivedKey) Q I'll look into the Foreign subroutine interface. Anything like Haskell's FFI?