| Re: Is TLS for the IIgs coming later? [message #421983] |
Sat, 27 July 2024 09:49  |
|
|
Originally posted by: Andrew Roughan
Stephen Heumann <stephenheumann@gmail.com> wrote:
> On 7/23/24 9:46 AM, D Finnigan wrote:
>> 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
|
|
|
|
| Re: Is TLS for the IIgs coming later? [message #421984 is a reply to message #421983] |
Sat, 27 July 2024 20:08  |
|
|
Originally posted by: Stephen Heumann
On 7/27/24 8:49 AM, Andrew Roughan wrote:
> 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.
> 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.
> 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.
--
Stephen Heumann
|
|
|
|
| Re: Is TLS for the IIgs coming later? [message #421987 is a reply to message #421984] |
Tue, 30 July 2024 02:38 |
Oliver Schmidt
Messages: 137
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi Stephen,
>> 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
|
|
|
|
Members
Search
Help
Register
Login
Home
