Is TLS for the IIgs coming later?

[D Finnigan]

As a part of Stephen Heumann's SMB filesystem translator for GS/OS, he also
developed 65816 Cryptographic & Hash Libraries which are on GitHub here:
https://github.com/sheumann/65816-crypto

The project Read Me says:

This package contains libraries implementing cryptographic algorithms for
the 65816, suitable for use on the Apple IIgs and potentially also other
65816-based systems. Currently, it includes implementations of AES and RC4
encryption and decryption (in lib65816crypto), and of the MD4, MD5, SHA-1,
and SHA-256 hash functions (in lib65816hash). The core algorithms for each
of these are written in carefully optimized assembly code, and they can
generally process at least several thousand bytes per second on a 2.8 MHz
Apple IIgs.

Using the Libraries
These libraries can easily be used from ORCA/C, or from ORCA/M or other
assemblers that permit linking to OMF libraries. (With appropriate glue
code, they could also be used from other languages.) Refer to the included
header files for documentation on how to call them. Note that each algorithm
uses a 'context' structure which must be in bank 0. This can be allocated on
the stack (e.g. by using a local variable in C), although maximum
performance will be obtained if it is page-aligned.

============

Availability of these hashes and ciphers brings us one step closer to a TLS
library for the Apple IIgs.

[Stephen Heumann]

Post by D Finnigan
As a part of Stephen Heumann's SMB filesystem translator for GS/OS, he also
https://github.com/sheumann/65816-crypto
Availability of these hashes and ciphers brings us one step closer to a TLS
library for the Apple IIgs.

I actually wrote most of the 65816-crypto package years ago, partially
with TLS in mind, but actually implementing TLS on the IIGS would still
be quite a bit of work and might be prohibitive in terms of performance.

The biggest issue with TLS would be establishing the connection and
negotiating the encryption keys. That phase of TLS normally requires
public-key cryptography algorithms, which are not currently included in
the 65816-crypto package and which can be quite slow.

If you could get past that phase to the point of sending encrypted data
back and forth, then algorithms in the 65816-crypto package (e.g. AES
and HMAC-SHA256) could be used. That would still be pretty slow, but
maybe usable for some things, especially on an accelerated IIGS.

[D Finnigan]

Post by Stephen Heumann
If you could get past that phase to the point of sending encrypted data
back and forth, then algorithms in the 65816-crypto package (e.g. AES
and HMAC-SHA256) could be used. That would still be pretty slow, but
maybe usable for some things, especially on an accelerated IIGS.

Indeed so. Do you have an accelerator in your Apple IIgs? I do not, but
accelerators are a lot more accessible now than they were 10 years ago,
thanks to recent developments.

And next step with TLS is to integrate it in IIgs applications. That's going
to require efforts from IIgs developers.

[Andrew Roughan]

Post by Stephen Heumann

Post by D Finnigan
Availability of these hashes and ciphers brings us one step closer to a TLS
library for the Apple IIgs.

I actually wrote most of the 65816-crypto package years ago, partially
with TLS in mind

Following up publicly after private email seems to have not gotten through
(spam perhaps)

I see you have your own crypto routine library.
Were you aware of the hashtool and crypto toolsets? I’d be interested in
hearing your thoughts about this model of providing routines for
application reuse. And perhaps you may consider contributing your code to
them or taking them over?
QKumba has implemented cha-cha which I requested and should include at some
point.

I think all the available ciphers for IIgs are now deprecated which makes
establishing a connection more challenging when the goal posts keep
changing. Perhaps we can offload the encryption / decryption to some other
mechanism (perhaps UltimateDrive could be used).

Regards
Andrew

[Stephen Heumann]

Post by Andrew Roughan
I see you have your own crypto routine library.

Yes. It's open source and available from my GitHub:

https://github.com/sheumann/65816-crypto

There are libraries for the crypto and hash routines, which are usable
from ORCA/C or ORCA/M, and potentially also from other IIGS languages.

Post by Andrew Roughan
Were you aware of the hashtool and crypto toolsets? I’d be interested in
hearing your thoughts about this model of providing routines for
application reuse. And perhaps you may consider contributing your code to
them or taking them over?
QKumba has implemented cha-cha which I requested and should include at some
point.

I'm aware of the hash tool and crypto tool. They're valuable tools, but
they do not currently include all the crypto algorithms needed for SMB
(or for modern TLS or SSH), so I had to develop some of them myself, and
it was easiest for me to just make a library containing all the required
crypto algorithms.

I'm probably going to keep my implementations as a library, but others
are welcome to use it. You or others could also potentially incorporate
my code into the tools, if you wanted.

Post by Andrew Roughan
I think all the available ciphers for IIgs are now deprecated which makes
establishing a connection more challenging when the goal posts keep
changing. Perhaps we can offload the encryption / decryption to some other
mechanism (perhaps UltimateDrive could be used).

Some of the crypto algorithms I've implemented are still widely used and
not deprecated (e.g. AES and SHA-256), but in general the need to keep
up with evolving cipher suites is definitely a challenge for
implementing crypto on the IIGS, and some sort of offload mechanism
might well be more practical than doing everything on the GS.

[Oliver Schmidt]

Hi Stephen,

Post by Andrew Roughan
Perhaps we can offload the encryption / decryption to some other
mechanism (perhaps UltimateDrive could be used).

[...] some sort of offload mechanism
might well be more practical than doing everything on the GS.

I don't know what the UltimateDrive brings to the table that you desire,
but...

1.

The A2Pico:
* is software-defined hardware
* is open source - both hardware and firmware
* is very DIY friendly due to its through-hole variant without any chips to
be programmed
* is available as completely assembled SMD variant for a pretty affordable
price
* comes with a reusable library that contains the code necessary to
communicate with the A2
* can easily be programmed in C

2.

If you define a "crypto accelerator" software interface based on a
SmartPort character device, then this interface can be implemented both
* internally (i.e. based on A2Pico)
* externally (i.e. based on FujiNet)
in a similar way a "usual" SmartPort block device can be implemented both
internally (i.e. CFFA3000) and externally (i.e. Floppy Emu).

Oliver