Date   

#SharedCrypto Default Artifact builds #SharedCrypto

mike@...
 

When making the CD pipeline. I propose we make the most common artifacts that consumers will want to use. For now, these are the ones I can think of

RPM (RedHat distros)
DEB (Debian distros)
MSI (Windows)

Does anyone have any objections to these like perhaps we can start without MSI?
--
Mike Lodder
Security Maven


#SharedCrypto crypto-lib meeting tomorrow #SharedCrypto

Hart Montgomery
 

Hi Everyone,

 

This is just a reminder email for tomorrow’s crypto-lib meeting (at the usual time).

 

Some agenda items:

 

1.       Discuss the “tiering” process for implementations and any guidelines we want to have for this going forward.  Dan Middleton sent out an email about this earlier.

2.       Naming.  Are we happy with Ursa?  We need to straighten everything out with the marketing committee no matter what we decide.

3.       Final proposal edits/suggestions.  Is there anything we still need to change in light of recent discussion?

 

Thanks a lot, and I hope to hear from many of you tomorrow.

 

Thanks,

Hart


Re: #SharedCrypto agenda ideas for Oct 31 #SharedCrypto

Hart Montgomery
 

Hi Dan,

 

Sounds great!  On your points:

 

1.       I think there will also be some grey area for tiering.  We will probably have to have maintainers collectively decide these things through votes.  We can have a standardized criteria, but I bet I could find a protocol where we would disagree on tier even given the standardized critieria.  This is a good thing to discuss though and something we will definitely have to consider more going forward.

2.       Is anyone not in favor of Ursa?  It sounded like everyone was pretty happy with it, provided we had a sufficiently scary logo.  If we’re happy with it, we should ask the marketing committee to approve.  Hopefully this shouldn’t be a long discussion tomorrow.

 

Thanks,

Hart

 

From: labs@... [mailto:labs@...] On Behalf Of Middleton, Dan
Sent: Tuesday, October 30, 2018 6:20 AM
To: labs@...
Subject: [Hyperledger Labs] #SharedCrypto agenda ideas for Oct 31

 

Tomorrow I’d like to use the blake PR to have some discussion about standards and tiers per

https://lists.hyperledger.org/g/labs/topic/sharedcrypto_3rd_party/27631934?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27631934

 

Time permitting maybe we could also settle on a name. I don’t like to burn a lot of time on name-the-baby activities but it sounded like we were all in favor of Ursa. If so, we could formalize that.

 

--Dan


#SharedCrypto agenda ideas for Oct 31 #SharedCrypto

Middleton, Dan
 

Tomorrow I’d like to use the blake PR to have some discussion about standards and tiers per

https://lists.hyperledger.org/g/labs/topic/sharedcrypto_3rd_party/27631934?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27631934

 

Time permitting maybe we could also settle on a name. I don’t like to burn a lot of time on name-the-baby activities but it sounded like we were all in favor of Ursa. If so, we could formalize that.

 

--Dan


Re: #SharedCrypto 3rd party library standards #SharedCrypto

Bob Summerwill <bob@...>
 

Government crypto is something which came up within the EEA.

Essentially you have NIST standards and then there are Chinese and Russian equivalents which are mandatory for regulated (mainly banking) industry in those countries.


Masterchain, built by the Russian FinTech consortium, with Sberbank in a lead role, forked Geth and switched to GOST cryptography.  More that that, even, they did some architectural fixes to make all the cryptography pluggable, so you could have different "modes".   Kirill also had some ideas about how you could bridge those different modes in a manner analogous to a network gateway, so you could have International backbones connecting country-specific networks with different cryptography.  Bridge nodes.

On Fri., Oct. 26, 2018, 8:28 a.m. Middleton, Dan, <dan.middleton@...> wrote:

Yes, that criteria list was heavily biased towards standard implementations. To accommodate the other 2 tiers it should be expanded to quantify the level of review of the algorithm.


When it comes to government required implementations, I’m willing to take the position we declare that as out of scope.

On the one hand, if someone wants to contribute something that’s great. On the other hand, each thing we add costs more overhead in a variety of areas including maintaining the build and CI much less security review. The implications, both good and bad, of government implementations are probably significant but they are beyond what I have time to consider right now. I think the fail-safe is to declare them out of scope for the time being and re-evaluate in the future.

 

Thanks,

Dan

 

From: "Montgomery, Hart" <hmontgomery@...>
Date: Thursday, October 25, 2018 at 9:01 AM
To: Dan Middleton <dan.middleton@...>, "labs@..." <labs@...>
Subject: RE: #SharedCrypto 3rd party library standards

 

This is a good point.  However, there are many other criteria that we might use to assess the confidence we have in standards or libraries we are using—the ones Dan lists here are only related to the practical issues around code implementation.  Other questions to consider include things like how much the algorithms being implemented have been studied and/or peer reviewed, whether the library implements a “sketchy” government-designed algorithm that has the potential for back doors, and what cryptographic assumptions the implementations are based upon.

 

I’m generally in favor of being more permissive in terms of implementations we add to the project (if someone wants to contribute them and they are useful and seemingly secure, then why not).  However, whatever build processes we use should heavily flag nonstandard or nontraditional implementations, and it should be impossible for a user to “build” crypto-lib with such algorithms unintentionally.

 

Exactly how we want to rank or rate code dependencies (including ones that we potentially write!) is a good thing for open discussion.  We can discuss our approach for something like this at our meeting next week if people like.  I doubt we’ll get universal agreement, but that’s OK—our goal should again be to just inform people using the less standard stuff and make sure they are aware rather than dictate exactly what they should use.

 

Thanks,

Hart

 

From: labs@... [mailto:labs@...] On Behalf Of Middleton, Dan
Sent: Thursday, October 25, 2018 6:03 AM
To: labs@...
Subject: [Hyperledger Labs] #SharedCrypto 3rd party library standards

 

I propose we establish some standards for libraries we will incorporate in crypto-lib (or Ursa or whatever we will soon call it :)  )

 

As a motivating example there’s a PR to add a blake2 library. I’ve not independently verified the performance claims but it looks like it is quite fast. In the risk department, though, the source repo indicates a single contributor and only 2-3 months of history. The latter raises risks that the code is not hardened and the former is a risk that it won’t be maintained.

 

The different tiers we establish complicate having a single list of criteria. Without being too rigid we could probably make a matrix of what degree applies to which tier. Here’s a starter list of criteria:

 

  • Maturity (how long has this code existed)
  • Maintainer count (how likely is the code to be maintained and issues responded to)
  • Community size (are there active mail lists and users that indicate it’s in active use)
  • Bug reporting (is there a way to submit security bugs)
  • What is the maintenance history (regular updates, patches, responsiveness for CVEs)?
  • Known issues (due diligence that the code is sound)
  • Are there protected releases (can we depend on signed libraries)

 

Taking `maturity` as a simple example we could set the levels for the 3 tiers as

Standard:            1 year

Semi-Trusted:   3 months

Research:            NA

 

Interested in feedback on this approach.

 

Regards,

Dan

 

 


Re: #SharedCrypto 3rd party library standards #SharedCrypto

Middleton, Dan
 

Yes, that criteria list was heavily biased towards standard implementations. To accommodate the other 2 tiers it should be expanded to quantify the level of review of the algorithm.


When it comes to government required implementations, I’m willing to take the position we declare that as out of scope.

On the one hand, if someone wants to contribute something that’s great. On the other hand, each thing we add costs more overhead in a variety of areas including maintaining the build and CI much less security review. The implications, both good and bad, of government implementations are probably significant but they are beyond what I have time to consider right now. I think the fail-safe is to declare them out of scope for the time being and re-evaluate in the future.

 

Thanks,

Dan

 

From: "Montgomery, Hart" <hmontgomery@...>
Date: Thursday, October 25, 2018 at 9:01 AM
To: Dan Middleton <dan.middleton@...>, "labs@..." <labs@...>
Subject: RE: #SharedCrypto 3rd party library standards

 

This is a good point.  However, there are many other criteria that we might use to assess the confidence we have in standards or libraries we are using—the ones Dan lists here are only related to the practical issues around code implementation.  Other questions to consider include things like how much the algorithms being implemented have been studied and/or peer reviewed, whether the library implements a “sketchy” government-designed algorithm that has the potential for back doors, and what cryptographic assumptions the implementations are based upon.

 

I’m generally in favor of being more permissive in terms of implementations we add to the project (if someone wants to contribute them and they are useful and seemingly secure, then why not).  However, whatever build processes we use should heavily flag nonstandard or nontraditional implementations, and it should be impossible for a user to “build” crypto-lib with such algorithms unintentionally.

 

Exactly how we want to rank or rate code dependencies (including ones that we potentially write!) is a good thing for open discussion.  We can discuss our approach for something like this at our meeting next week if people like.  I doubt we’ll get universal agreement, but that’s OK—our goal should again be to just inform people using the less standard stuff and make sure they are aware rather than dictate exactly what they should use.

 

Thanks,

Hart

 

From: labs@... [mailto:labs@...] On Behalf Of Middleton, Dan
Sent: Thursday, October 25, 2018 6:03 AM
To: labs@...
Subject: [Hyperledger Labs] #SharedCrypto 3rd party library standards

 

I propose we establish some standards for libraries we will incorporate in crypto-lib (or Ursa or whatever we will soon call it :)  )

 

As a motivating example there’s a PR to add a blake2 library. I’ve not independently verified the performance claims but it looks like it is quite fast. In the risk department, though, the source repo indicates a single contributor and only 2-3 months of history. The latter raises risks that the code is not hardened and the former is a risk that it won’t be maintained.

 

The different tiers we establish complicate having a single list of criteria. Without being too rigid we could probably make a matrix of what degree applies to which tier. Here’s a starter list of criteria:

 

  • Maturity (how long has this code existed)
  • Maintainer count (how likely is the code to be maintained and issues responded to)
  • Community size (are there active mail lists and users that indicate it’s in active use)
  • Bug reporting (is there a way to submit security bugs)
  • What is the maintenance history (regular updates, patches, responsiveness for CVEs)?
  • Known issues (due diligence that the code is sound)
  • Are there protected releases (can we depend on signed libraries)

 

Taking `maturity` as a simple example we could set the levels for the 3 tiers as

Standard:            1 year

Semi-Trusted:   3 months

Research:            NA

 

Interested in feedback on this approach.

 

Regards,

Dan

 

 


Re: #SharedCrypto crypto-lib proposal update #SharedCrypto

Middleton, Dan
 

I’m fine with the updated maintainers concept.

We can enforce n maintainer reviews with github. We already do that in sawtooth. I’m still planning to get the contributor rules writeup in as a PR before our next meeting.

 

--Dan

 

From: <labs@...> on behalf of Mark Wagner <mwagner114@...>
Date: Thursday, October 25, 2018 at 8:44 PM
To: Hart Montgomery <hmontgomery@...>
Cc: "labs@..." <labs@...>
Subject: Re: [Hyperledger Labs] #SharedCrypto crypto-lib proposal update

 

Sounds good to me

 

On Thu, Oct 25, 2018, 21:28 hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

I just wanted to give a brief update.  At the TSC meeting today, we discussed the crypto-lib proposal for a little bit and got some good feedback.

 

The main suggestion (from Chris Ferris) was that it would be simpler (and better for expanding the project in the future) if, instead of having “stewards” and maintainers, we just classified everyone as maintainers and separated them into lists.  This would mean we have a list of “theoretical maintainers” which would currently be our stewards, and “base signature/Zmix maintainers” which would be our current maintainers.  This would simplify our review process, since we could just require people on the “theoretical maintainer” list to sign off on changes that are algorithmic in nature, and this could be done natively in, say, Gerrit.  It would also mean our project structure would be much more like established projects, which is almost certainly a good thing.

 

I don’t think this is a radical change (or even much of a change) from what we had in mind and shouldn’t change the way things are currently working.  The semantics are just a little bit different, and it will help in the future if we want to further define roles (i.e. security code review expert, or post-quantum cryptography expert) to get appropriate reviews.

 

Does anyone have any thoughts on or objections to this change?  If not, then I’ll modify the project proposal to reflect this.

 

Thanks,

Hart


Re: #SharedCrypto crypto-lib proposal update #SharedCrypto

Mark Wagner
 

Sounds good to me


On Thu, Oct 25, 2018, 21:28 hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

I just wanted to give a brief update.  At the TSC meeting today, we discussed the crypto-lib proposal for a little bit and got some good feedback.

 

The main suggestion (from Chris Ferris) was that it would be simpler (and better for expanding the project in the future) if, instead of having “stewards” and maintainers, we just classified everyone as maintainers and separated them into lists.  This would mean we have a list of “theoretical maintainers” which would currently be our stewards, and “base signature/Zmix maintainers” which would be our current maintainers.  This would simplify our review process, since we could just require people on the “theoretical maintainer” list to sign off on changes that are algorithmic in nature, and this could be done natively in, say, Gerrit.  It would also mean our project structure would be much more like established projects, which is almost certainly a good thing.

 

I don’t think this is a radical change (or even much of a change) from what we had in mind and shouldn’t change the way things are currently working.  The semantics are just a little bit different, and it will help in the future if we want to further define roles (i.e. security code review expert, or post-quantum cryptography expert) to get appropriate reviews.

 

Does anyone have any thoughts on or objections to this change?  If not, then I’ll modify the project proposal to reflect this.

 

Thanks,

Hart


#SharedCrypto crypto-lib proposal update #SharedCrypto

Hart Montgomery
 

Hi Everyone,

 

I just wanted to give a brief update.  At the TSC meeting today, we discussed the crypto-lib proposal for a little bit and got some good feedback.

 

The main suggestion (from Chris Ferris) was that it would be simpler (and better for expanding the project in the future) if, instead of having “stewards” and maintainers, we just classified everyone as maintainers and separated them into lists.  This would mean we have a list of “theoretical maintainers” which would currently be our stewards, and “base signature/Zmix maintainers” which would be our current maintainers.  This would simplify our review process, since we could just require people on the “theoretical maintainer” list to sign off on changes that are algorithmic in nature, and this could be done natively in, say, Gerrit.  It would also mean our project structure would be much more like established projects, which is almost certainly a good thing.

 

I don’t think this is a radical change (or even much of a change) from what we had in mind and shouldn’t change the way things are currently working.  The semantics are just a little bit different, and it will help in the future if we want to further define roles (i.e. security code review expert, or post-quantum cryptography expert) to get appropriate reviews.

 

Does anyone have any thoughts on or objections to this change?  If not, then I’ll modify the project proposal to reflect this.

 

Thanks,

Hart


Re: #SharedCrypto 3rd party library standards #SharedCrypto

Hart Montgomery
 

This is a good point.  However, there are many other criteria that we might use to assess the confidence we have in standards or libraries we are using—the ones Dan lists here are only related to the practical issues around code implementation.  Other questions to consider include things like how much the algorithms being implemented have been studied and/or peer reviewed, whether the library implements a “sketchy” government-designed algorithm that has the potential for back doors, and what cryptographic assumptions the implementations are based upon.

 

I’m generally in favor of being more permissive in terms of implementations we add to the project (if someone wants to contribute them and they are useful and seemingly secure, then why not).  However, whatever build processes we use should heavily flag nonstandard or nontraditional implementations, and it should be impossible for a user to “build” crypto-lib with such algorithms unintentionally.

 

Exactly how we want to rank or rate code dependencies (including ones that we potentially write!) is a good thing for open discussion.  We can discuss our approach for something like this at our meeting next week if people like.  I doubt we’ll get universal agreement, but that’s OK—our goal should again be to just inform people using the less standard stuff and make sure they are aware rather than dictate exactly what they should use.

 

Thanks,

Hart

 

From: labs@... [mailto:labs@...] On Behalf Of Middleton, Dan
Sent: Thursday, October 25, 2018 6:03 AM
To: labs@...
Subject: [Hyperledger Labs] #SharedCrypto 3rd party library standards

 

I propose we establish some standards for libraries we will incorporate in crypto-lib (or Ursa or whatever we will soon call it :)  )

 

As a motivating example there’s a PR to add a blake2 library. I’ve not independently verified the performance claims but it looks like it is quite fast. In the risk department, though, the source repo indicates a single contributor and only 2-3 months of history. The latter raises risks that the code is not hardened and the former is a risk that it won’t be maintained.

 

The different tiers we establish complicate having a single list of criteria. Without being too rigid we could probably make a matrix of what degree applies to which tier. Here’s a starter list of criteria:

 

  • Maturity (how long has this code existed)
  • Maintainer count (how likely is the code to be maintained and issues responded to)
  • Community size (are there active mail lists and users that indicate it’s in active use)
  • Bug reporting (is there a way to submit security bugs)
  • What is the maintenance history (regular updates, patches, responsiveness for CVEs)?
  • Known issues (due diligence that the code is sound)
  • Are there protected releases (can we depend on signed libraries)

 

Taking `maturity` as a simple example we could set the levels for the 3 tiers as

Standard:            1 year

Semi-Trusted:   3 months

Research:            NA

 

Interested in feedback on this approach.

 

Regards,

Dan

 

 


#SharedCrypto 3rd party library standards #SharedCrypto

Middleton, Dan
 

I propose we establish some standards for libraries we will incorporate in crypto-lib (or Ursa or whatever we will soon call it :)  )

 

As a motivating example there’s a PR to add a blake2 library. I’ve not independently verified the performance claims but it looks like it is quite fast. In the risk department, though, the source repo indicates a single contributor and only 2-3 months of history. The latter raises risks that the code is not hardened and the former is a risk that it won’t be maintained.

 

The different tiers we establish complicate having a single list of criteria. Without being too rigid we could probably make a matrix of what degree applies to which tier. Here’s a starter list of criteria:

 

  • Maturity (how long has this code existed)
  • Maintainer count (how likely is the code to be maintained and issues responded to)
  • Community size (are there active mail lists and users that indicate it’s in active use)
  • Bug reporting (is there a way to submit security bugs)
  • What is the maintenance history (regular updates, patches, responsiveness for CVEs)?
  • Known issues (due diligence that the code is sound)
  • Are there protected releases (can we depend on signed libraries)

 

Taking `maturity` as a simple example we could set the levels for the 3 tiers as

Standard:            1 year

Semi-Trusted:   3 months

Research:            NA

 

Interested in feedback on this approach.

 

Regards,

Dan

 

 


#SharedCrypto crypto-lib meeting tomorrow #SharedCrypto

Hart Montgomery
 

Hi Everyone,

 

This is just a reminder for tomorrow’s crypto-lib meeting (7:00 AM Pacific time, as usual).  Some things to discuss:

 

1.       My perception is that we’re on the cusp of proposing crypto-lib to the TSC for incubation status.  I’d like to discuss this with everyone at the meeting.  As such, if you haven’t gone over the proposal document recently, please take a look: https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing.  I have made some edits recently after discussions with Dan M and Shawn, among others.  Ideally, we could announce to the TSC this week that we were planning on asking for a vote in the near future.

2.       Hackfest recap:  we will go over the progress made at the hackfest and next steps.

3.       Whatever else people want to talk about.

 

Thanks a lot for everyone’s time, and I hope to speak with many of you tomorrow.

 

Thanks,

Hart

 

 


Re: #SharedCrypto team-specific hack-a-thon? #SharedCrypto

David Huseby <dhuseby@...>
 

I’ll be there I think. If we have a hackathon I’ll be there for sure. 

Dave

On Fri, Oct 12, 2018 at 3:09 PM Montgomery, Hart <hmontgomery@...> wrote:

I can't promise anything since I haven't confirmed yet, but I might be able to offer space at our Sunnyvale campus either before or after Real World Crypto  (but probably before, since it's a Wed-Fri event) this coming January.  If it's a small group, then I can almost certainly do it.

 

I doubt RWC is a good venue for a hackathon though--people are usually pretty drained from going to the talks all day.  I've never seen anyone try to do a hackathon in conjunction with an IACR conference before, and I'd be worried about turnout (RWC may be an exception to this rule, but I'd be surprised).  Most people are there to go to talks and socialize, not hack.  It would be difficult to get new people. 

 

Are lots of people on this list planning on coming to RWC?  If so, at minimum I can try to plan for a crypto-lib workday on the Tuesday before RWC.

 

Thanks,

Hart

 

 

From: labs@... [mailto:labs@...] On Behalf Of Geater, Jon
Sent: Friday, October 12, 2018 1:03 PM
To: David Huseby <dhuseby@...>; labs@...
Subject: Re: [Hyperledger Labs] #SharedCrypto team-specific hack-a-thon?

 

I think it’s a good idea.  The Crypto Lib is a very good fit for a hackathon in my opinion - lots of small jobs, lots of specialist edges that will benefit from a quick injection of niche skills, no distracting demo UI pressure...

 

Jon

 





 

Jon Geater
CTO

Tel: +44 1223 703479
Mob: +44 7966 995312

@thalesesecurity

Thales eSecurity
One Station Square
Cambridge CB1 2GA

United Kingdom

www.thalesesecurity.com

 

On Fri, Oct 12, 2018 at 8:45 PM +0100, "David Huseby" <dhuseby@...> wrote:

Hi Crypto-Lib Team,
 
We're busy building the 2019 budget and I was considering setting
aside some money so that HL could pay for space/snacks/swag for doing
crypto-lib specific hack-a-thons that coincide with events such as
Real World Crypto.  Since we're all likely to be attending these
conferences, it might make sense to take advantage of that and get
some space for us to meet in during the evenings or the day after the
event.
 
I'm looking for feedback from the rest of you on if you think it is a
good idea and a good use of HL resources.  Please respond ASAP.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
 
 
 
 

--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: #SharedCrypto team-specific hack-a-thon? #SharedCrypto

Hart Montgomery
 

I can't promise anything since I haven't confirmed yet, but I might be able to offer space at our Sunnyvale campus either before or after Real World Crypto  (but probably before, since it's a Wed-Fri event) this coming January.  If it's a small group, then I can almost certainly do it.

 

I doubt RWC is a good venue for a hackathon though--people are usually pretty drained from going to the talks all day.  I've never seen anyone try to do a hackathon in conjunction with an IACR conference before, and I'd be worried about turnout (RWC may be an exception to this rule, but I'd be surprised).  Most people are there to go to talks and socialize, not hack.  It would be difficult to get new people. 

 

Are lots of people on this list planning on coming to RWC?  If so, at minimum I can try to plan for a crypto-lib workday on the Tuesday before RWC.

 

Thanks,

Hart

 

 

From: labs@... [mailto:labs@...] On Behalf Of Geater, Jon
Sent: Friday, October 12, 2018 1:03 PM
To: David Huseby <dhuseby@...>; labs@...
Subject: Re: [Hyperledger Labs] #SharedCrypto team-specific hack-a-thon?

 

I think it’s a good idea.  The Crypto Lib is a very good fit for a hackathon in my opinion - lots of small jobs, lots of specialist edges that will benefit from a quick injection of niche skills, no distracting demo UI pressure...

 

Jon

 





 

Jon Geater
CTO

Tel: +44 1223 703479
Mob: +44 7966 995312

@thalesesecurity

Thales eSecurity
One Station Square
Cambridge CB1 2GA

United Kingdom

www.thalesesecurity.com

 

On Fri, Oct 12, 2018 at 8:45 PM +0100, "David Huseby" <dhuseby@...> wrote:

Hi Crypto-Lib Team,
 
We're busy building the 2019 budget and I was considering setting
aside some money so that HL could pay for space/snacks/swag for doing
crypto-lib specific hack-a-thons that coincide with events such as
Real World Crypto.  Since we're all likely to be attending these
conferences, it might make sense to take advantage of that and get
some space for us to meet in during the evenings or the day after the
event.
 
I'm looking for feedback from the rest of you on if you think it is a
good idea and a good use of HL resources.  Please respond ASAP.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
 
 
 
 


Re: #SharedCrypto team-specific hack-a-thon? #SharedCrypto

Geater, Jon <Jon.Geater@...>
 

I think it’s a good idea.  The Crypto Lib is a very good fit for a hackathon in my opinion - lots of small jobs, lots of specialist edges that will benefit from a quick injection of niche skills, no distracting demo UI pressure...

Jon






 
Jon Geater
CTO
Tel: +44 1223 703479
Mob: +44 7966 995312
@thalesesecurity

Thales eSecurity
One Station Square
Cambridge CB1 2GA
United Kingdom



www.thalesesecurity.com

On Fri, Oct 12, 2018 at 8:45 PM +0100, "David Huseby" <dhuseby@...> wrote:

Hi Crypto-Lib Team,

We're busy building the 2019 budget and I was considering setting
aside some money so that HL could pay for space/snacks/swag for doing
crypto-lib specific hack-a-thons that coincide with events such as
Real World Crypto.  Since we're all likely to be attending these
conferences, it might make sense to take advantage of that and get
some space for us to meet in during the evenings or the day after the
event.

I'm looking for feedback from the rest of you on if you think it is a
good idea and a good use of HL resources.  Please respond ASAP.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





Re: #SharedCrypto team-specific hack-a-thon? #SharedCrypto

Mark Wagner
 

While I wont be participating, I like the idea


On Fri, Oct 12, 2018, 15:45 David Huseby <dhuseby@...> wrote:
Hi Crypto-Lib Team,

We're busy building the 2019 budget and I was considering setting
aside some money so that HL could pay for space/snacks/swag for doing
crypto-lib specific hack-a-thons that coincide with events such as
Real World Crypto.  Since we're all likely to be attending these
conferences, it might make sense to take advantage of that and get
some space for us to meet in during the evenings or the day after the
event.

I'm looking for feedback from the rest of you on if you think it is a
good idea and a good use of HL resources.  Please respond ASAP.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...




Re: #SharedCrypto team-specific hack-a-thon? #SharedCrypto

Middleton, Dan
 

sounds good to me

--Dan

On 10/12/18, 2:45 PM, "labs@lists.hyperledger.org on behalf of David Huseby" <labs@lists.hyperledger.org on behalf of dhuseby@linuxfoundation.org> wrote:

Hi Crypto-Lib Team,

We're busy building the 2019 budget and I was considering setting
aside some money so that HL could pay for space/snacks/swag for doing
crypto-lib specific hack-a-thons that coincide with events such as
Real World Crypto. Since we're all likely to be attending these
conferences, it might make sense to take advantage of that and get
some space for us to meet in during the evenings or the day after the
event.

I'm looking for feedback from the rest of you on if you think it is a
good idea and a good use of HL resources. Please respond ASAP.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@linuxfoundation.org


#SharedCrypto team-specific hack-a-thon? #SharedCrypto

David Huseby <dhuseby@...>
 

Hi Crypto-Lib Team,

We're busy building the 2019 budget and I was considering setting
aside some money so that HL could pay for space/snacks/swag for doing
crypto-lib specific hack-a-thons that coincide with events such as
Real World Crypto. Since we're all likely to be attending these
conferences, it might make sense to take advantage of that and get
some space for us to meet in during the evenings or the day after the
event.

I'm looking for feedback from the rest of you on if you think it is a
good idea and a good use of HL resources. Please respond ASAP.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@linuxfoundation.org


#SharedCrypto crypto-lib meeting tomorrow CANCELLED #SharedCrypto

Hart Montgomery
 

Hi Everyone,

 

I’m cancelling tomorrow’s crypto-lib meeting due to the fact that a large amount of our regular participants will be attending the Montreal hackfest.  I hope that we can come out of the meetings with a proposal for incubation ready to submit to the TSC.

 

Hope you all are doing well, and talk to everyone either tomorrow at the hackfest or in two weeks.

 

Thanks,

Hart


Re: #SharedCrypto crypto-lib meeting tomorrow #SharedCrypto

Middleton, Dan
 

Thanks for wrangling this, Hart.

Not sure if I can make it to today’s call. In case I can’t I’ve added a couple comments in the proposal.

As further high-level thoughts, though, it might be helpful to get more concrete on scope.

I think what we have is 2 sub-projects or feature areas. A signature library and z-mix. We should reference some kind of spec for each.

 

As the third tier is explicitly labs, we may as well be clear it’s out of scope of this “project”.  The lab has its own process and the project can elect to adopt lab code at the right time.

 

Other high-level thing is we should think about this project proposal with developer hats on.

 

Thanks,

Dan

 

From: <labs@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Tuesday, September 18, 2018 at 8:46 PM
To: "labs@..." <labs@...>
Subject: [Hyperledger Labs] #SharedCrypto crypto-lib meeting tomorrow

 

Hi Everyone,

 

This is just a reminder for tomorrow’s crypto-lib meeting.  Currently we have on the agenda:

 

  1. Discuss the project proposal document:  https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing .  Please read through this if you haven’t already.
  2. Modular hash functions (and symmetric primitives) for region compatibility.  People using Hyperledger in China are required to use government-approved cryptographic algorithms.  We need to discuss how to best deal with this.
  3. Updates and questions from the devs on z-mix and the shared signature library.

 

Thanks a lot for your time, and I hope to hear from many of you tomorrow.

 

Thanks,

Hart

81 - 100 of 120