W dniu 15.01.2022 o 01:21, Tony Harminc pisze:
On Fri, 14 Jan 2022 at 13:00, Radoslaw Skorupka <[email protected]> wrote:
Let's assume two z/OS images and some data exchange.
One of possible methods is symmetric encryption.
However that requires key exchange.
I have the following idea:
1. Both sides create asymetric key.
2. Public keys are exported and exchanged.
3. One side encrypt symm key using public key of another side.
4. Second side decrypt symm key using it's own private key.
Does it make sense?
Sure..
Any hints?
What services to use in steps 4. and 5. ?
You don't show a point 5... But more generally, I'm not sure what you
are really asking. Certainly it makes sense - it is basically what any
public-key crypto scheme does.
For any such proposal you need a threat model. As Charles says, you
have to protect the private key(s) of the asymmetric algorithm, and
the single secret key of the symmetric one. You also need to consider
MITM/WITM (now called middleperson) attacks.
Even if this is - as you say later - a no-network scheme (I'll assume
you are exchanging tapes or using RFC 1149 or similar technology),
there is no real difference in the attack surface. Someone can
intercept and copy (or simply steal) your tape, or interrogate the
pigeon, or whatever. For a state-level actor, even middleperson
against a hand-carried key exchange against two banks is not
impossible. Cloak and Dagger.
Realistically, you don't want that secret key ever in clear text
outside the crypto hardware. This means using key entry station and
such to produce a transportable key. You can use ICSF or on fairly
modern z hardware you can use the crypto instructions yourself for all
the parts you describe.
Well these are all platitudes. If you can say a bit more about what is
unique about your problem (e.g. not already done by PGP et al),
perhaps you'll get less general answers.
Point 5. is a little bit vague (not my decision) and it is NOT a network
(FTPS would be sufficient IMHO).
Yes, it is somehow reinventing the wheel. However the amount of data is
small, the usage would be small (infrequent), so simple jobstep on both
sides seem to be OK. And there is some other coding planned, so some
ICSF services added on top are reasonable.
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
