[Cryptography Team] ASN1WrapperConstructedType and ASN1ExplicitContextValue use

Ron Teitelbaum ron at usmedrec.com
Sat Sep 10 00:28:37 UTC 2022


HI Rob,

I see.  We are using TCP secure sockets now with our own protocol to do an
overlay network to allow for network prioritization.  It all runs over one
port which makes proxy support simple. The overlay network allows us to
limit traffic to what is most important.  Since we are not passing a huge
amount of data we don't use UDP.  Maybe at some point in the future it
would be a good idea to look into it.  I don't think it is necessary now.
It might be interesting to look into UDP for 3D object data sometime in the
future.  Thanks for the offer.

All the best,

Ron




On Fri, Sep 9, 2022 at 8:19 PM rabbit <rabbit at callistohouse.org> wrote:

> Hey, yes I was think of getting ParrotTalk working over UDP, then
> RemotePromises on top of that, then place it underneath Croquet to combine
> a metaverse communications protocol with distributed secure
> object-capabilities alongside.
>
> My latest ParrotTalk iteration is to get my SPADS Server working. The
> SPADS server will have multiple installed secure protocols (ParrotTalk
> v3.6, v3.7 & v3.8 as well as SSL 1.0, TLS 1.2, perhaps TLS 1.3 (with
> elliptical DH) and SSH. There is a probing frame buffer just above the
> socket thunk with protocol frame probes which
>
>
> Have a good one; keep it, light.
> Kindly,
> rabbit
> . .. … ‘…^,^
>
>
> Sent from Callisto House :: decentralized mobile homeless solutions
>
> On Sep 9, 2022, at 20:10, Ron Teitelbaum <ron at usmedrec.com> wrote:
>
> 
> Hi Rob,
>
> Yeah I'm still working on Croquet at 3D Immersive Collaboration Corp
> www.3dicc.com.  We renamed our product from Immersive Terf, before that
> Teleplace, and  before that Qwaq, to Virtend.  As in you can virtually
> attend a meeting.
>
> UDP can be encrypted but since the stream itself is not guaranteed you
> would need to encrypt each datagram.  I believe there is a good method for
> this using DTLS.  https://www.rfc-editor.org/rfc/rfc4347.txt.
>
> All the best,
>
> Ron Tetielbaum
>
> On Fri, Sep 9, 2022 at 5:03 PM rabbit <rabbit at callistohouse.org> wrote:
>
>> HAH HAH HAH HAH!!!
>>
>> Yessir, it was a long time ago. According to your methods
>> in ASN1ExplicitContextValue, it was 16 years ago, yesterday! .  ..   ….
>> ‘…^,^
>>
>> I am still undecided. Should Crypto ASN1 type structures (DSAPublicKey,
>> and such) be of an application variety? But WrapperPrimitive perhaps, not
>> constructed.
>>
>> You said: [  I believe that for Objects this makes sense if we are
>> encoding them but you could easily encode them as class name with a bucket
>> of values with default encoding. ]
>>
>> Yes, I’ll need to see about this. Some sort of
>>
>>     ASN1 tagValues:= object class instVarNames
>>         collect: [ :ivarName | object instVarAt: ivarName ].
>>     ^ Array with: object className with: tagValues.
>>
>> You also wrote: [Wish I had more time to work on this but I'm sorry I
>> don't right now.  Good luck with it.  Let me know what you decide to do
>> with it.  Happy to try and keep up to date on it.]
>>
>> What is keeping you busy these days?
>>
>> Didn’t you work with Croquet? Do you think ParrotTalk could talk and
>> encrypt over UDP? I don’t understand how UDP works. :(
>>
>> Cheers!
>>
>> Have a good one; keep it, light.
>> Kindly,
>> rabbit
>> . .. … ‘…^,^
>>
>>
>> Sent from Callisto House :: decentralized mobile homeless solutions
>>
>> On Sep 9, 2022, at 12:58, Ron Teitelbaum <ron at usmedrec.com> wrote:
>>
>> 
>> Hey Rob,
>>
>> I'm not sure it was a long time ago.  My understanding of the application
>> flag is that it is for encoding tags that are application specific and not
>> for ASN1 defined values.  So the Context is an Application context not a
>> default value.  If we have a specific context and special rules for
>> encoding or decoding a value it would be marked as application otherwise it
>> should be marked as non-application specific to handle it using default
>> rules.  I believe that for Objects this makes sense if we are encoding them
>> but you could easily encode them as class name with a bucket of values with
>> default encoding.
>>
>> Wish I had more time to work on this but I'm sorry I don't right now.
>> Good luck with it.  Let me know what you decide to do with it.  Happy to
>> try and keep up to date on it.
>>
>> All the best,
>>
>> Ron Teitelbaum
>>
>> On Fri, Sep 9, 2022 at 11:11 AM rabbit <rabbit at callistohouse.org> wrote:
>>
>>> Hi Ron,
>>>
>>> I see that originally when you had introduce ASN1 to our library, you
>>> defined the classes ASN1WrapperConstructedType and
>>> ASN1ExplicitContextValue. I tried to implement decode and encode to
>>> ASN1WrapperConstructedType, but only partially. I used your
>>> ASN1ExplicitContextValue but have not completed it. Now I have the need to
>>> implement, as I attempt to switch the PromisesRemote to using ASN1
>>> encoding, rather than STON.
>>>
>>> In looking at Object>>#asn1Tag we construct a tag with
>>>
>>> Object>>#asn1Tag
>>>
>>>     ^ (ASN1MappedSequenceType new asn1Tag "48"
>>>             bitOr: 2r11000000) "Application"
>>>             bitOr: 2r00100000 "Constructed"
>>>
>>> So we are an application class and constructed. In
>>> ASN1OutputStream>>#typeForTag: tag, the tag is broken down into the
>>> numericTag, the tagClass (application) and whether it is constructed. This
>>> is called from decode: anObject with the call:
>>>
>>> ^ self encode: anObject with Type: (self typeForTag: anObject asn1Tag)
>>>
>>> So Object>>#asn1Tag is called. So with a ASN1 non-registered object, we
>>> end up with a ASN1WrapperConstructedType.
>>>
>>> I am totally unsure about how the ASN1ExplicitContextValue should be
>>> used with the ASN1WrapperConstructedType, nor how it builds the context
>>> from the ivars of the provided anonymous object.
>>>
>>> My related concern is whether all of the crypto objects with ASN1
>>> definitions ought to be of the application tagClass.
>>>
>>> Any guidance you could provide me for this would be very welcome! If it
>>> is not too far back in history! Heh!
>>>
>>> Thanks!
>>>
>>> --
>>> Have a good one; keep it, light.
>>> Kindly,
>>> rabbit
>>> . .. … ‘…^,^
>>>
>>> Sent from Callisto House :: decentralized mobile homeless solutions
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20220909/66e2328e/attachment-0001.html>


More information about the Cryptography mailing list