On 7/22/21 2:58 PM, Charles Mills wrote:
I would say in no event does the OP want to "roll his own" or "cobble
something together out of bits and pieces."
I think we have different ideas of what "roll your own" means.
Personally, I don't believe that running some standard commands (at
least from a unix perspective), transferring two files, and running some
closely related commands to be "rolling your own".
At least not any more than creating JCL is "roll your own".
This problem is what FTP does for a living.
Agreed.
An investment in secure FTP is an investment in the future, not just
this one problem.
Yes.
Though, sometimes such an /investment/ means a LOT more work, especially
if something is going to be persistent and need to adhere to corporate
security policies / scans / etc.
Often, especially for one off cases, doing a little bit more work
manually is the simpler and faster of the solutions.
Oh! In Step 3 below, add to the sentence "... using a secure
cryptographic-quality random-number generator."
Agreed.
I expect that any contemporary / patched operating system to
sufficiently address this concern. Especially when following vendor
best practices regarding cryptographic utilities that they provide.
Again, you don't want to roll your own on this. Waaaay too many traps
for the unwary.
See above. There is a big difference in putting some commands in JCL vs
coding your own cryptographic algorithms, including the math and keying
algorithms. There is an apt saying for that "friends don't let friends
create their own cryptographic algorithms". Friends help friends use
well established cryptographic algorithms in the proper way.
--
Grant. . . .
unix || die
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
