Cryptography

cryptography@lists.squeakfoundation.org

364 discussions

I’m sad.
by rabbit 12 Sep '22

12 Sep '22

It seems no one has any time to maintain Cryptography. I think people are using it. I’m looking into adopting libsodium and would LOVE some help! Will Cryptography die on the Vine? Best, rabbit 🐰 Have a Good One; Keep it, Light. Kindly, rabbit . .. … ‘…^,^ Sent from Callisto House :: decentralized mobile homeless solutions

2 4

Porting the Cryptography library to use libsodium
by rabbit 11 Sep '22

11 Sep '22

Good morning! I have successfully made and installed libsodium on my box (Ubuntu Jammy). I wish to access functions in the libsodium.so from Squeak, but I am not familiar with FFI (Alien?). Another question I have is how to configure the vm to include libsodium.so or does using FFI remove that need? Is it possible to have the VM automatically download, make and install the libsodium.so? My approach is to get it all working then make it work right. Have a Good One; Keep it, Light. Kindly, rabbit . .. … ‘…^,^ Sent from Callisto House :: decentralized mobile homeless solutions

2 3

My endeavors…
by rabbit 10 Sep '22

10 Sep '22

Just to give you a heads up, I’ve set my plate with the following morsels: 1) SPADSServer with frame probe detection and protocol operations stack switching, for adaptive secure connections. Implementing a MultiListener to listen to multiple ports at the same time. 2) Port RemotePromises to use an ASN1Encoder thunk instead of STON. Change the tests to test the finite set of ASN1 messages sent as the PromiseProtocol over the Session. 3) Debug Raven and RemotePromises releases for their failure to handle a triggered event on #startupSuccessful. Did event registrations not get copied correctly when the operation gets switched? 4) Port our Cryptography onto the cross-platform libsodium library. 5) Kafka Client. Have a Good One; Keep it, Light. Kindly, rabbit . .. … ‘…^,^ Sent from Callisto House :: decentralized mobile homeless solutions

1 0

SPADS Support
by Robert Withers 31 Aug '22

31 Aug '22

I have started shaping my new SPADS server, the SecureProtocolAnalysisDetetectionSelection server. I have the ProbingFrameBuffer using frame probes to analyze, detect and select the operations for the discovered protocol. This SPADS server can come online with all available functional protocols installed and probing incoming traffic to detect and select the appropriate secure handshake protocol based on the initial frame arriving. Then proceed with that handshake to establish a secure connection. Currently non-functional and non-tested. I like to mold the clay before making it sound. Get it working; get it working right; get it working fast. It is not yet working, but it is molding well. ThunkStack-rabbit.40.mcz take it, light, rabbit . .. ... '...^,^

3 11

OpenSSL Releases Security Updates
by Ron Teitelbaum 17 Mar '22

17 Mar '22

Hi All, https://www.openssl.org/news/secadv/20220315.txt TLDR: It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. You are vulnerable to this if you accept certificates from clients. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. It is affected by the issue. Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1. All the best, Ron Teitelbaum

1 0

SHA3 or Keccak?
by Chris Muller 07 Aug '21

07 Aug '21

Does anyone know any way to perform these hashes from within a Squeak image?

1 0

RS FEC stabilized. All tests #Green!
by Robert Withers 27 Jun '21

27 Jun '21

Hi y'all, Progress. I managed to fix the remaining GF fields, including QRCode and the various Aztec fields. Verified with the RS Java code. Loading the latest ProCrypto-1-1-1 and ProCryptoTests-1-1-1 will load the latest RSFEC. > Installer ss > project: 'Cryptography'; > install: 'ProCrypto-1-1-1'; > install: 'ProCryptoTests-1-1-1'; > install: 'CryptographyRSPlugin'. Currently all methods are pluganized except for { #encode: #runEuclideanAlgorithm:..., #dividePoly... & @decode:twoS: }. I am getting segfaults on those primitives when called. Investigating... > - 41541 tallies, 53540 msec. > > ((116473 - 53540) / 116473) asFloat * 100 > 54% SpeedUp > > **Leaves** > > Unpluganized > 24.7% {13224ms} RSFECDecoderWithPlugin>>decode:twoS: > 3.0% {1587ms} RSFECDecoderWithPlugin>>runEuclideanAlgorithmPoly:poly:rDegrees: > > Pluganized > 16.9% {9045ms} RSFECGenericGFPoly class>>newField:coefficients: > 6.2% {3311ms} RSFECDecoderWithPlugin>>primFindErrorLocationsDegree:coefficients:fieldSize:expTable:logTable: > 4.2% {2245ms} RSFECGenericGFPolyWithPlugin>>addOrSubtractPoly: > 2.5% {1317ms} RSFECDecoderWithPlugin>>findErrorMagnitudes:errorLocations: > 1.7% {887ms} RSFECGenericGFWithPlugin>>log: > 1.1% {583ms} RSFECGenericGFPolyWithPlugin>>degree > > Other > 8.2% {4414ms} LargePositiveInteger(Integer)>>bitShift: > 5.8% {3115ms} SecureHashAlgorithm>>finalHash > 5.2% {2775ms} ByteArray class(Behavior)>>new: > 5.1% {2705ms} LargePositiveInteger>>+ > 3.1% {1639ms} SecureHashAlgorithm>>hashInteger:seed: > 2.4% {1260ms} SecureRandom>>nextRandom160 > 1.6% {833ms} SmallInteger(Magnitude)>>between:and: > 1.5% {786ms} ByteArray>>unsignedLongAt:put:bigEndian: -- --- Kindly, Robert

1 0

Re: [Cryptography Team] [Vm-dev] Reed Solomon plugins & performance slow down
by Robert Withers 05 Jun '21

05 Jun '21

Alright, Levente! Thank you so very much! You are a generous soul & an angel! Your suggestions (the first two) worked like a charm and I have a running plugin to GF arithmetic, GFPoly arithmetic and RSDecoder arithmetic {#findErrorLocation: & #findErrorMagnitudes:errorLocations:} both plugganized. The cumulative speedup is 568% and all the hotspots changed again. I tried to implement GFPoly>>#initializeField:coefficients: in a plugin function, but my image is crashing on startup, when standard GFs are created in GF class>>#startUp:, when each GF initializes it attempts to create a one and a zero polynomial. This would call the primitive for #initializePoly. This code can be seen in the package: CryptographyRSFECPluginsInitializeGFPoly. I am attempting to run: > (firstNonZero > coefficientsLength) > ifTrue: [ > mutableCoefficients := interpreterProxy > instantiateClass: interpreterProxy classByteArray > indexableSize: 1] > ifFalse: [ > mutableCoefficients := interpreterProxy > instantiateClass: interpreterProxy classByteArray > indexableSize: (coefficientsLength - firstNonZero + 1). The cumulative speedup is 568% and all the hotspots changed again. Here are the profiling results from just the RSFEC code alone, no RSErasure code is in the profiles. The new hotspots are, with RSFECPlugin, then without. > ((128683 > > / 22648) asFloat * 100) asInteger = 568% The remaining potential plugganization relates to complex object instantiation inside the plugin functions. {#decode:twoS:, #runEuclideanAlgorithm: and #initializeField:coefficients:}. The best value for work return is to plugganize #initializeField:coefficients: at 3.3 seconds (14%) > WITH GF & GFPOLY PRIMITIVES AND DECODER > > PRIMITIVES > > ( > > 3 > > asterix > > for > > in-progress plugganization) > > - 22194 tallies, 22648 msec. > > **Leaves** > 29.1% > > { > > 6586 > > ms} RSFECDecoderWithPlugin>>decode:twoS: > > 14.7 > > % { > > 3329 > > ms} RSFECGenericGFPoly > > class > >> > >>newField:coefficients: > > 7.3 > > % { > > 1646 > > ms} RSFECDecoderWithPlugin>>primFindErrorLocationsDegree:coefficients:result:fieldSize: > > 2.9 > > % { > > 654 > > ms} RSFECDecoderWithPlugin>>findErrorMagnitudes:errorLocations: > > 1.0 > > % { > > 237 > > ms} RSFECDecoderWithPlugin>>runEuclideanAlgorithmPoly:poly:rDegrees: Calls to plugganized GF/GFPoly methods: > 1.4% {317ms} RSFECGenericGFWithPlugin>>log: And: > WITHOUT GF & GFPOLY PRIMITIVES - NO RSFEC PRIMITIVES > > - > > 98352 > > tallies, > > 128683 > > msec. > > **Leaves** > GF arithmetic > > 23.4 > > % { > > 30126 > > ms} RSFECGenericGF>> > > exp > > : > > 13.4 > > % { > > 17229 > > ms} RSFECGenericGF>>addOrSubtract:by: > > 11.9 > > % { > > 15251 > > ms} RSFECGenericGF>>maskValue: > > 10.0 > > % { > > 12916 > > ms} RSFECGenericGF>> > > log > > : > > 8.6 > > % { > > 11059 > > ms} RSFECGenericGF>>normalizeIndex: > > 6.8 > > % { > > 8792 > > ms} RSFECGenericGF>>multiply:by: > GFPoly arithmetic > > 2.7 > > % { > > 3529 > > ms} RSFECGenericGFPoly>>evaluateAt: > > 2.1 > > % { > > 2715 > > ms} RSFECGenericGFPoly>>addOrSubtractPoly: > > 2.0 > > % { > > 2578 > > ms} RSFECGenericGFPoly>>multiplyByMonomialDegree:coefficient: --- Kindly, Robert On 6/3/21 8:43 PM, Levente Uzonyi wrote: > Hi Robert, > > I see the following potential causes: > > In #findErrorLocationsDegree:coefficients:count:fieldSize:result: the > return value in ambiguous. You make the primitive fail if not enough > errors are found. But after the send, you don't check for failure > but simply send #methodReturnReceiver. > Instead, you should either check for primitive failure after the send > or make #findErrorLocationsDegree:coefficients:count:fieldSize:result: > return boolean value: the method was successful or not. > E.g. when numErrors = 1, return true, in the other branch, return e = > numErrors. (If slang doesn't support boolean types, just use 0 and 1). > In the actual primitive method, check for the value returned by that > method and fail the primitive when needed. Once the primitive has failed, > you ought to return from it. > I see the above pattern in other methods too (marking the primitive as > failed in a not-top-level method without checking for failure outside). > Those need to be fixed as well. > > Another potential issue I see is that the validation of the arguments is > not complete. > E.g.: #stackIntegerValue: may have already set the primitive to failed if > the argument was not an integer. So, before continuing, that has to be > checked. > > Another possible but unlikely problem is that you assume that both result > and coefficients have at least one field. But that may not be true which > can result in segfaults. > > Levente

2 8

Re: [Cryptography Team] [Vm-dev] Reed Solomon plugins & performance slow down
by Robert Withers 04 Jun '21

04 Jun '21

Thanks very much, Levente. I'll dig into your suggestions tomorrow. I made my first contact over ham radio tonight after another generous soul totally hooked me up with cables and power supplies and programmed my radio. I am so excited! Now on the air, KO4PYS. --- Kindly, Robert On 6/3/21 8:43 PM, Levente Uzonyi wrote: > Hi Robert, > > I see the following potential causes: > > In #findErrorLocationsDegree:coefficients:count:fieldSize:result: the > return value in ambiguous. You make the primitive fail if not enough > errors are found. But after the send, you don't check for failure > but simply send #methodReturnReceiver. > Instead, you should either check for primitive failure after the send > or make #findErrorLocationsDegree:coefficients:count:fieldSize:result: > return boolean value: the method was successful or not. > E.g. when numErrors = 1, return true, in the other branch, return e = > numErrors. (If slang doesn't support boolean types, just use 0 and 1). > In the actual primitive method, check for the value returned by that > method and fail the primitive when needed. Once the primitive has failed, > you ought to return from it. > I see the above pattern in other methods too (marking the primitive as > failed in a not-top-level method without checking for failure outside). > Those need to be fixed as well. > > Another potential issue I see is that the validation of the arguments is > not complete. > E.g.: #stackIntegerValue: may have already set the primitive to failed if > the argument was not an integer. So, before continuing, that has to be > checked. > > Another possible but unlikely problem is that you assume that both result > and coefficients have at least one field. But that may not be true which > can result in segfaults. > > > Levente

1 0

Who's got the time on their dime?
by Robert Withers 03 Jun '21

03 Jun '21

Hey everyone! I am doing a bit of work in Cryptography, and I got to thinking that perhaps it needs an upgrade to stay current. Who has the time? Who has a dime? I'm not sure, but I do think we need Elliptical Curve crypto, for various purposes, to modernize. I am praying angels swoop down and make it happen! What we have built is so sweet! Bit hard to get it certified, though, I suppose. -- --- Kindly, Robert

1 0

← Newer
1
2
3
4
5
6
7
...
37
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography