This is a message intended for anyone who was on the Cryptography team. I recently ported it to Pharo and had to make changes to RandomGenerator class>>unpredictableStringsDo:. This certainly removed some uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
--- Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
--- Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote:
This is a message intended for anyone who was on the Cryptography team. I recently ported it to Pharo and had to make changes to RandomGenerator class>>unpredictableStringsDo:. This certainly removed some uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Sunday, October 18, 2015 5:00 AM To: The general-purpose Squeak developers list; Pharo Development List Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote:
This is a message intended for anyone who was on the Cryptography team. I recently ported it to Pharo and had to make changes to
RandomGenerator
class>>unpredictableStringsDo:. This certainly removed some uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography #bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote:
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Sunday, October 18, 2015 5:00 AM To: The general-purpose Squeak developers list; Pharo Development List Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote:
This is a message intended for anyone who was on the Cryptography team. I recently ported it to Pharo and had to make changes to
RandomGenerator
class>>unpredictableStringsDo:. This certainly removed some uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography #bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote:
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Sunday, October 18, 2015 5:00 AM To: The general-purpose Squeak developers list; Pharo Development List Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote:
This is a message intended for anyone who was on the Cryptography team. I recently ported it to Pharo and had to make changes to
RandomGenerator
class>>unpredictableStringsDo:. This certainly removed some uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
On 19-10-2015, at 5:58 AM, Louis LaBrunda Lou@Keystone-Software.com wrote:
I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM).
ARM *is* most cpus. I think we long ago passed the point where more than 50% of all >32bit cpus were ARM.
Typically the temperature of each core is monitored by stuff added around the ARM cores in an SoC, not the ARM itself. For example on a Pi, `vcgencmd measure_temp` works, though strictly speaking that measures the general temp of the SoC - which like many devices that are ARM powered is a large thing to do stuff and just happens to have a few Gips of processor hidden in a small corner.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Airline Food
Hi Tim,
On Mon, 19 Oct 2015 10:02:25 -0700, tim Rowledge tim@rowledge.org wrote:
On 19-10-2015, at 5:58 AM, Louis LaBrunda Lou@Keystone-Software.com wrote:
I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM).
ARM *is* most cpus. I think we long ago passed the point where more than 50% of all >32bit cpus were ARM.
You are of course right. Possibly when I first read about "Digital Thermal Sensor", things may have been different. But I'm sure everyone knew what I meant.
Typically the temperature of each core is monitored by stuff added around the ARM cores in an SoC, not the ARM itself. For example on a Pi, `vcgencmd measure_temp` works, though strictly speaking that measures the general temp of the SoC - which like many devices that are ARM powered is a large thing to do stuff and just happens to have a few Gips of processor hidden in a small corner.
tim
Exactly what temperature is being measured probably doesn't matter as long as there is enough range to help add some entropy.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
This is great guys. Is there a way to get this from the image? Good to get it with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote:
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography #bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote:
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Sunday, October 18, 2015 5:00 AM To: The general-purpose Squeak developers list; Pharo Development List Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName platformSubtype datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that should be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each) asByteArray ] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote:
This is a message intended for anyone who was on the Cryptography team. I recently ported it to Pharo and had to make changes to
RandomGenerator
class>>unpredictableStringsDo:. This certainly removed some uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an admin. Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
This is great guys. Is there a way to get this from the image? Good to get
it
with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote:
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be
grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography
#bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote:
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of
entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Sunday, October 18, 2015 5:00 AM To: The general-purpose Squeak developers list; Pharo Development List Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that
should
be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName
platformSubtype
datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each)
asByteArray
] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that
should
be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each)
asByteArray
] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote:
This is a message intended for anyone who was on the Cryptography
team.
I recently ported it to Pharo and had to make changes to
RandomGenerator
class>>unpredictableStringsDo:. This certainly removed some class>>uncertainty from the results of this message. My question is what should I do about that? This method seems to require non-headless, as it is checking the mouse point and such. This being a crypto cornerstone, what the best answer here.
Thank you, Robert
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an admin. Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
This is great guys. Is there a way to get this from the image? Good to get
it
with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote:
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be
grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography
#bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote:
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of
entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Sunday, October 18, 2015 5:00 AM To: The general-purpose Squeak developers list; Pharo Development List Subject: Re: [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
I'm sorry, I forgot the code. I list the existing method, followed by my modified Pharo method below. I welcome any feedback.
Regards, Robert
Existing: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that
should
be generally hard to guess." | time | time := Time millisecondsToRun: [ aBlock value: World imageForm bits compressToByteArray ; value: Sensor mousePoint x asString ; value: Sensor mousePoint y asString ; value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString ; value: Display extent asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(vmVersion platformName primVmPath imageName
platformSubtype
datedVersion lastQuitLogPosition vmStatisticsReportString imageName) collect: [ : each | aBlock value: (SmalltalkImage current perform: each)
asByteArray
] ]. aBlock value: time asByteArray; "maybe the pointer has moved, hit it again." value: Sensor mousePoint asString ; value: Time millisecondClockValue asByteArray
Pharo port: unpredictableStringsDo: aBlock "Enumerate sources of information from my environment that
should
be generally hard to guess."
| time | time := Time millisecondsToRun: [ aBlock value: Time millisecondClockValue asByteArray ; value: Date today asString ; value: Time now asString. 100 timesRepeat: [ aBlock value: UUID new ]. #(version primImagePath imagePath datedVersion lastQuitLogPosition) collect: [ : each | aBlock value: (SmalltalkImage current perform: each)
asByteArray
] ]. aBlock value: time asByteArray; value: Time millisecondClockValue asByteArray
On 10/18/2015 04:23 AM, Robert Withers wrote: > This is a message intended for anyone who was on the Cryptography
team.
> I recently ported it to Pharo and had to make changes to RandomGenerator > class>>unpredictableStringsDo:. This certainly removed some > class>>uncertainty > from the results of this message. My question is what should I do > about that? This method seems to require non-headless, as it is > checking the mouse point and such. This being a crypto > cornerstone, what the best answer here. > > Thank you, > Robert
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an admin. Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
This is great guys. Is there a way to get this from the image? Good to get
it
with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote:
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal situation? If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be
grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography
#bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote:
Hi Robert,
Nice to see you!
Looks interesting I know that Chris did something gathering sources of
entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
All the best,
Ron Teitelbaum
> -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > Behalf Of Robert Withers > Sent: Sunday, October 18, 2015 5:00 AM > To: The general-purpose Squeak developers list; Pharo Development > List > Subject: Re: [Pharo-dev] [Cryptography port to Pharo] > RandomGenerator > class>>unpredictableStringsDo: > > I'm sorry, I forgot the code. I list the existing method, followed > by my modified Pharo method below. I welcome any feedback. > > Regards, > Robert > > --- > Existing: > unpredictableStringsDo: aBlock > "Enumerate sources of information from my environment that
should
> > be generally hard to guess." > | time | > time := Time millisecondsToRun: > [ aBlock > value: World imageForm bits > compressToByteArray ; > value: Sensor mousePoint x asString ; > value: Sensor mousePoint y asString ; > value: Time millisecondClockValue asByteArray > ; > value: Date today asString ; > value: Time now asString ; > value: Display extent asString. > 100 timesRepeat: [ aBlock value: UUID new ]. > #(vmVersion platformName primVmPath imageName
platformSubtype
> > datedVersion lastQuitLogPosition vmStatisticsReportString > imageName) > collect: > [ : each | > aBlock value: (SmalltalkImage current > perform: each)
asByteArray
> > ] ]. > aBlock > value: time asByteArray; > "maybe the pointer has moved, hit it again." > value: Sensor mousePoint asString ; > value: Time millisecondClockValue asByteArray > > --- > Pharo port: > unpredictableStringsDo: aBlock > "Enumerate sources of information from my environment that
should
> > be generally hard to guess." > > | time | > time := Time millisecondsToRun: > [ aBlock > value: Time millisecondClockValue asByteArray > ; > value: Date today asString ; > value: Time now asString. > 100 timesRepeat: [ aBlock value: UUID new ]. > #(version primImagePath imagePath datedVersion > lastQuitLogPosition) > collect: > [ : each | > aBlock value: (SmalltalkImage current > perform: each)
asByteArray
> > ] ]. > aBlock > value: time asByteArray; > value: Time millisecondClockValue asByteArray > > > On 10/18/2015 04:23 AM, Robert Withers wrote: >> >> This is a message intended for anyone who was on the Cryptography
team.
>> >> I recently ported it to Pharo and had to make changes to > > RandomGenerator >> >> class>>unpredictableStringsDo:. This certainly removed some >> class>>uncertainty >> from the results of this message. My question is what should I do >> about that? This method seems to require non-headless, as it is >> checking the mouse point and such. This being a crypto >> cornerstone, what the best answer here. >> >> Thank you, >> Robert
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an
admin.
Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
This is great guys. Is there a way to get this from the image? Good to get
it
with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote:
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
Hi Ron , nice to see you too! It has been a number of years, hasn't it? Crypto is timestamped back in 2010, so there is is. I hope these have been kind years to you, as they have for me.
I love the idea of optional sources of entropy, depending on the deployed capabilities. So there are our mouse points and such, because they ought to be optional.
What are some reliably present sources in the most minimal
situation?
If we could define minimal as an image with no image level I/O beyond file I/O, I would think we'd have: Kernel, System, Collections, Compiler and FFI. Some intransitives in that scope for entropy would be
grand.
I was thinking to take 5 millisecondClockValues, separated by 4 non-secure random intervals: take the low order byte of the 4 intervals and reverse & concat them, as a entropic source.
I can coordinate these changes. Ron, could you add me to the Cryptography team so I can upload the Pharo Cryptography
#bleedingEdge?
Thanks and I look forward to more, :)
Robert
On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: > > Hi Robert, > > Nice to see you! > > Looks interesting I know that Chris did something gathering > sources of
entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
> > > All the best, > > Ron Teitelbaum > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >> Behalf Of Robert Withers >> Sent: Sunday, October 18, 2015 5:00 AM >> To: The general-purpose Squeak developers list; Pharo >> Development List >> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >> RandomGenerator >> class>>unpredictableStringsDo: >> >> I'm sorry, I forgot the code. I list the existing method, >> followed by my modified Pharo method below. I welcome any
feedback.
>> >> Regards, >> Robert >> >> --- >> Existing: >> unpredictableStringsDo: aBlock >> "Enumerate sources of information from my environment >> that
should
>> >> be generally hard to guess." >> | time | >> time := Time millisecondsToRun: >> [ aBlock >> value: World imageForm bits >> compressToByteArray ; >> value: Sensor mousePoint x asString ; >> value: Sensor mousePoint y asString ; >> value: Time millisecondClockValue >> asByteArray ; >> value: Date today asString ; >> value: Time now asString ; >> value: Display extent asString. >> 100 timesRepeat: [ aBlock value: UUID new ]. >> #(vmVersion platformName primVmPath imageName
platformSubtype
>> >> datedVersion lastQuitLogPosition vmStatisticsReportString >> imageName) >> collect: >> [ : each | >> aBlock value: (SmalltalkImage current >> perform: each)
asByteArray
>> >> ] ]. >> aBlock >> value: time asByteArray; >> "maybe the pointer has moved, hit it again." >> value: Sensor mousePoint asString ; >> value: Time millisecondClockValue asByteArray >> >> --- >> Pharo port: >> unpredictableStringsDo: aBlock >> "Enumerate sources of information from my environment >> that
should
>> >> be generally hard to guess." >> >> | time | >> time := Time millisecondsToRun: >> [ aBlock >> value: Time millisecondClockValue >> asByteArray ; >> value: Date today asString ; >> value: Time now asString. >> 100 timesRepeat: [ aBlock value: UUID new ]. >> #(version primImagePath imagePath datedVersion >> lastQuitLogPosition) >> collect: >> [ : each | >> aBlock value: (SmalltalkImage current >> perform: each)
asByteArray
>> >> ] ]. >> aBlock >> value: time asByteArray; >> value: Time millisecondClockValue asByteArray >> >> >> On 10/18/2015 04:23 AM, Robert Withers wrote: >>> >>> This is a message intended for anyone who was on the >>> Cryptography
team.
>>> >>> I recently ported it to Pharo and had to make changes to >> >> RandomGenerator >>> >>> class>>unpredictableStringsDo:. This certainly removed some >>> class>>uncertainty >>> from the results of this message. My question is what should I >>> do about that? This method seems to require non-headless, as it >>> is checking the mouse point and such. This being a crypto >>> cornerstone, what the best answer here. >>> >>> Thank you, >>> Robert > > > >
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-
Software.com
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an
admin.
Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
This is great guys. Is there a way to get this from the image? Good to get
it
with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote:
Hi Guys,
How about getting the CPU temperature. I think most CPUs support "Digital Thermal Sensor" (I'm not sure about ARM). I think it is seven bits. The real range should be less than that but it may be enough to help add some entropy.
Lou
On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers robert.w.withers@gmail.com wrote:
> Hi Ron , nice to see you too! It has been a number of years, hasn't it? > Crypto is timestamped back in 2010, so there is is. I hope these > have been kind years to you, as they have for me. > > I love the idea of optional sources of entropy, depending on the > deployed capabilities. So there are our mouse points and such, > because they ought to be optional. > > What are some reliably present sources in the most minimal
situation?
> If we could define minimal as an image with no image level I/O > beyond file I/O, I would think we'd have: Kernel, System, > Collections, Compiler and FFI. Some intransitives in that scope > for entropy would be
grand.
> > > I was thinking to take 5 millisecondClockValues, separated by 4 > non-secure random intervals: take the low order byte of the 4 > intervals and reverse & concat them, as a entropic source. > > I can coordinate these changes. Ron, could you add me to the > Cryptography team so I can upload the Pharo Cryptography
#bleedingEdge?
> > > Thanks and I look forward to more, :) > > Robert > > On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >> >> Hi Robert, >> >> Nice to see you! >> >> Looks interesting I know that Chris did something gathering >> sources of
entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom.
>> >> >> All the best, >> >> Ron Teitelbaum >> >>> -----Original Message----- >>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>> Behalf Of Robert Withers >>> Sent: Sunday, October 18, 2015 5:00 AM >>> To: The general-purpose Squeak developers list; Pharo >>> Development List >>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>> RandomGenerator >>> class>>unpredictableStringsDo: >>> >>> I'm sorry, I forgot the code. I list the existing method, >>> followed by my modified Pharo method below. I welcome any
feedback.
>>> >>> Regards, >>> Robert >>> >>> --- >>> Existing: >>> unpredictableStringsDo: aBlock >>> "Enumerate sources of information from my environment >>> that
should
>>> >>> be generally hard to guess." >>> | time | >>> time := Time millisecondsToRun: >>> [ aBlock >>> value: World imageForm bits >>> compressToByteArray ; >>> value: Sensor mousePoint x asString ; >>> value: Sensor mousePoint y asString ; >>> value: Time millisecondClockValue >>> asByteArray ; >>> value: Date today asString ; >>> value: Time now asString ; >>> value: Display extent asString. >>> 100 timesRepeat: [ aBlock value: UUID new ]. >>> #(vmVersion platformName primVmPath imageName
platformSubtype
>>> >>> datedVersion lastQuitLogPosition vmStatisticsReportString >>> imageName) >>> collect: >>> [ : each | >>> aBlock value: (SmalltalkImage current >>> perform: each)
asByteArray
>>> >>> ] ]. >>> aBlock >>> value: time asByteArray; >>> "maybe the pointer has moved, hit it again." >>> value: Sensor mousePoint asString ; >>> value: Time millisecondClockValue asByteArray >>> >>> --- >>> Pharo port: >>> unpredictableStringsDo: aBlock >>> "Enumerate sources of information from my environment >>> that
should
>>> >>> be generally hard to guess." >>> >>> | time | >>> time := Time millisecondsToRun: >>> [ aBlock >>> value: Time millisecondClockValue >>> asByteArray ; >>> value: Date today asString ; >>> value: Time now asString. >>> 100 timesRepeat: [ aBlock value: UUID new ]. >>> #(version primImagePath imagePath datedVersion >>> lastQuitLogPosition) >>> collect: >>> [ : each | >>> aBlock value: (SmalltalkImage current >>> perform: each)
asByteArray
>>> >>> ] ]. >>> aBlock >>> value: time asByteArray; >>> value: Time millisecondClockValue asByteArray >>> >>> >>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>> >>>> This is a message intended for anyone who was on the >>>> Cryptography
team.
>>>> >>>> I recently ported it to Pharo and had to make changes to >>> >>> RandomGenerator >>>> >>>> class>>unpredictableStringsDo:. This certainly removed some >>>> class>>uncertainty >>>> from the results of this message. My question is what should I >>>> do about that? This method seems to require non-headless, as it >>>> is checking the mouse point and such. This being a crypto >>>> cornerstone, what the best answer here. >>>> >>>> Thank you, >>>> Robert >> >> >> >>
>
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-
Software.com
Hi Chris,
The exemption is not for the location of the server but the URL where it is hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as
well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an
admin.
Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
This is great guys. Is there a way to get this from the image? Good to get
it
with an FFI/OSProcess call or something.
Thank you, Robert
On 10/19/2015 08:58 AM, Louis LaBrunda wrote: > > Hi Guys, > > How about getting the CPU temperature. I think most CPUs > support "Digital Thermal Sensor" (I'm not sure about ARM). I > think it is seven bits. The real range should be less than that > but it may be enough to help add some entropy. > > Lou > > On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers > robert.w.withers@gmail.com wrote: > >> Hi Ron , nice to see you too! It has been a number of years, hasn't
it?
>> Crypto is timestamped back in 2010, so there is is. I hope >> these have been kind years to you, as they have for me. >> >> I love the idea of optional sources of entropy, depending on >> the deployed capabilities. So there are our mouse points and >> such, because they ought to be optional. >> >> What are some reliably present sources in the most minimal
situation?
>> If we could define minimal as an image with no image level I/O >> beyond file I/O, I would think we'd have: Kernel, System, >> Collections, Compiler and FFI. Some intransitives in that scope >> for entropy would be
grand. >> >> >> I was thinking to take 5 millisecondClockValues, separated by 4 >> non-secure random intervals: take the low order byte of the 4 >> intervals and reverse & concat them, as a entropic source. >> >> I can coordinate these changes. Ron, could you add me to the >> Cryptography team so I can upload the Pharo Cryptography
#bleedingEdge? >> >> >> Thanks and I look forward to more, :) >> >> Robert >> >> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>> >>> Hi Robert, >>> >>> Nice to see you! >>> >>> Looks interesting I know that Chris did something gathering >>> sources of
entropy. Seems like the more the better. Could you just make the entropy sources optional such that if they exist we use them? I would have to go back and see what Chris did but he was following suggestions from Schneider in his secureRandom. >>> >>> >>> All the best, >>> >>> Ron Teitelbaum >>> >>>> -----Original Message----- >>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>> Behalf Of Robert Withers >>>> Sent: Sunday, October 18, 2015 5:00 AM >>>> To: The general-purpose Squeak developers list; Pharo >>>> Development List >>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>> RandomGenerator >>>> class>>unpredictableStringsDo: >>>> >>>> I'm sorry, I forgot the code. I list the existing method, >>>> followed by my modified Pharo method below. I welcome any
feedback.
>>>> >>>> Regards, >>>> Robert >>>> >>>> --- >>>> Existing: >>>> unpredictableStringsDo: aBlock >>>> "Enumerate sources of information from my environment >>>> that
should >>>> >>>> be generally hard to guess." >>>> | time | >>>> time := Time millisecondsToRun: >>>> [ aBlock >>>> value: World imageForm bits >>>> compressToByteArray ; >>>> value: Sensor mousePoint x asString ; >>>> value: Sensor mousePoint y asString ; >>>> value: Time millisecondClockValue >>>> asByteArray ; >>>> value: Date today asString ; >>>> value: Time now asString ; >>>> value: Display extent asString. >>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>> #(vmVersion platformName primVmPath imageName
platformSubtype >>>> >>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>> imageName) >>>> collect: >>>> [ : each | >>>> aBlock value: (SmalltalkImage current >>>> perform: each)
asByteArray >>>> >>>> ] ]. >>>> aBlock >>>> value: time asByteArray; >>>> "maybe the pointer has moved, hit it again." >>>> value: Sensor mousePoint asString ; >>>> value: Time millisecondClockValue asByteArray >>>> >>>> --- >>>> Pharo port: >>>> unpredictableStringsDo: aBlock >>>> "Enumerate sources of information from my environment >>>> that
should >>>> >>>> be generally hard to guess." >>>> >>>> | time | >>>> time := Time millisecondsToRun: >>>> [ aBlock >>>> value: Time millisecondClockValue >>>> asByteArray ; >>>> value: Date today asString ; >>>> value: Time now asString. >>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>> #(version primImagePath imagePath >>>> datedVersion >>>> lastQuitLogPosition) >>>> collect: >>>> [ : each | >>>> aBlock value: (SmalltalkImage current >>>> perform: each)
asByteArray >>>> >>>> ] ]. >>>> aBlock >>>> value: time asByteArray; >>>> value: Time millisecondClockValue asByteArray >>>> >>>> >>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>> >>>>> This is a message intended for anyone who was on the >>>>> Cryptography
team. >>>>> >>>>> I recently ported it to Pharo and had to make changes to >>>> >>>> RandomGenerator >>>>> >>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>> class>>uncertainty >>>>> from the results of this message. My question is what should >>>>> I do about that? This method seems to require non-headless, >>>>> as it is checking the mouse point and such. This being a >>>>> crypto cornerstone, what the best answer here. >>>>> >>>>> Thank you, >>>>> Robert >>> >>> >>> >>> >> > ----------------------------------------------------------- > Louis LaBrunda > Keystone Software Corp. > SkypeMe callto://PhotonDemon > mailto:Lou@Keystone-Software.com http://www.Keystone-
Software.com
> >
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as
well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an
admin.
Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
> -----Original Message----- From: > squeak-dev-bounces@lists.squeakfoundation.org > [mailto:squeak-dev- bounces@lists.squeakfoundation.org] > On Behalf Of Robert Withers Sent: Monday, October 19, > 2015 1:53 PM To: squeak-dev@lists.squeakfoundation.org > Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port > to Pharo] RandomGenerator class>>unpredictableStringsDo: > > This is great guys. Is there a way to get this from the > image? Good to get
it > > with an FFI/OSProcess call or something. > > Thank you, Robert > > On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >> >> Hi Guys, >> >> How about getting the CPU temperature. I think most >> CPUs support "Digital Thermal Sensor" (I'm not sure >> about ARM). I think it is seven bits. The real range >> should be less than that but it may be enough to help >> add some entropy. >> >> Lou >> >> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >> robert.w.withers@gmail.com wrote: >> >>> Hi Ron , nice to see you too! It has been a number of >>> years, hasn't
it?
>>> Crypto is timestamped back in 2010, so there is is. I >>> hope these have been kind years to you, as they have >>> for me. >>> >>> I love the idea of optional sources of entropy, >>> depending on the deployed capabilities. So there are >>> our mouse points and such, because they ought to be >>> optional. >>> >>> What are some reliably present sources in the most >>> minimal
situation?
>>> If we could define minimal as an image with no image >>> level I/O beyond file I/O, I would think we'd have: >>> Kernel, System, Collections, Compiler and FFI. Some >>> intransitives in that scope for entropy would be > > grand. >>> >>> >>> I was thinking to take 5 millisecondClockValues, >>> separated by 4 non-secure random intervals: take the >>> low order byte of the 4 intervals and reverse & >>> concat them, as a entropic source. >>> >>> I can coordinate these changes. Ron, could you add me >>> to the Cryptography team so I can upload the Pharo >>> Cryptography > > #bleedingEdge? >>> >>> >>> Thanks and I look forward to more, :) >>> >>> Robert >>> >>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>> >>>> Hi Robert, >>>> >>>> Nice to see you! >>>> >>>> Looks interesting I know that Chris did something >>>> gathering sources of > > entropy. Seems like the more the better. Could you just > make the entropy sources optional such that if they exist > we use them? I would have to go back and see what Chris > did but he was following suggestions from Schneider in > his secureRandom. >>>> >>>> >>>> All the best, >>>> >>>> Ron Teitelbaum >>>> >>>>> -----Original Message----- From: Pharo-dev >>>>> [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>> Behalf Of Robert Withers Sent: Sunday, October >>>>> 18, 2015 5:00 AM To: The general-purpose Squeak >>>>> developers list; Pharo Development List Subject: >>>>> Re: [Pharo-dev] [Cryptography port to Pharo] >>>>> RandomGenerator class>>unpredictableStringsDo: >>>>> >>>>> I'm sorry, I forgot the code. I list the existing >>>>> method, followed by my modified Pharo method >>>>> below. I welcome any
feedback.
>>>>> >>>>> Regards, Robert >>>>> >>>>> --- Existing: unpredictableStringsDo: aBlock >>>>> "Enumerate sources of information from my >>>>> environment that > > should >>>>> >>>>> be generally hard to guess." | time | time := >>>>> Time millisecondsToRun: [ aBlock value: World >>>>> imageForm bits compressToByteArray ; value: >>>>> Sensor mousePoint x asString ; value: Sensor >>>>> mousePoint y asString ; value: Time >>>>> millisecondClockValue asByteArray ; value: Date >>>>> today asString ; value: Time now asString ; >>>>> value: Display extent asString. 100 timesRepeat: >>>>> [ aBlock value: UUID new ]. #(vmVersion >>>>> platformName primVmPath imageName > > platformSubtype >>>>> >>>>> datedVersion lastQuitLogPosition >>>>> vmStatisticsReportString imageName) collect: [ : >>>>> each | aBlock value: (SmalltalkImage current >>>>> perform: each) > > asByteArray >>>>> >>>>> ] ]. aBlock value: time asByteArray; "maybe the >>>>> pointer has moved, hit it again." value: Sensor >>>>> mousePoint asString ; value: Time >>>>> millisecondClockValue asByteArray >>>>> >>>>> --- Pharo port: unpredictableStringsDo: aBlock >>>>> "Enumerate sources of information from my >>>>> environment that > > should >>>>> >>>>> be generally hard to guess." >>>>> >>>>> | time | time := Time millisecondsToRun: [ >>>>> aBlock value: Time millisecondClockValue >>>>> asByteArray ; value: Date today asString ; value: >>>>> Time now asString. 100 timesRepeat: [ aBlock >>>>> value: UUID new ]. #(version primImagePath >>>>> imagePath datedVersion lastQuitLogPosition) >>>>> collect: [ : each | aBlock value: (SmalltalkImage >>>>> current perform: each) > > asByteArray >>>>> >>>>> ] ]. aBlock value: time asByteArray; value: Time >>>>> millisecondClockValue asByteArray >>>>> >>>>> >>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>> >>>>>> This is a message intended for anyone who was >>>>>> on the Cryptography > > team. >>>>>> >>>>>> I recently ported it to Pharo and had to make >>>>>> changes to >>>>> >>>>> RandomGenerator >>>>>> >>>>>> class>>unpredictableStringsDo:. This certainly >>>>>> removed some class>>uncertainty from the >>>>>> results of this message. My question is what >>>>>> should I do about that? This method seems to >>>>>> require non-headless, as it is checking the >>>>>> mouse point and such. This being a crypto >>>>>> cornerstone, what the best answer here. >>>>>> >>>>>> Thank you, Robert >>>> >>>> >>>> >>>> >>> >> ----------------------------------------------------------- >> >>
Louis LaBrunda
>> Keystone Software Corp. SkypeMe callto://PhotonDemon >> mailto:Lou@Keystone-Software.com http://www.Keystone-
Software.com
>> >>
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as
well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote:
Hi Robert,
You are already on the Cryptograph repo on SqueakSource.com as an
admin.
Please feel free to reorg if you like.
Let me know if you have trouble resurrecting your account.
All the best,
Ron
> -----Original Message----- > From: squeak-dev-bounces@lists.squeakfoundation.org > [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf > Of Robert Withers > Sent: Monday, October 19, 2015 1:53 PM > To: squeak-dev@lists.squeakfoundation.org > Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to > Pharo] RandomGenerator class>>unpredictableStringsDo: > > This is great guys. Is there a way to get this from the image? > Good to get
it > > with an FFI/OSProcess call or something. > > Thank you, > Robert > > On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >> >> Hi Guys, >> >> How about getting the CPU temperature. I think most CPUs >> support "Digital Thermal Sensor" (I'm not sure about ARM). I >> think it is seven bits. The real range should be less than that >> but it may be enough to help add some entropy. >> >> Lou >> >> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >> robert.w.withers@gmail.com wrote: >> >>> Hi Ron , nice to see you too! It has been a number of years, hasn't
it?
>>> Crypto is timestamped back in 2010, so there is is. I hope >>> these have been kind years to you, as they have for me. >>> >>> I love the idea of optional sources of entropy, depending on >>> the deployed capabilities. So there are our mouse points and >>> such, because they ought to be optional. >>> >>> What are some reliably present sources in the most minimal
situation?
>>> If we could define minimal as an image with no image level I/O >>> beyond file I/O, I would think we'd have: Kernel, System, >>> Collections, Compiler and FFI. Some intransitives in that scope >>> for entropy would be > > grand. >>> >>> >>> I was thinking to take 5 millisecondClockValues, separated by 4 >>> non-secure random intervals: take the low order byte of the 4 >>> intervals and reverse & concat them, as a entropic source. >>> >>> I can coordinate these changes. Ron, could you add me to the >>> Cryptography team so I can upload the Pharo Cryptography > > #bleedingEdge? >>> >>> >>> Thanks and I look forward to more, :) >>> >>> Robert >>> >>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>> >>>> Hi Robert, >>>> >>>> Nice to see you! >>>> >>>> Looks interesting I know that Chris did something gathering >>>> sources of > > entropy. Seems like the more the better. Could you just make > the entropy sources optional such that if they exist we use them? > I would have to go back and see what Chris did but he was > following suggestions from Schneider in his secureRandom. >>>> >>>> >>>> All the best, >>>> >>>> Ron Teitelbaum >>>> >>>>> -----Original Message----- >>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >>>>> Behalf Of Robert Withers >>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>> To: The general-purpose Squeak developers list; Pharo >>>>> Development List >>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>> RandomGenerator >>>>> class>>unpredictableStringsDo: >>>>> >>>>> I'm sorry, I forgot the code. I list the existing method, >>>>> followed by my modified Pharo method below. I welcome any
feedback.
>>>>> >>>>> Regards, >>>>> Robert >>>>> >>>>> --- >>>>> Existing: >>>>> unpredictableStringsDo: aBlock >>>>> "Enumerate sources of information from my environment >>>>> that > > should >>>>> >>>>> be generally hard to guess." >>>>> | time | >>>>> time := Time millisecondsToRun: >>>>> [ aBlock >>>>> value: World imageForm bits >>>>> compressToByteArray ; >>>>> value: Sensor mousePoint x asString ; >>>>> value: Sensor mousePoint y asString ; >>>>> value: Time millisecondClockValue >>>>> asByteArray ; >>>>> value: Date today asString ; >>>>> value: Time now asString ; >>>>> value: Display extent asString. >>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>> #(vmVersion platformName primVmPath imageName > > platformSubtype >>>>> >>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>> imageName) >>>>> collect: >>>>> [ : each | >>>>> aBlock value: (SmalltalkImage current >>>>> perform: each) > > asByteArray >>>>> >>>>> ] ]. >>>>> aBlock >>>>> value: time asByteArray; >>>>> "maybe the pointer has moved, hit it again." >>>>> value: Sensor mousePoint asString ; >>>>> value: Time millisecondClockValue asByteArray >>>>> >>>>> --- >>>>> Pharo port: >>>>> unpredictableStringsDo: aBlock >>>>> "Enumerate sources of information from my environment >>>>> that > > should >>>>> >>>>> be generally hard to guess." >>>>> >>>>> | time | >>>>> time := Time millisecondsToRun: >>>>> [ aBlock >>>>> value: Time millisecondClockValue >>>>> asByteArray ; >>>>> value: Date today asString ; >>>>> value: Time now asString. >>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>> #(version primImagePath imagePath >>>>> datedVersion >>>>> lastQuitLogPosition) >>>>> collect: >>>>> [ : each | >>>>> aBlock value: (SmalltalkImage current >>>>> perform: each) > > asByteArray >>>>> >>>>> ] ]. >>>>> aBlock >>>>> value: time asByteArray; >>>>> value: Time millisecondClockValue asByteArray >>>>> >>>>> >>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>> >>>>>> This is a message intended for anyone who was on the >>>>>> Cryptography > > team. >>>>>> >>>>>> I recently ported it to Pharo and had to make changes to >>>>> >>>>> RandomGenerator >>>>>> >>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>> class>>uncertainty >>>>>> from the results of this message. My question is what should >>>>>> I do about that? This method seems to require non-headless, >>>>>> as it is checking the mouse point and such. This being a >>>>>> crypto cornerstone, what the best answer here. >>>>>> >>>>>> Thank you, >>>>>> Robert >>>> >>>> >>>> >>>> >>> >> ----------------------------------------------------------- >> Louis LaBrunda >> Keystone Software Corp. >> SkypeMe callto://PhotonDemon >> mailto:Lou@Keystone-Software.com http://www.Keystone-
Software.com
>> >>
Hi Robert,
I went back and reviewed and this is what I sent to BIS.
http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/000117...
Not much to it but we got a lot of advice from SFLC first.
From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm
I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 5:28 PM To: The general-purpose Squeak developers list; 'Chris Muller' Cc: 'Pharo Development List' Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is
hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote:
hey Ron,
It was actually the Pharo Cryptography team I was thinking of. Perhaps we can get the same package to work in both squeak and Pharo, with use of installable entropy sources or the like. In order to get SqueakElib running in Pharo I need crypto and we may as
well do it right.
Cheers, Robert
On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: > > Hi Robert, > > You are already on the Cryptograph repo on SqueakSource.com as an
admin.
> Please feel free to reorg if you like. > > Let me know if you have trouble resurrecting your account. > > All the best, > > Ron > >> -----Original Message----- >> From: squeak-dev-bounces@lists.squeakfoundation.org >> [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On >> Behalf Of Robert Withers >> Sent: Monday, October 19, 2015 1:53 PM >> To: squeak-dev@lists.squeakfoundation.org >> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >> Pharo] RandomGenerator class>>unpredictableStringsDo: >> >> This is great guys. Is there a way to get this from the image? >> Good to get > > it >> >> with an FFI/OSProcess call or something. >> >> Thank you, >> Robert >> >> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>> >>> Hi Guys, >>> >>> How about getting the CPU temperature. I think most CPUs >>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>> think it is seven bits. The real range should be less than >>> that but it may be enough to help add some entropy. >>> >>> Lou >>> >>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>> robert.w.withers@gmail.com wrote: >>> >>>> Hi Ron , nice to see you too! It has been a number of years, >>>> hasn't
it?
>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>> these have been kind years to you, as they have for me. >>>> >>>> I love the idea of optional sources of entropy, depending on >>>> the deployed capabilities. So there are our mouse points and >>>> such, because they ought to be optional. >>>> >>>> What are some reliably present sources in the most minimal
situation?
>>>> If we could define minimal as an image with no image level I/O >>>> beyond file I/O, I would think we'd have: Kernel, System, >>>> Collections, Compiler and FFI. Some intransitives in that >>>> scope for entropy would be >> >> grand. >>>> >>>> >>>> I was thinking to take 5 millisecondClockValues, separated by >>>> 4 non-secure random intervals: take the low order byte of the >>>> 4 intervals and reverse & concat them, as a entropic source. >>>> >>>> I can coordinate these changes. Ron, could you add me to the >>>> Cryptography team so I can upload the Pharo Cryptography >> >> #bleedingEdge? >>>> >>>> >>>> Thanks and I look forward to more, :) >>>> >>>> Robert >>>> >>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>> >>>>> Hi Robert, >>>>> >>>>> Nice to see you! >>>>> >>>>> Looks interesting I know that Chris did something gathering >>>>> sources of >> >> entropy. Seems like the more the better. Could you just make >> the entropy sources optional such that if they exist we use them? >> I would have to go back and see what Chris did but he was >> following suggestions from Schneider in his secureRandom. >>>>> >>>>> >>>>> All the best, >>>>> >>>>> Ron Teitelbaum >>>>> >>>>>> -----Original Message----- >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] >>>>>> On Behalf Of Robert Withers >>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>> Development List >>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>> RandomGenerator >>>>>> class>>unpredictableStringsDo: >>>>>> >>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>> followed by my modified Pharo method below. I welcome any
feedback.
>>>>>> >>>>>> Regards, >>>>>> Robert >>>>>> >>>>>> --- >>>>>> Existing: >>>>>> unpredictableStringsDo: aBlock >>>>>> "Enumerate sources of information from my >>>>>> environment that >> >> should >>>>>> >>>>>> be generally hard to guess." >>>>>> | time | >>>>>> time := Time millisecondsToRun: >>>>>> [ aBlock >>>>>> value: World imageForm bits >>>>>> compressToByteArray ; >>>>>> value: Sensor mousePoint x asString ; >>>>>> value: Sensor mousePoint y asString ; >>>>>> value: Time millisecondClockValue >>>>>> asByteArray ; >>>>>> value: Date today asString ; >>>>>> value: Time now asString ; >>>>>> value: Display extent asString. >>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>> #(vmVersion platformName primVmPath >>>>>> imageName >> >> platformSubtype >>>>>> >>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>> imageName) >>>>>> collect: >>>>>> [ : each | >>>>>> aBlock value: (SmalltalkImage >>>>>> current >>>>>> perform: each) >> >> asByteArray >>>>>> >>>>>> ] ]. >>>>>> aBlock >>>>>> value: time asByteArray; >>>>>> "maybe the pointer has moved, hit it again." >>>>>> value: Sensor mousePoint asString ; >>>>>> value: Time millisecondClockValue >>>>>> asByteArray >>>>>> >>>>>> --- >>>>>> Pharo port: >>>>>> unpredictableStringsDo: aBlock >>>>>> "Enumerate sources of information from my >>>>>> environment that >> >> should >>>>>> >>>>>> be generally hard to guess." >>>>>> >>>>>> | time | >>>>>> time := Time millisecondsToRun: >>>>>> [ aBlock >>>>>> value: Time millisecondClockValue >>>>>> asByteArray ; >>>>>> value: Date today asString ; >>>>>> value: Time now asString. >>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>> #(version primImagePath imagePath >>>>>> datedVersion >>>>>> lastQuitLogPosition) >>>>>> collect: >>>>>> [ : each | >>>>>> aBlock value: (SmalltalkImage >>>>>> current >>>>>> perform: each) >> >> asByteArray >>>>>> >>>>>> ] ]. >>>>>> aBlock >>>>>> value: time asByteArray; >>>>>> value: Time millisecondClockValue >>>>>> asByteArray >>>>>> >>>>>> >>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>> >>>>>>> This is a message intended for anyone who was on the >>>>>>> Cryptography >> >> team. >>>>>>> >>>>>>> I recently ported it to Pharo and had to make changes to >>>>>> >>>>>> RandomGenerator >>>>>>> >>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>> class>>uncertainty >>>>>>> from the results of this message. My question is what >>>>>>> should I do about that? This method seems to require >>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>> This being a crypto cornerstone, what the best answer here. >>>>>>> >>>>>>> Thank you, >>>>>>> Robert >>>>> >>>>> >>>>> >>>>> >>>> >>> ----------------------------------------------------------- >>> Louis LaBrunda >>> Keystone Software Corp. >>> SkypeMe callto://PhotonDemon >>> mailto:Lou@Keystone-Software.com http://www.Keystone-
Software.com
>>> >>> > > >
Thank you for you research and advise on how to make it right, Ron. I may look into it, but I don't want to promise you that I will definitely. I will certainly put this in my crypto folder, though. :)
... ^^ robert
On 10/19/2015 06:25 PM, Ron Teitelbaum wrote:
Hi Robert,
I went back and reviewed and this is what I sent to BIS.
http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/000117...
Not much to it but we got a lot of advice from SFLC first.
From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm
I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 5:28 PM To: The general-purpose Squeak developers list; 'Chris Muller' Cc: 'Pharo Development List' Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is
hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote: > hey Ron, > > It was actually the Pharo Cryptography team I was thinking of. > Perhaps we can get the same package to work in both squeak and > Pharo, with use of installable entropy sources or the like. In > order to get SqueakElib running in Pharo I need crypto and we may > as
well do it right.
> > Cheers, > Robert > > > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >> >> Hi Robert, >> >> You are already on the Cryptograph repo on SqueakSource.com as an admin. >> Please feel free to reorg if you like. >> >> Let me know if you have trouble resurrecting your account. >> >> All the best, >> >> Ron >> >>> -----Original Message----- >>> From: squeak-dev-bounces@lists.squeakfoundation.org >>> [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On >>> Behalf Of Robert Withers >>> Sent: Monday, October 19, 2015 1:53 PM >>> To: squeak-dev@lists.squeakfoundation.org >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>> >>> This is great guys. Is there a way to get this from the image? >>> Good to get >> >> it >>> >>> with an FFI/OSProcess call or something. >>> >>> Thank you, >>> Robert >>> >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>> >>>> Hi Guys, >>>> >>>> How about getting the CPU temperature. I think most CPUs >>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>> think it is seven bits. The real range should be less than >>>> that but it may be enough to help add some entropy. >>>> >>>> Lou >>>> >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>> robert.w.withers@gmail.com wrote: >>>> >>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>> hasn't
it?
>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>> these have been kind years to you, as they have for me. >>>>> >>>>> I love the idea of optional sources of entropy, depending on >>>>> the deployed capabilities. So there are our mouse points and >>>>> such, because they ought to be optional. >>>>> >>>>> What are some reliably present sources in the most minimal situation? >>>>> If we could define minimal as an image with no image level I/O >>>>> beyond file I/O, I would think we'd have: Kernel, System, >>>>> Collections, Compiler and FFI. Some intransitives in that >>>>> scope for entropy would be >>> >>> grand. >>>>> >>>>> >>>>> I was thinking to take 5 millisecondClockValues, separated by >>>>> 4 non-secure random intervals: take the low order byte of the >>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>> >>>>> I can coordinate these changes. Ron, could you add me to the >>>>> Cryptography team so I can upload the Pharo Cryptography >>> >>> #bleedingEdge? >>>>> >>>>> >>>>> Thanks and I look forward to more, :) >>>>> >>>>> Robert >>>>> >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>> >>>>>> Hi Robert, >>>>>> >>>>>> Nice to see you! >>>>>> >>>>>> Looks interesting I know that Chris did something gathering >>>>>> sources of >>> >>> entropy. Seems like the more the better. Could you just make >>> the entropy sources optional such that if they exist we use them? >>> I would have to go back and see what Chris did but he was >>> following suggestions from Schneider in his secureRandom. >>>>>> >>>>>> >>>>>> All the best, >>>>>> >>>>>> Ron Teitelbaum >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] >>>>>>> On Behalf Of Robert Withers >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>> Development List >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>> RandomGenerator >>>>>>> class>>unpredictableStringsDo: >>>>>>> >>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>> followed by my modified Pharo method below. I welcome any feedback. >>>>>>> >>>>>>> Regards, >>>>>>> Robert >>>>>>> >>>>>>> --- >>>>>>> Existing: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my >>>>>>> environment that >>> >>> should >>>>>>> >>>>>>> be generally hard to guess." >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: World imageForm bits >>>>>>> compressToByteArray ; >>>>>>> value: Sensor mousePoint x asString ; >>>>>>> value: Sensor mousePoint y asString ; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString ; >>>>>>> value: Display extent asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(vmVersion platformName primVmPath >>>>>>> imageName >>> >>> platformSubtype >>>>>>> >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>> imageName) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage >>>>>>> current >>>>>>> perform: each) >>> >>> asByteArray >>>>>>> >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> "maybe the pointer has moved, hit it again." >>>>>>> value: Sensor mousePoint asString ; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray >>>>>>> >>>>>>> --- >>>>>>> Pharo port: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my >>>>>>> environment that >>> >>> should >>>>>>> >>>>>>> be generally hard to guess." >>>>>>> >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(version primImagePath imagePath >>>>>>> datedVersion >>>>>>> lastQuitLogPosition) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage >>>>>>> current >>>>>>> perform: each) >>> >>> asByteArray >>>>>>> >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray >>>>>>> >>>>>>> >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>> >>>>>>>> This is a message intended for anyone who was on the >>>>>>>> Cryptography >>> >>> team. >>>>>>>> >>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>> >>>>>>> RandomGenerator >>>>>>>> >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>> class>>uncertainty >>>>>>>> from the results of this message. My question is what >>>>>>>> should I do about that? This method seems to require >>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>> This being a crypto cornerstone, what the best answer here. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Robert >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> ----------------------------------------------------------- >>>> Louis LaBrunda >>>> Keystone Software Corp. >>>> SkypeMe callto://PhotonDemon >>>> mailto:Lou@Keystone-Software.com http://www.Keystone- Software.com >>>> >>>> >> >> >> >
Thank you Ron, I'll look into it.
Regards,
... ^^ robert
On 10/19/2015 06:25 PM, Ron Teitelbaum wrote:
Hi Robert,
I went back and reviewed and this is what I sent to BIS.
http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/000117...
Not much to it but we got a lot of advice from SFLC first.
From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm
I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 5:28 PM To: The general-purpose Squeak developers list; 'Chris Muller' Cc: 'Pharo Development List' Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is
hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote: > hey Ron, > > It was actually the Pharo Cryptography team I was thinking of. > Perhaps we can get the same package to work in both squeak and > Pharo, with use of installable entropy sources or the like. In > order to get SqueakElib running in Pharo I need crypto and we may > as
well do it right.
> > Cheers, > Robert > > > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >> >> Hi Robert, >> >> You are already on the Cryptograph repo on SqueakSource.com as an admin. >> Please feel free to reorg if you like. >> >> Let me know if you have trouble resurrecting your account. >> >> All the best, >> >> Ron >> >>> -----Original Message----- >>> From: squeak-dev-bounces@lists.squeakfoundation.org >>> [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On >>> Behalf Of Robert Withers >>> Sent: Monday, October 19, 2015 1:53 PM >>> To: squeak-dev@lists.squeakfoundation.org >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>> >>> This is great guys. Is there a way to get this from the image? >>> Good to get >> >> it >>> >>> with an FFI/OSProcess call or something. >>> >>> Thank you, >>> Robert >>> >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>> >>>> Hi Guys, >>>> >>>> How about getting the CPU temperature. I think most CPUs >>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>> think it is seven bits. The real range should be less than >>>> that but it may be enough to help add some entropy. >>>> >>>> Lou >>>> >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>> robert.w.withers@gmail.com wrote: >>>> >>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>> hasn't
it?
>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>> these have been kind years to you, as they have for me. >>>>> >>>>> I love the idea of optional sources of entropy, depending on >>>>> the deployed capabilities. So there are our mouse points and >>>>> such, because they ought to be optional. >>>>> >>>>> What are some reliably present sources in the most minimal situation? >>>>> If we could define minimal as an image with no image level I/O >>>>> beyond file I/O, I would think we'd have: Kernel, System, >>>>> Collections, Compiler and FFI. Some intransitives in that >>>>> scope for entropy would be >>> >>> grand. >>>>> >>>>> >>>>> I was thinking to take 5 millisecondClockValues, separated by >>>>> 4 non-secure random intervals: take the low order byte of the >>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>> >>>>> I can coordinate these changes. Ron, could you add me to the >>>>> Cryptography team so I can upload the Pharo Cryptography >>> >>> #bleedingEdge? >>>>> >>>>> >>>>> Thanks and I look forward to more, :) >>>>> >>>>> Robert >>>>> >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>> >>>>>> Hi Robert, >>>>>> >>>>>> Nice to see you! >>>>>> >>>>>> Looks interesting I know that Chris did something gathering >>>>>> sources of >>> >>> entropy. Seems like the more the better. Could you just make >>> the entropy sources optional such that if they exist we use them? >>> I would have to go back and see what Chris did but he was >>> following suggestions from Schneider in his secureRandom. >>>>>> >>>>>> >>>>>> All the best, >>>>>> >>>>>> Ron Teitelbaum >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] >>>>>>> On Behalf Of Robert Withers >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>> Development List >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>> RandomGenerator >>>>>>> class>>unpredictableStringsDo: >>>>>>> >>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>> followed by my modified Pharo method below. I welcome any feedback. >>>>>>> >>>>>>> Regards, >>>>>>> Robert >>>>>>> >>>>>>> --- >>>>>>> Existing: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my >>>>>>> environment that >>> >>> should >>>>>>> >>>>>>> be generally hard to guess." >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: World imageForm bits >>>>>>> compressToByteArray ; >>>>>>> value: Sensor mousePoint x asString ; >>>>>>> value: Sensor mousePoint y asString ; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString ; >>>>>>> value: Display extent asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(vmVersion platformName primVmPath >>>>>>> imageName >>> >>> platformSubtype >>>>>>> >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>> imageName) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage >>>>>>> current >>>>>>> perform: each) >>> >>> asByteArray >>>>>>> >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> "maybe the pointer has moved, hit it again." >>>>>>> value: Sensor mousePoint asString ; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray >>>>>>> >>>>>>> --- >>>>>>> Pharo port: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my >>>>>>> environment that >>> >>> should >>>>>>> >>>>>>> be generally hard to guess." >>>>>>> >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(version primImagePath imagePath >>>>>>> datedVersion >>>>>>> lastQuitLogPosition) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage >>>>>>> current >>>>>>> perform: each) >>> >>> asByteArray >>>>>>> >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray >>>>>>> >>>>>>> >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>> >>>>>>>> This is a message intended for anyone who was on the >>>>>>>> Cryptography >>> >>> team. >>>>>>>> >>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>> >>>>>>> RandomGenerator >>>>>>>> >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>> class>>uncertainty >>>>>>>> from the results of this message. My question is what >>>>>>>> should I do about that? This method seems to require >>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>> This being a crypto cornerstone, what the best answer here. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Robert >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> ----------------------------------------------------------- >>>> Louis LaBrunda >>>> Keystone Software Corp. >>>> SkypeMe callto://PhotonDemon >>>> mailto:Lou@Keystone-Software.com http://www.Keystone- Software.com >>>> >>>> >> >> >> >
Ron,
I checked that email and there is no mention of who it was sent to now this SFLC advisors. Ok that must be the Software Freedom Law Center. I just reached out to them on this.
Thank you, Robert
On 10/19/2015 06:25 PM, Ron Teitelbaum wrote:
Hi Robert,
I went back and reviewed and this is what I sent to BIS.
http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/000117...
Not much to it but we got a lot of advice from SFLC first.
From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm
I would recommend at the very least to register the repo with the BIS for Pharo, but I would also contact the SFLC to verify nothing has changed.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 5:28 PM To: The general-purpose Squeak developers list; 'Chris Muller' Cc: 'Pharo Development List' Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is
hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum ron@usmedrec.com wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Chris Muller Sent: Monday, October 19, 2015 2:47 PM To: The general-purpose Squeak developers list Cc: Pharo Development List Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Yes, if a common package for both Squeak and Pharo is possible, that'd be great. Otherwise, the Squeak and Pharo versions should reside in separate repositories. Squeak users are still using squeaksource.com, Pharo moved to smalltalkhub and beyond..
On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers robert.w.withers@gmail.com wrote: > hey Ron, > > It was actually the Pharo Cryptography team I was thinking of. > Perhaps we can get the same package to work in both squeak and > Pharo, with use of installable entropy sources or the like. In > order to get SqueakElib running in Pharo I need crypto and we may > as
well do it right.
> Cheers, > Robert > > > On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >> Hi Robert, >> >> You are already on the Cryptograph repo on SqueakSource.com as an admin. >> Please feel free to reorg if you like. >> >> Let me know if you have trouble resurrecting your account. >> >> All the best, >> >> Ron >> >>> -----Original Message----- >>> From: squeak-dev-bounces@lists.squeakfoundation.org >>> [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On >>> Behalf Of Robert Withers >>> Sent: Monday, October 19, 2015 1:53 PM >>> To: squeak-dev@lists.squeakfoundation.org >>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>> >>> This is great guys. Is there a way to get this from the image? >>> Good to get >> it >>> with an FFI/OSProcess call or something. >>> >>> Thank you, >>> Robert >>> >>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>> Hi Guys, >>>> >>>> How about getting the CPU temperature. I think most CPUs >>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>> think it is seven bits. The real range should be less than >>>> that but it may be enough to help add some entropy. >>>> >>>> Lou >>>> >>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>> robert.w.withers@gmail.com wrote: >>>> >>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>> hasn't
it?
>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>> these have been kind years to you, as they have for me. >>>>> >>>>> I love the idea of optional sources of entropy, depending on >>>>> the deployed capabilities. So there are our mouse points and >>>>> such, because they ought to be optional. >>>>> >>>>> What are some reliably present sources in the most minimal situation? >>>>> If we could define minimal as an image with no image level I/O >>>>> beyond file I/O, I would think we'd have: Kernel, System, >>>>> Collections, Compiler and FFI. Some intransitives in that >>>>> scope for entropy would be >>> grand. >>>>> >>>>> I was thinking to take 5 millisecondClockValues, separated by >>>>> 4 non-secure random intervals: take the low order byte of the >>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>> >>>>> I can coordinate these changes. Ron, could you add me to the >>>>> Cryptography team so I can upload the Pharo Cryptography >>> #bleedingEdge? >>>>> >>>>> Thanks and I look forward to more, :) >>>>> >>>>> Robert >>>>> >>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>> Hi Robert, >>>>>> >>>>>> Nice to see you! >>>>>> >>>>>> Looks interesting I know that Chris did something gathering >>>>>> sources of >>> entropy. Seems like the more the better. Could you just make >>> the entropy sources optional such that if they exist we use them? >>> I would have to go back and see what Chris did but he was >>> following suggestions from Schneider in his secureRandom. >>>>>> >>>>>> All the best, >>>>>> >>>>>> Ron Teitelbaum >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] >>>>>>> On Behalf Of Robert Withers >>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>> Development List >>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>> RandomGenerator >>>>>>> class>>unpredictableStringsDo: >>>>>>> >>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>> followed by my modified Pharo method below. I welcome any feedback. >>>>>>> Regards, >>>>>>> Robert >>>>>>> >>>>>>> --- >>>>>>> Existing: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my >>>>>>> environment that >>> should >>>>>>> be generally hard to guess." >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: World imageForm bits >>>>>>> compressToByteArray ; >>>>>>> value: Sensor mousePoint x asString ; >>>>>>> value: Sensor mousePoint y asString ; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString ; >>>>>>> value: Display extent asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(vmVersion platformName primVmPath >>>>>>> imageName >>> platformSubtype >>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>> imageName) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage >>>>>>> current >>>>>>> perform: each) >>> asByteArray >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> "maybe the pointer has moved, hit it again." >>>>>>> value: Sensor mousePoint asString ; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray >>>>>>> >>>>>>> --- >>>>>>> Pharo port: >>>>>>> unpredictableStringsDo: aBlock >>>>>>> "Enumerate sources of information from my >>>>>>> environment that >>> should >>>>>>> be generally hard to guess." >>>>>>> >>>>>>> | time | >>>>>>> time := Time millisecondsToRun: >>>>>>> [ aBlock >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray ; >>>>>>> value: Date today asString ; >>>>>>> value: Time now asString. >>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>> #(version primImagePath imagePath >>>>>>> datedVersion >>>>>>> lastQuitLogPosition) >>>>>>> collect: >>>>>>> [ : each | >>>>>>> aBlock value: (SmalltalkImage >>>>>>> current >>>>>>> perform: each) >>> asByteArray >>>>>>> ] ]. >>>>>>> aBlock >>>>>>> value: time asByteArray; >>>>>>> value: Time millisecondClockValue >>>>>>> asByteArray >>>>>>> >>>>>>> >>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>> This is a message intended for anyone who was on the >>>>>>>> Cryptography >>> team. >>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>> RandomGenerator >>>>>>>> class>>unpredictableStringsDo:. This certainly removed some >>>>>>>> class>>uncertainty >>>>>>>> from the results of this message. My question is what >>>>>>>> should I do about that? This method seems to require >>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>> This being a crypto cornerstone, what the best answer here. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Robert >>>>>> >>>>>> >>>>>> >>>> ----------------------------------------------------------- >>>> Louis LaBrunda >>>> Keystone Software Corp. >>>> SkypeMe callto://PhotonDemon >>>> mailto:Lou@Keystone-Software.com http://www.Keystone- Software.com >>>> >> >>
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Ron,
I checked that email and there is no mention of who it was sent to now this SFLC advisors. Ok that must be the Software Freedom Law Center. I just reached out to them on this.
[Ron Teitelbaum] It was set to Dan Ravicher but not sure if he is still there.
http://lists.squeakfoundation.org/pipermail/cryptography/2005-November/00008...
Thank you, Robert
On 10/19/2015 06:25 PM, Ron Teitelbaum wrote:
Hi Robert,
I went back and reviewed and this is what I sent to BIS.
http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/ 000117.html
Not much to it but we got a lot of advice from SFLC first.
From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm
I would recommend at the very least to register the repo with the BIS for
Pharo, but I would also contact the SFLC to verify nothing has changed.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 5:28 PM To: The general-purpose Squeak developers list; 'Chris Muller' Cc: 'Pharo Development List' Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a
lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission
later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is
hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple
packages hosted there.
It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum
wrote:
Hi All,
Unless someone filed the proper paperwork I would suggest NOT moving
the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository.
I'm not personally involved with the code on Pharo, not sure who is doing
crypto there.
All the best,
Ron
> -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > Behalf Of Chris Muller > Sent: Monday, October 19, 2015 2:47 PM > To: The general-purpose Squeak developers list > Cc: Pharo Development List > Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to > Pharo] RandomGenerator class>>unpredictableStringsDo: > > Yes, if a common package for both Squeak and Pharo is possible, > that'd be great. Otherwise, the Squeak and Pharo versions should > reside in separate repositories. Squeak users are still using > squeaksource.com, Pharo moved to smalltalkhub and beyond.. > > On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers > robert.w.withers@gmail.com wrote: >> hey Ron, >> >> It was actually the Pharo Cryptography team I was thinking of. >> Perhaps we can get the same package to work in both squeak and >> Pharo, with use of installable entropy sources or the like. In >> order to get SqueakElib running in Pharo I need crypto and we >> may as
well do it right.
>> Cheers, >> Robert >> >> >> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >>> Hi Robert, >>> >>> You are already on the Cryptograph repo on SqueakSource.com as >>> an > admin. >>> Please feel free to reorg if you like. >>> >>> Let me know if you have trouble resurrecting your account. >>> >>> All the best, >>> >>> Ron >>> >>>> -----Original Message----- >>>> From: squeak-dev-bounces@lists.squeakfoundation.org >>>> [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On >>>> Behalf Of Robert Withers >>>> Sent: Monday, October 19, 2015 1:53 PM >>>> To: squeak-dev@lists.squeakfoundation.org >>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>>> >>>> This is great guys. Is there a way to get this from the image? >>>> Good to get >>> it >>>> with an FFI/OSProcess call or something. >>>> >>>> Thank you, >>>> Robert >>>> >>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>>> Hi Guys, >>>>> >>>>> How about getting the CPU temperature. I think most CPUs >>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>>> think it is seven bits. The real range should be less than >>>>> that but it may be enough to help add some entropy. >>>>> >>>>> Lou >>>>> >>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>>> robert.w.withers@gmail.com wrote: >>>>> >>>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>>> hasn't
it?
>>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>>> these have been kind years to you, as they have for me. >>>>>> >>>>>> I love the idea of optional sources of entropy, depending on >>>>>> the deployed capabilities. So there are our mouse points and >>>>>> such, because they ought to be optional. >>>>>> >>>>>> What are some reliably present sources in the most minimal > situation? >>>>>> If we could define minimal as an image with no image level >>>>>> I/O beyond file I/O, I would think we'd have: Kernel, >>>>>> System, Collections, Compiler and FFI. Some intransitives in >>>>>> that scope for entropy would be >>>> grand. >>>>>> >>>>>> I was thinking to take 5 millisecondClockValues, separated >>>>>> by >>>>>> 4 non-secure random intervals: take the low order byte of >>>>>> the >>>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>>> >>>>>> I can coordinate these changes. Ron, could you add me to the >>>>>> Cryptography team so I can upload the Pharo Cryptography >>>> #bleedingEdge? >>>>>> >>>>>> Thanks and I look forward to more, :) >>>>>> >>>>>> Robert >>>>>> >>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>>> Hi Robert, >>>>>>> >>>>>>> Nice to see you! >>>>>>> >>>>>>> Looks interesting I know that Chris did something gathering >>>>>>> sources of >>>> entropy. Seems like the more the better. Could you just make >>>> the entropy sources optional such that if they exist we use them? >>>> I would have to go back and see what Chris did but he was >>>> following suggestions from Schneider in his secureRandom. >>>>>>> >>>>>>> All the best, >>>>>>> >>>>>>> Ron Teitelbaum >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Pharo-dev [mailto:pharo-dev-
bounces@lists.pharo.org]
>>>>>>>> On Behalf Of Robert Withers >>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>>> Development List >>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>>> RandomGenerator >>>>>>>> class>>unpredictableStringsDo: >>>>>>>> >>>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>>> followed by my modified Pharo method below. I welcome
any
> feedback. >>>>>>>> Regards, >>>>>>>> Robert >>>>>>>> >>>>>>>> --- >>>>>>>> Existing: >>>>>>>> unpredictableStringsDo: aBlock >>>>>>>> "Enumerate sources of information from my >>>>>>>> environment that >>>> should >>>>>>>> be generally hard to guess." >>>>>>>> | time | >>>>>>>> time := Time millisecondsToRun: >>>>>>>> [ aBlock >>>>>>>> value: World imageForm bits >>>>>>>> compressToByteArray ; >>>>>>>> value: Sensor mousePoint x asString ; >>>>>>>> value: Sensor mousePoint y asString ; >>>>>>>> value: Time >>>>>>>> millisecondClockValue asByteArray ; >>>>>>>> value: Date today asString ; >>>>>>>> value: Time now asString ; >>>>>>>> value: Display extent asString. >>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>> #(vmVersion platformName primVmPath >>>>>>>> imageName >>>> platformSubtype >>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>>> imageName) >>>>>>>> collect: >>>>>>>> [ : each | >>>>>>>> aBlock value: (SmalltalkImage >>>>>>>> current >>>>>>>> perform: each) >>>> asByteArray >>>>>>>> ] ]. >>>>>>>> aBlock >>>>>>>> value: time asByteArray; >>>>>>>> "maybe the pointer has moved, hit it again." >>>>>>>> value: Sensor mousePoint asString ; >>>>>>>> value: Time millisecondClockValue >>>>>>>> asByteArray >>>>>>>> >>>>>>>> --- >>>>>>>> Pharo port: >>>>>>>> unpredictableStringsDo: aBlock >>>>>>>> "Enumerate sources of information from my >>>>>>>> environment that >>>> should >>>>>>>> be generally hard to guess." >>>>>>>> >>>>>>>> | time | >>>>>>>> time := Time millisecondsToRun: >>>>>>>> [ aBlock >>>>>>>> value: Time >>>>>>>> millisecondClockValue asByteArray ; >>>>>>>> value: Date today asString ; >>>>>>>> value: Time now asString. >>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>> #(version primImagePath imagePath >>>>>>>> datedVersion >>>>>>>> lastQuitLogPosition) >>>>>>>> collect: >>>>>>>> [ : each | >>>>>>>> aBlock value: (SmalltalkImage >>>>>>>> current >>>>>>>> perform: each) >>>> asByteArray >>>>>>>> ] ]. >>>>>>>> aBlock >>>>>>>> value: time asByteArray; >>>>>>>> value: Time millisecondClockValue >>>>>>>> asByteArray >>>>>>>> >>>>>>>> >>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>>> This is a message intended for anyone who was on the >>>>>>>>> Cryptography >>>> team. >>>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>>> RandomGenerator >>>>>>>>> class>>unpredictableStringsDo:. This certainly removed >>>>>>>>> class>>some uncertainty >>>>>>>>> from the results of this message. My question is what >>>>>>>>> should I do about that? This method seems to require >>>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>>> This being a crypto cornerstone, what the best answer
here.
>>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> >>>>> ----------------------------------------------------------- >>>>> Louis LaBrunda >>>>> Keystone Software Corp. >>>>> SkypeMe callto://PhotonDemon >>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- > Software.com >>>>> >>> >>>
Thanks for the link and the name, Ron. When SFLC get back to me I will mention Dan's involvement.
Best, Robert
On 10/20/2015 10:23 PM, Ron Teitelbaum wrote:
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Ron,
I checked that email and there is no mention of who it was sent to now this SFLC advisors. Ok that must be the Software Freedom Law Center. I just reached out to them on this.
[Ron Teitelbaum] It was set to Dan Ravicher but not sure if he is still there.
http://lists.squeakfoundation.org/pipermail/cryptography/2005-November/00008...
Thank you, Robert
On 10/19/2015 06:25 PM, Ron Teitelbaum wrote:
Hi Robert,
I went back and reviewed and this is what I sent to BIS.
http://lists.squeakfoundation.org/pipermail/cryptography/2006-January/ 000117.html
Not much to it but we got a lot of advice from SFLC first.
From our research OS projects are allowed to host cryptographic code and make available for anyone to download. BUT that does not exclude users of the code from being restrained from exporting that code to any USA identified restricted entities. For example: http://www.state.gov/j/ct/list/c14151.htm
I would recommend at the very least to register the repo with the BIS for
Pharo, but I would also contact the SFLC to verify nothing has changed.
All the best,
Ron
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers Sent: Monday, October 19, 2015 5:28 PM To: The general-purpose Squeak developers list; 'Chris Muller' Cc: 'Pharo Development List' Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
(resending with Pharo list)
Ron, would it be an easy process to add a second URL to the exception paperwork. Pharo does have new ideas about code storage and distribution that we would want to take advantage of. This would help a
lot!
Then again, screw their paperwork requirements of us. Put my name as responsible on the Pharo code and I'll take a trip to Cuba, if they need a scape goat for their 20th century thinking. Crypto is already out of the bag and everyone uses it freely. Just do it and ask permission
later.
In thinking about consolidating crypto code between squeak and pharo, I would guess there would be a thin capatibility layer for each system, then the Crypto code in the main. My goal is to have compatibility, crypto and plugins on both virtual platforms.
Thanks so much ^^
Robert
On 10/19/2015 05:17 PM, Ron Teitelbaum wrote:
Hi Chris,
The exemption is not for the location of the server but the URL where it is
hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple
packages hosted there.
It's ok with me if we host some pharo code there too.
All the best,
Ron
-----Original Message----- From: Chris Muller [mailto:ma.chris.m@gmail.com] Sent: Monday, October 19, 2015 3:59 PM To: Ron Teitelbaum Cc: Pharo Development List; The general-purpose Squeak developers list Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to Pharo] RandomGenerator class>>unpredictableStringsDo:
Heh, well, since then SqueakSource itself was moved to a different server in a different country. I guess there was also a mirror of SqueakSource hosted in Chile under a different URL for many years.
I'm doubtful any of it matters, but we wouldn't want anyone to end up in Gitmo over it. If you're uncomfortable about hosting a copy elsewhere, then please at least namespace-prefix the Pharo-specific packages, to at least help keep it from becoming a tangled mess.
On Mon, Oct 19, 2015 at 2:39 PM, Ron Teitelbaum
wrote: > Hi All, > > Unless someone filed the proper paperwork I would suggest NOT > moving the cryptography code anywhere except for SqueakSource. When we started the project we spent time ensuring that we had a proper exemption from the U.S. regulations on exporting cryptographic code. If someone copied and forked the code that exemption may not still apply to that new repository. > I'm not personally involved with the code on Pharo, not sure who > is doing crypto there. > All the best, > > Ron > >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >> Behalf Of Chris Muller >> Sent: Monday, October 19, 2015 2:47 PM >> To: The general-purpose Squeak developers list >> Cc: Pharo Development List >> Subject: Re: [Pharo-dev] [squeak-dev] [Cryptography port to >> Pharo] RandomGenerator class>>unpredictableStringsDo: >> >> Yes, if a common package for both Squeak and Pharo is possible, >> that'd be great. Otherwise, the Squeak and Pharo versions should >> reside in separate repositories. Squeak users are still using >> squeaksource.com, Pharo moved to smalltalkhub and beyond.. >> >> On Mon, Oct 19, 2015 at 1:42 PM, Robert Withers >> robert.w.withers@gmail.com wrote: >>> hey Ron, >>> >>> It was actually the Pharo Cryptography team I was thinking of. >>> Perhaps we can get the same package to work in both squeak and >>> Pharo, with use of installable entropy sources or the like. In >>> order to get SqueakElib running in Pharo I need crypto and we >>> may as well do it right. >>> Cheers, >>> Robert >>> >>> >>> On 10/19/2015 02:28 PM, Ron Teitelbaum wrote: >>>> Hi Robert, >>>> >>>> You are already on the Cryptograph repo on SqueakSource.com as >>>> an >> admin. >>>> Please feel free to reorg if you like. >>>> >>>> Let me know if you have trouble resurrecting your account. >>>> >>>> All the best, >>>> >>>> Ron >>>> >>>>> -----Original Message----- >>>>> From: squeak-dev-bounces@lists.squeakfoundation.org >>>>> [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On >>>>> Behalf Of Robert Withers >>>>> Sent: Monday, October 19, 2015 1:53 PM >>>>> To: squeak-dev@lists.squeakfoundation.org >>>>> Subject: Re: [squeak-dev] [Pharo-dev] [Cryptography port to >>>>> Pharo] RandomGenerator class>>unpredictableStringsDo: >>>>> >>>>> This is great guys. Is there a way to get this from the image? >>>>> Good to get >>>> it >>>>> with an FFI/OSProcess call or something. >>>>> >>>>> Thank you, >>>>> Robert >>>>> >>>>> On 10/19/2015 08:58 AM, Louis LaBrunda wrote: >>>>>> Hi Guys, >>>>>> >>>>>> How about getting the CPU temperature. I think most CPUs >>>>>> support "Digital Thermal Sensor" (I'm not sure about ARM). I >>>>>> think it is seven bits. The real range should be less than >>>>>> that but it may be enough to help add some entropy. >>>>>> >>>>>> Lou >>>>>> >>>>>> On Mon, 19 Oct 2015 07:39:19 -0400, Robert Withers >>>>>> robert.w.withers@gmail.com wrote: >>>>>> >>>>>>> Hi Ron , nice to see you too! It has been a number of years, >>>>>>> hasn't it? >>>>>>> Crypto is timestamped back in 2010, so there is is. I hope >>>>>>> these have been kind years to you, as they have for me. >>>>>>> >>>>>>> I love the idea of optional sources of entropy, depending on >>>>>>> the deployed capabilities. So there are our mouse points and >>>>>>> such, because they ought to be optional. >>>>>>> >>>>>>> What are some reliably present sources in the most minimal >> situation? >>>>>>> If we could define minimal as an image with no image level >>>>>>> I/O beyond file I/O, I would think we'd have: Kernel, >>>>>>> System, Collections, Compiler and FFI. Some intransitives in >>>>>>> that scope for entropy would be >>>>> grand. >>>>>>> I was thinking to take 5 millisecondClockValues, separated >>>>>>> by >>>>>>> 4 non-secure random intervals: take the low order byte of >>>>>>> the >>>>>>> 4 intervals and reverse & concat them, as a entropic source. >>>>>>> >>>>>>> I can coordinate these changes. Ron, could you add me to the >>>>>>> Cryptography team so I can upload the Pharo Cryptography >>>>> #bleedingEdge? >>>>>>> Thanks and I look forward to more, :) >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> On 10/18/2015 02:38 PM, Ron Teitelbaum wrote: >>>>>>>> Hi Robert, >>>>>>>> >>>>>>>> Nice to see you! >>>>>>>> >>>>>>>> Looks interesting I know that Chris did something gathering >>>>>>>> sources of >>>>> entropy. Seems like the more the better. Could you just make >>>>> the entropy sources optional such that if they exist we use them? >>>>> I would have to go back and see what Chris did but he was >>>>> following suggestions from Schneider in his secureRandom. >>>>>>>> All the best, >>>>>>>> >>>>>>>> Ron Teitelbaum >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Pharo-dev [mailto:pharo-dev-
bounces@lists.pharo.org]
>>>>>>>>> On Behalf Of Robert Withers >>>>>>>>> Sent: Sunday, October 18, 2015 5:00 AM >>>>>>>>> To: The general-purpose Squeak developers list; Pharo >>>>>>>>> Development List >>>>>>>>> Subject: Re: [Pharo-dev] [Cryptography port to Pharo] >>>>>>>>> RandomGenerator >>>>>>>>> class>>unpredictableStringsDo: >>>>>>>>> >>>>>>>>> I'm sorry, I forgot the code. I list the existing method, >>>>>>>>> followed by my modified Pharo method below. I welcome
any
>> feedback. >>>>>>>>> Regards, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> --- >>>>>>>>> Existing: >>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>> "Enumerate sources of information from my >>>>>>>>> environment that >>>>> should >>>>>>>>> be generally hard to guess." >>>>>>>>> | time | >>>>>>>>> time := Time millisecondsToRun: >>>>>>>>> [ aBlock >>>>>>>>> value: World imageForm bits >>>>>>>>> compressToByteArray ; >>>>>>>>> value: Sensor mousePoint x asString ; >>>>>>>>> value: Sensor mousePoint y asString ; >>>>>>>>> value: Time >>>>>>>>> millisecondClockValue asByteArray ; >>>>>>>>> value: Date today asString ; >>>>>>>>> value: Time now asString ; >>>>>>>>> value: Display extent asString. >>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>> #(vmVersion platformName primVmPath >>>>>>>>> imageName >>>>> platformSubtype >>>>>>>>> datedVersion lastQuitLogPosition vmStatisticsReportString >>>>>>>>> imageName) >>>>>>>>> collect: >>>>>>>>> [ : each | >>>>>>>>> aBlock value: (SmalltalkImage >>>>>>>>> current >>>>>>>>> perform: each) >>>>> asByteArray >>>>>>>>> ] ]. >>>>>>>>> aBlock >>>>>>>>> value: time asByteArray; >>>>>>>>> "maybe the pointer has moved, hit it again." >>>>>>>>> value: Sensor mousePoint asString ; >>>>>>>>> value: Time millisecondClockValue >>>>>>>>> asByteArray >>>>>>>>> >>>>>>>>> --- >>>>>>>>> Pharo port: >>>>>>>>> unpredictableStringsDo: aBlock >>>>>>>>> "Enumerate sources of information from my >>>>>>>>> environment that >>>>> should >>>>>>>>> be generally hard to guess." >>>>>>>>> >>>>>>>>> | time | >>>>>>>>> time := Time millisecondsToRun: >>>>>>>>> [ aBlock >>>>>>>>> value: Time >>>>>>>>> millisecondClockValue asByteArray ; >>>>>>>>> value: Date today asString ; >>>>>>>>> value: Time now asString. >>>>>>>>> 100 timesRepeat: [ aBlock value: UUID new ]. >>>>>>>>> #(version primImagePath imagePath >>>>>>>>> datedVersion >>>>>>>>> lastQuitLogPosition) >>>>>>>>> collect: >>>>>>>>> [ : each | >>>>>>>>> aBlock value: (SmalltalkImage >>>>>>>>> current >>>>>>>>> perform: each) >>>>> asByteArray >>>>>>>>> ] ]. >>>>>>>>> aBlock >>>>>>>>> value: time asByteArray; >>>>>>>>> value: Time millisecondClockValue >>>>>>>>> asByteArray >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/18/2015 04:23 AM, Robert Withers wrote: >>>>>>>>>> This is a message intended for anyone who was on the >>>>>>>>>> Cryptography >>>>> team. >>>>>>>>>> I recently ported it to Pharo and had to make changes to >>>>>>>>> RandomGenerator >>>>>>>>>> class>>unpredictableStringsDo:. This certainly removed >>>>>>>>>> class>>some uncertainty >>>>>>>>>> from the results of this message. My question is what >>>>>>>>>> should I do about that? This method seems to require >>>>>>>>>> non-headless, as it is checking the mouse point and such. >>>>>>>>>> This being a crypto cornerstone, what the best answer
here.
>>>>>>>>>> Thank you, >>>>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>> ----------------------------------------------------------- >>>>>> Louis LaBrunda >>>>>> Keystone Software Corp. >>>>>> SkypeMe callto://PhotonDemon >>>>>> mailto:Lou@Keystone-Software.com http://www.Keystone- >> Software.com >>>>
Hi Chris,
The exemption is not for the location of the server but the URL where it is hosted. I'm happy to help in any way I can but I don't have access to the Pharo Repos. I have no issue with having Pharo packages on SqueakSource if that is what everyone agrees too. We have multiple packages hosted there. It's ok with me if we host some pharo code there too.
All the best,
Ron
The squeaksource.com service is open to everyone. Many people in the Pharo community make use of it, and should feel welcome to do so.
Dave
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
David T. Lewis -
Louis LaBrunda -
Robert Withers -
Ron Teitelbaum -
tim Rowledge