rjones (Wed, 21 Feb 2018 19:20:57 GMT):
dhuseby

dhuseby (Wed, 21 Feb 2018 19:22:15 GMT):
hi

hartm (Wed, 21 Feb 2018 19:22:18 GMT):
Has joined the channel.

dhuseby (Wed, 21 Feb 2018 19:22:41 GMT):
@rjones will you set @hartm as the owner?

dhuseby (Wed, 21 Feb 2018 19:22:42 GMT):
thanks

stanliberman (Wed, 21 Feb 2018 19:22:44 GMT):
Has joined the channel.

hartm (Wed, 21 Feb 2018 19:22:45 GMT):
Proposal DocumenT:

hartm (Wed, 21 Feb 2018 19:22:52 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

MicBowman (Wed, 21 Feb 2018 19:22:55 GMT):
Has joined the channel.

MicBowman (Wed, 21 Feb 2018 19:22:58 GMT):
tada...

rjones (Wed, 21 Feb 2018 19:23:01 GMT):
hartm

dhuseby (Wed, 21 Feb 2018 19:23:05 GMT):
thanks

hartm (Wed, 21 Feb 2018 19:23:11 GMT):
Thanks Ry!

rjones (Wed, 21 Feb 2018 19:23:28 GMT):
Sure thing!

MicBowman (Wed, 21 Feb 2018 19:23:35 GMT):
@me jumps into the dunk tank

dhuseby (Wed, 21 Feb 2018 19:23:36 GMT):
_hi_

MicBowman (Wed, 21 Feb 2018 19:23:40 GMT):
_jumps into the dunk tank_

hartm (Wed, 21 Feb 2018 19:24:03 GMT):
"; DROP TABLE; "

amundson (Wed, 21 Feb 2018 19:24:15 GMT):
Has joined the channel.

rjagadee (Wed, 21 Feb 2018 19:24:54 GMT):
Has joined the channel.

dhuseby (Wed, 21 Feb 2018 19:25:14 GMT):
February 21, 2018 meeting agenda

dhuseby (Wed, 21 Feb 2018 19:25:31 GMT):
- identify initial contributions what and who

dhuseby (Wed, 21 Feb 2018 19:25:42 GMT):
- finalize document structure and content

dhuseby (Wed, 21 Feb 2018 19:25:57 GMT):
- set up meeting schedule

Dan (Wed, 21 Feb 2018 19:38:44 GMT):
Has joined the channel.

nage (Wed, 21 Feb 2018 20:24:24 GMT):
Has joined the channel.

nage (Wed, 21 Feb 2018 20:24:31 GMT):
https://github.com/hyperledger/indy-crypto/blob/master/README.md

hartm (Wed, 21 Feb 2018 20:24:37 GMT):
Initial meeting proposal: Tuesday, March 6th, at 7:00 AM Pacific Time. Please feel free to comment if this does or does not work for you. Thanks!

nage (Wed, 21 Feb 2018 20:24:50 GMT):
User User_1 added by nage.

nage (Wed, 21 Feb 2018 20:25:23 GMT):
User User_2 added by nage.

nage (Wed, 21 Feb 2018 20:25:53 GMT):
User User_3 added by nage.

nage (Wed, 21 Feb 2018 20:26:08 GMT):
User User_4 added by nage.

nage (Wed, 21 Feb 2018 21:10:55 GMT):
User User_5 added by nage.

Er1ck (Wed, 21 Feb 2018 21:48:59 GMT):
Has joined the channel.

peter-choe (Thu, 22 Feb 2018 18:16:21 GMT):
Has joined the channel.

austinwork (Thu, 22 Feb 2018 18:18:04 GMT):
Has joined the channel.

hartm (Thu, 22 Feb 2018 19:04:21 GMT):
TLDR from today's meeting:

hartm (Thu, 22 Feb 2018 19:04:58 GMT):
1) We should split off the tier 3 portion of the library. It's probably a better fit for labs, and might hinder the current proposal.

hartm (Thu, 22 Feb 2018 19:05:51 GMT):
2) Indy and Sawtooth are going to create a repository to begin looking at combining some signature functionality. If there are some successes, this will be the initial codebase of the project proposal.

hartm (Thu, 22 Feb 2018 19:06:18 GMT):
3) We need further discussion with Fabric crypto people to discuss their role in this effort.

MicBowman (Thu, 22 Feb 2018 21:29:39 GMT):
@hartm does this mean you don't need our wrapper? perfectly fine with me... but we should update the proposal accordingly

jsmitchell (Thu, 22 Feb 2018 22:55:04 GMT):
Has joined the channel.

hartm (Thu, 22 Feb 2018 23:25:07 GMT):
I'm going to update the proposal. The Indy/Sawtooth repository will utilize this wrapper functionality, so we will definitely need the Sawtooth wrapper.

kelly_ (Thu, 22 Feb 2018 23:48:00 GMT):
Has joined the channel.

amundson (Fri, 23 Feb 2018 20:29:20 GMT):
@MicBowman can you push up your wrapper somewhere so we can see it? The pieces we were discussing for signing aren't necessarily the code Sawtooth is using for PoET currently; rather, the libsecp256k1 wrappers for the various languages.

amundson (Fri, 23 Feb 2018 20:29:59 GMT):
https://github.com/hyperledger/sawtooth-core/tree/master/sdk/rust/src/signing

amundson (Fri, 23 Feb 2018 20:30:26 GMT):
https://github.com/hyperledger/sawtooth-core/tree/master/signing

amundson (Fri, 23 Feb 2018 20:30:47 GMT):
https://github.com/hyperledger/sawtooth-core/tree/master/sdk/go/src/sawtooth_sdk/signing

amundson (Fri, 23 Feb 2018 20:31:04 GMT):
(the non-SDK one is the python package)

amundson (Fri, 23 Feb 2018 20:31:45 GMT):
https://github.com/hyperledger/sawtooth-core/tree/master/sdk/javascript/signing

amundson (Fri, 23 Feb 2018 20:32:48 GMT):
I'm not sure we have anything like that for C++ or Java yet

amundson (Fri, 23 Feb 2018 20:36:14 GMT):
https://github.com/hyperledger/indy-crypto

amundson (Fri, 23 Feb 2018 20:40:42 GMT):
is there more indy stuff we should be looking at?

smartheye (Mon, 26 Feb 2018 15:06:12 GMT):
Has joined the channel.

koenbuyens (Tue, 27 Feb 2018 18:14:52 GMT):
Has joined the channel.

chandrakanthm (Wed, 28 Feb 2018 09:52:31 GMT):
Has joined the channel.

MicBowman (Wed, 28 Feb 2018 17:04:36 GMT):
@amundson i can send it to you separately

binhn (Wed, 28 Feb 2018 17:15:50 GMT):
Has joined the channel.

hartm (Mon, 05 Mar 2018 21:37:24 GMT):
@here Are people still OK with a call tomorrow morning to discuss progress? Thanks, and sorry for "here" spam.

nage (Mon, 05 Mar 2018 22:20:48 GMT):
I’m at Rebooting the Web of Trust, but perhaps someone else from Indy will be able to make it?

hartm (Mon, 05 Mar 2018 22:29:02 GMT):
Should we put it off until next week if you guys are going to be gone?

rjones (Tue, 06 Mar 2018 01:56:13 GMT):
Has left the channel.

Dan (Tue, 06 Mar 2018 02:16:07 GMT):
I'm going to be stuck on a plane tomorrow morning :(

hartm (Tue, 06 Mar 2018 02:34:30 GMT):
@here OK then, let's put this off until next week. Does Tuesday morning next week work for everyone?

Dan (Tue, 06 Mar 2018 02:37:37 GMT):
how's about wed afternoon? otherwise, ok to miss me. can't always get everyone and I don't want to slow things down too much.

hartm (Tue, 06 Mar 2018 04:56:03 GMT):
I think a lot of the Indy folks are going to be at rebooting web of trust.

binhn (Tue, 06 Mar 2018 14:43:57 GMT):
i m planning to be out next week, but i probably can make the call

nage (Wed, 07 Mar 2018 07:01:17 GMT):
There is a lot of interesting work at Rebooting the Web of Trust about extending TLS libraries to be able to leverage non-CA certificates anchored to blockchains. It seems like an interesting case to support mutually authenticated connections and ledger membership use cases for our systems. Im looking for opinions, would that be good work to take up in the shared crypto library, as a HL lab or something else?

tobowers (Wed, 07 Mar 2018 21:08:18 GMT):
Has joined the channel.

tobowers (Wed, 07 Mar 2018 21:08:27 GMT):
this the right place to talk about libindy-crypto?

lovesh (Thu, 08 Mar 2018 20:32:46 GMT):
@tobowers Depends on the question. But indy-sdk is another appropriate channel since most devs of the library hang out there

tobowers (Fri, 09 Mar 2018 07:31:19 GMT):
Thanks @lovesh - I sent my question to the hyperledger-indy mailing list. I figured out what I was doing wrong... but I'm still concerned that I passed in a bunch of bad bytes to the FFI verify function (single BLS signature) and the result was a success error code and a True for verified

hartm (Fri, 09 Mar 2018 16:04:10 GMT):
@tobowers That seems like a bug. If you can recreate it (it sounds like you have found a way to essentially forge a signature) it would definitely be something the indy devs should know about.

gudkov (Fri, 09 Mar 2018 20:48:41 GMT):
@hartm I can't see your email in mailing list. Could you provide more info here or just create a bug in Jira or Github.

tobowers (Sat, 10 Mar 2018 08:23:23 GMT):
@hartm , @gudkov https://jira.hyperledger.org/browse/IS-583

gudkov (Mon, 12 Mar 2018 16:43:29 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=GdsptKEAyWetxZ3ag) This result can be easily achieved if you used incorrect data for generator point and verkey/signkey pair. The math is valid only if you use correct (gp, verkey, signkey) tuple. At least i see that Generator Point contains garbage (zero points). If any of (gp, verkey, signkey) values contain garbade the result is unpredictable. If multiplies something by zero it will be always zero.

hartm (Mon, 12 Mar 2018 19:12:06 GMT):
@gudkov @tobowers Yeah, I just looked at your trace. You're using zero for the generator element, which will give you all kinds of bad results. Since it seems like you've already fixed this, I wouldn't worry too much about it. However, note that an adversary can control the bytes for the (message, signature) pair, it cannot control the public or secret keys (or the group generator) and we can generally assume those will be correct (assuming no hardware attacks).

hartm (Mon, 12 Mar 2018 19:14:13 GMT):
This isn't a bug in indy-crypt, but if it's easy to stop people from using clearly flawed choices (i.e. zero or the point at infinity) as parameters in a side-channel resilient manner (or warn them when they do), it might be worth the time to do it in the long run.

hartm (Mon, 12 Mar 2018 22:47:07 GMT):
@here Are people still OK with a call tomorrow at 7:00 AM Pacific time (10:00 Eastern)? There seem to be less scheduling conflicts this week.

hartm (Tue, 13 Mar 2018 07:37:20 GMT):
@here OK, on second thought, we're not ready for a meeting tomorrow. I'll try to put together a formal agenda, invite, and everything so that we can maximize participation. Sorry for the delays.

hartm (Tue, 13 Mar 2018 07:37:38 GMT):
Talk to everybody next week (or, more likely, in other meetings).

manu (Tue, 13 Mar 2018 16:07:56 GMT):
Has joined the channel.

Maria (Tue, 13 Mar 2018 16:08:01 GMT):
Has joined the channel.

dhuseby (Thu, 15 Mar 2018 21:15:46 GMT):
@hartm so when is the proposed meeting time? I'd like to get it in my calendar so that I don't miss it.

hartm (Thu, 15 Mar 2018 22:20:48 GMT):
@dhuseby I'm fishing around with emails to find what works best for people.

hartm (Thu, 15 Mar 2018 22:21:08 GMT):
Initial proposal is Tuesday at 7:00 AM pacific time, although that is highly subject to change.

dhuseby (Thu, 15 Mar 2018 22:23:40 GMT):
That works for me

hartm (Tue, 20 Mar 2018 01:16:01 GMT):
@here After polling everyone, it appears Wednesday at 7:00 AM pacific time is the best meeting time for everyone. I look forward to speaking with everyone bright and early Wednesday!

hartm (Tue, 20 Mar 2018 01:16:06 GMT):
Link: https://zoom.us/j/685604650

dhuseby (Tue, 20 Mar 2018 01:57:10 GMT):
Thanks Hart

ShikarSharma (Tue, 20 Mar 2018 22:36:21 GMT):
Has joined the channel.

Dan (Wed, 21 Mar 2018 13:04:50 GMT):
@hart are we meeting this morning?

Dan (Wed, 21 Mar 2018 13:04:50 GMT):
@hartm are we meeting this morning?

Dan (Wed, 21 Mar 2018 13:17:52 GMT):
ah n/m got my timezones messed up. talk to you in ~45min.

hartm (Wed, 21 Mar 2018 14:00:51 GMT):
Relevant links:

hartm (Wed, 21 Mar 2018 14:00:55 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

hartm (Wed, 21 Mar 2018 14:01:09 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

manu (Wed, 21 Mar 2018 14:03:02 GMT):
User User_6 added by manu.

brian038 (Wed, 21 Mar 2018 14:03:29 GMT):
Has joined the channel.

eramitg (Wed, 21 Mar 2018 14:17:18 GMT):
Has joined the channel.

nage (Wed, 21 Mar 2018 14:42:33 GMT):
Leaving this here in case someone has time to experiment: https://doc.rust-lang.org/1.16.0/book/no-stdlib.html

MicBowman (Wed, 21 Mar 2018 14:45:13 GMT):
and... https://github.com/baidu/rust-sgx-sdk

binhn (Wed, 28 Mar 2018 14:08:44 GMT):
@hartm meeting today?

manu (Wed, 28 Mar 2018 14:28:37 GMT):
since there apparently isn't a call today, is there any progress on getting a labs project started?

MicBowman (Wed, 28 Mar 2018 15:09:24 GMT):
@binhn my understanding from the call last week is that we are alternating weeks

binhn (Wed, 28 Mar 2018 15:27:37 GMT):
we should update the community calendar as it is showing meeting today https://calendar.google.com/calendar/embed?src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=UTC

manu (Wed, 28 Mar 2018 15:32:16 GMT):
agree, and @hartm please cancel the calendar invites for the dates where we don't meet

hartm (Wed, 28 Mar 2018 16:13:37 GMT):
@manu @binhn Sorry--I don't have control over the calendar invites, but it looks like this has been fixed.

hartm (Wed, 28 Mar 2018 16:14:05 GMT):
I've talked to the labs stewards about the labs proposal. I'll hopefully be able to get the proposal submitted today.

KOttoni (Wed, 28 Mar 2018 16:52:07 GMT):
Has joined the channel.

hartm (Wed, 28 Mar 2018 22:58:34 GMT):
Pull request for the labs proposal done: https://github.com/hartm/hyperledger-labs.github.io/pull/1

hartm (Wed, 28 Mar 2018 22:58:41 GMT):
Feel free to edit if any of you all like.

hartm (Thu, 29 Mar 2018 17:50:24 GMT):
Hi Everyone, we now have a repo in Hyperledger Labs:

hartm (Thu, 29 Mar 2018 17:50:29 GMT):
https://github.com/hyperledger-labs/crypto-lib

hartm (Fri, 30 Mar 2018 00:11:53 GMT):
@here If you'd like to have write access to hyperledger-labs/crypto-lib so that you can start messing with code, please send me your github ID (hmontgomery@us.fujitsu.com) so that we can get the process started. Thanks!

Pan0ptic (Fri, 30 Mar 2018 16:28:23 GMT):
Has joined the channel.

amundson (Sat, 31 Mar 2018 04:17:39 GMT):
@hartm - https://github.com/hyperledger-labs/crypto-lib/pull/2

thalisson (Sun, 01 Apr 2018 02:41:13 GMT):
Has joined the channel.

Rumeel_Hussain (Tue, 03 Apr 2018 15:00:13 GMT):
Has joined the channel.

hartm (Tue, 03 Apr 2018 21:31:42 GMT):
@here Just a reminder that we WILL have a meeting tomorrow morning at 7:00 AM Pacific time (as per the calendar). I look forward to speaking with everyone tomorrow!

hartm (Tue, 03 Apr 2018 21:32:52 GMT):
The planned meeting topics will include 1) going over the new lab infrastructure (we have a lab repo now), 2) discussing how we want to start working, and 3) discussing any sort of governance/proposal suggestions that people may have. Any other topics that people bring up during the course of the meeting will be fine as well.

nage (Tue, 03 Apr 2018 21:42:55 GMT):
I send my regrets. Myself and a bunch of others are at the Internet Identity Workshop. I’m really interested in how the build and packaging will shake out so we can transition Indy-crypto code over while we are still using it in our production system.

hartm (Wed, 04 Apr 2018 14:00:20 GMT):
Relevant links for today's meeting:

hartm (Wed, 04 Apr 2018 14:00:23 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

hartm (Wed, 04 Apr 2018 14:00:43 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

amundson (Wed, 04 Apr 2018 15:46:23 GMT):
@hartm ugh, I missed the meeting - any important decisions made?

hartm (Wed, 04 Apr 2018 15:48:04 GMT):
@amundson No worries! We didn't decide anything particularly important. We heard a lot from the Fabric folks in attendance (Bin and Jan) about how they wanted to be involved with crypto-lib. You can see a (very meager) outline of what went on in the discussion notes, which are in the second link above.

amundson (Wed, 04 Apr 2018 15:49:38 GMT):
should I move forward with adding python and/or go signing SDK from Sawtooth to the crypto-lib labs repo?

hartm (Wed, 04 Apr 2018 16:00:42 GMT):
@amundson You're welcome to do so if you like. It might be a good thing for comparison with Fabric and Indy.

amundson (Wed, 04 Apr 2018 16:04:39 GMT):
ideally, we mash them all up and come up with the one-true-way

Dan (Wed, 11 Apr 2018 14:04:35 GMT):
are we meeting now?

manu (Wed, 11 Apr 2018 14:06:03 GMT):
@Dan I think the idea is to have it every second week and since there was one last week there would be no meeting today

Dan (Wed, 11 Apr 2018 14:07:50 GMT):
thx @manu @hartm I have a recurring invite for every week on my calendar. Could you update that?

eramitg (Wed, 11 Apr 2018 15:40:48 GMT):
Hi Folks , I am an Phd Candidate in www.nitrr.ac.in my Linkedind Profile is https://www.linkedin.com/in/eramitg/ for sake of earning an Phd Degree i was proposed Blockchain Technology research work area to my guide so oom I request all of you gyus ,please guide me and assign me some research oriented task so that we mutullay benifited research related to Hyperledger Umbrella Project , All of you feel free to catch me on twitter or skype to https://twitter.com/eramitg1 or amitg.iitb skype id also in Zoom to in Zoom ID 3649222703 or whatsapp +917773011100 Regards

hartm (Wed, 11 Apr 2018 18:54:38 GMT):
@Dan Sorry, Tracy has control of the calendar, and I thought she updated it after this happened two weeks ago. @tkuhrt, has the calendar been updated? Thanks a lot.

tkuhrt (Wed, 11 Apr 2018 18:54:38 GMT):
Has joined the channel.

Dan (Wed, 11 Apr 2018 19:37:20 GMT):
I see. You forwarded the community calendar notice. I'll just delete that invite and get it directly.

yxnl (Thu, 12 Apr 2018 15:05:49 GMT):
Has joined the channel.

eramitg (Thu, 12 Apr 2018 16:43:55 GMT):
Hey folks anyone would like to crypto-lib research issue for development with me

bdu 5 (Sat, 14 Apr 2018 09:55:51 GMT):
Has joined the channel.

robinrob (Mon, 16 Apr 2018 21:37:10 GMT):
Has joined the channel.

hartm (Wed, 18 Apr 2018 00:16:30 GMT):
@here Reminder: we will be having a meeting tomorrow at the usual time (7:00 AM Pacific time--check the Hyperledger calendar for your time zone). Thanks!

hartm (Wed, 18 Apr 2018 13:59:34 GMT):
Meeting notes (and attendee list): https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

Jan.Camenisch (Wed, 18 Apr 2018 14:04:16 GMT):
Has joined the channel.

Dan (Wed, 18 Apr 2018 14:09:08 GMT):
Paging @nage or others from Indy for crypto lib meeting

nage (Wed, 18 Apr 2018 14:09:41 GMT):
I have to send regrets. I was double booked for the 8:00 hour

nage (Wed, 18 Apr 2018 14:10:18 GMT):
@ashcherbakov or @gudkov or @danielhardman ?

danielhardman (Wed, 18 Apr 2018 14:10:18 GMT):
Has joined the channel.

gudkov (Wed, 18 Apr 2018 14:11:51 GMT):
do you have the link?

manu (Wed, 18 Apr 2018 14:12:14 GMT):
https://zoom.us/j/685604650

hartm (Wed, 18 Apr 2018 14:41:29 GMT):
@nage Is this a bad time in general, or was this a one-time thing? Thanks!

nage (Wed, 18 Apr 2018 14:41:45 GMT):
I’m hoping a one time thing

sstercan (Sun, 22 Apr 2018 09:35:37 GMT):
Has joined the channel.

trthhrtz (Wed, 25 Apr 2018 07:21:07 GMT):
Has joined the channel.

IVictorFeng (Thu, 26 Apr 2018 02:30:38 GMT):
Has joined the channel.

lvndry (Tue, 01 May 2018 19:17:17 GMT):
Has joined the channel.

hartm (Wed, 02 May 2018 01:59:54 GMT):
@here Hi everyone--just a reminder that we'll have a meeting tomorrow at the usual time. Thanks!

Dan (Wed, 02 May 2018 13:51:34 GMT):
Looks like main agenda will be sawtooth<-->indy signing. I plan to be on (only a few min away now).

binhn (Wed, 02 May 2018 14:03:19 GMT):
can't get in

hartm (Wed, 02 May 2018 14:03:29 GMT):
My zoom link isn't working either.

hartm (Wed, 02 May 2018 14:06:07 GMT):
Try zoom.us/my/hyperledger.community.backup

hartm (Wed, 02 May 2018 14:06:10 GMT):
I'm in this one.

hartm (Wed, 02 May 2018 14:06:22 GMT):
(The main one seems to be occupied).

binhn (Wed, 02 May 2018 14:06:44 GMT):
@tkuhrt ^^

tkuhrt (Wed, 02 May 2018 14:07:37 GMT):
Just getting this message. Are you all good?

Dan (Wed, 02 May 2018 14:07:59 GMT):
you are probably on the old link

hartm (Wed, 02 May 2018 14:08:05 GMT):
I took control of the hyperledger.community.backup

tkuhrt (Wed, 02 May 2018 14:08:07 GMT):
I can kick people out if necessary

hartm (Wed, 02 May 2018 14:08:14 GMT):
The main one seems to be full.

Dan (Wed, 02 May 2018 14:08:28 GMT):
https://zoom.us/j/685604650

Dan (Wed, 02 May 2018 14:09:08 GMT):
There are about 6 of us on this one ^

hartm (Wed, 02 May 2018 14:09:23 GMT):
OK. We will join that one!

hartm (Wed, 02 May 2018 14:09:24 GMT):
Thanks!

tkuhrt (Wed, 02 May 2018 14:09:47 GMT):
That is why the community one is locked

Dan (Wed, 02 May 2018 14:09:52 GMT):
We are almost done finalizing the new Caesar cipher spec. Going to be best confidential txns ever!

tkuhrt (Wed, 02 May 2018 14:12:03 GMT):
The six of you joined the old meeting ID locking people out of joining the hyperledger.community meeting

Dan (Wed, 02 May 2018 14:14:48 GMT):
:-O

Dan (Wed, 02 May 2018 14:15:23 GMT):
Last week I deleted my old invite and grabbed the new invite out of the community calendar

tkuhrt (Wed, 02 May 2018 14:16:24 GMT):
When did you grab it?

tkuhrt (Wed, 02 May 2018 14:16:33 GMT):
It was updated on Monday

Dan (Wed, 02 May 2018 14:16:40 GMT):
Monday of this week?

tkuhrt (Wed, 02 May 2018 14:16:43 GMT):
Yep

Dan (Wed, 02 May 2018 14:16:53 GMT):
oh yeah I updated last week

tkuhrt (Wed, 02 May 2018 14:17:24 GMT):
Update again, please. :) I am going to delete old meeting IDs so that this won't happen again.

Dan (Wed, 02 May 2018 14:19:37 GMT):
https://github.com/hyperledger-labs/crypto-lib

eabiodun (Wed, 02 May 2018 14:22:27 GMT):
Has joined the channel.

jlaw (Wed, 02 May 2018 14:23:15 GMT):
Has joined the channel.

binhn (Wed, 02 May 2018 14:26:21 GMT):
From Daniel Hardman to Everyone: (10:22 AM) indy-crypto bls signatures: https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/src/ffi/bls.rs indy-crypto Pedersen commitments: https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/src/utils/commitment.rs From Daniel Hardman to Everyone: (10:24 AM) indy_crypto_sign() prototype that’s not yet in indy-crypto repo (the one that has a dependency on the wallet construct and needs to be moved down): https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/crypto.rs#L167

Dan (Wed, 02 May 2018 14:37:29 GMT):
https://github.com/hyperledger-labs/crypto-lib/blob/master/rust/src/signing/mod.rs#L142

Dan (Wed, 02 May 2018 14:39:29 GMT):
python implementation of the signing library https://github.com/hyperledger/sawtooth-core/tree/master/signing/sawtooth_signing

Dan (Wed, 02 May 2018 14:48:37 GMT):
Open question from meeting: Should threshold signatures etc fit into a unified signing interface or should there be multiple APIs?

dhuseby (Wed, 02 May 2018 14:59:06 GMT):
Ideally we’d design an API that is abstracted enough that we avoid having multiple.

danielhardman (Wed, 02 May 2018 15:21:06 GMT):
My action items from the meeting today: 1. Study the code that the Sawtooth team committed to github.com/hyperledger-labs/crypto-lib; produce a mapping to indy constructs and post the mapping here and on indy and sawtooth mailing lists 2. Per Hart's request, produce a clean summary of indy APIs that omits all the messy details, so pure API comparison is easy

amundson (Wed, 02 May 2018 15:27:26 GMT):
@danielhardman there are examples of the Sawtooth signing code in other languages as well if that is helpful

MohitYadav2317 (Fri, 04 May 2018 19:46:14 GMT):
Has joined the channel.

JonGeater (Mon, 07 May 2018 17:13:54 GMT):
Has joined the channel.

JonGeater (Mon, 07 May 2018 17:14:24 GMT):
Hi All, sorry I’m late to the party. Been locked out of chat for a while and hadn’t noticed...

JonGeater (Mon, 07 May 2018 17:15:16 GMT):
I’ll review progress to date and join the call on 16th, time willing (I have customer meetings all day but will try to carve out the slot). Hope I can be helpful to folks

JonGeater (Mon, 07 May 2018 17:16:56 GMT):
Just jumping on in here, I have an implementation of threshold sig that fits behind both PKCS#11 and the eIDAS remote signing APIs just fine. I don’t think it should matter how your key material is protected or processed for what signing API you call

JonGeater (Mon, 07 May 2018 17:17:50 GMT):
(That’s @Dan )

LoveshHarchandani (Mon, 07 May 2018 20:38:15 GMT):
Has joined the channel.

hartm (Mon, 07 May 2018 20:49:08 GMT):
@JonGeater You may also want to talk to the Indy guys about that--they also need threshold signatures (linking @nage).

JonGeater (Mon, 07 May 2018 20:51:00 GMT):
Cool will do.

JonGeater (Mon, 07 May 2018 20:56:28 GMT):
Popped an ask in #indy

Starseven (Tue, 08 May 2018 11:56:03 GMT):
Has joined the channel.

Dan (Tue, 08 May 2018 13:05:55 GMT):
@JonGeater that sounds cool. The question I think you were responding to was whether there should be one signing / verification API that would cover all sig types including ECDSA & Threshold. Or whether it would be better to have those APIs separate.

JonGeater (Tue, 08 May 2018 13:42:55 GMT):
@Dan yes exactly. I agree with @dhuseby that we should be able to abstract sufficiently to make it a single API.

JonGeater (Tue, 08 May 2018 13:44:13 GMT):
The management piece (mainly just key generation in this case) is very different and will get complex, but you had that problem anyway

manu (Tue, 08 May 2018 13:46:39 GMT):
@JonGeater Sounds interesting, could you share a link to the implementation? Which scheme do you implement?

JonGeater (Tue, 08 May 2018 13:48:39 GMT):
(An assumption I’m making here, which is very important, is that the design of the API will delegate policy enforcement to inside the crypto module and so you won’t have to express semantic details of things like shares and access control inline with the crypto calls themselves. I hope this is the line we’re going down. So either an authorised session model or an opaque authtoken model)

JonGeater (Tue, 08 May 2018 13:49:55 GMT):
Hi @manu, yes a few people have asked, I’m looking how we can expose it - it’s currently in our internal gitlab but should be easy enough to port to an exposed server given a little time. We’re going to put the paper out as a blog post very soon.

JonGeater (Tue, 08 May 2018 13:51:26 GMT):
The scheme is a fairly vanilla Damgard. We explicitly were not trying to improve the art in MPC signing itself, but rather prove out the other two ends: higher assurance key sharing at the management end, and simple abstract API integration at the client

adave (Wed, 09 May 2018 06:34:06 GMT):
Has joined the channel.

nfarley (Thu, 10 May 2018 10:45:19 GMT):
Has joined the channel.

mansoor (Thu, 10 May 2018 10:58:44 GMT):
Has joined the channel.

rfitzpatrick (Thu, 10 May 2018 11:47:39 GMT):
Has joined the channel.

sauravverma (Tue, 15 May 2018 10:29:30 GMT):
Has joined the channel.

hartm (Wed, 16 May 2018 02:04:36 GMT):
@here Cancelling tomorrow's meeting--I think too many people will be away for us to have a reasonable meeting. Thanks, and talk to you all in two weeks!

danielhardman (Wed, 16 May 2018 03:58:31 GMT):
@MALodder , are you in this channel?

mpiekarska (Fri, 18 May 2018 22:23:17 GMT):
Has joined the channel.

robwahl (Sat, 19 May 2018 16:09:23 GMT):
Has joined the channel.

cre8bidio (Tue, 22 May 2018 05:33:11 GMT):
Has joined the channel.

username343 (Wed, 23 May 2018 11:59:05 GMT):
Has joined the channel.

acuestareig (Thu, 24 May 2018 15:26:06 GMT):
Has joined the channel.

acuestareig (Thu, 24 May 2018 15:28:51 GMT):
Has left the channel.

Gandalf (Sun, 27 May 2018 04:11:56 GMT):
Has joined the channel.

Dan (Tue, 29 May 2018 15:40:09 GMT):
Reminder we have a meeting Wed at 2-3pm GMT (8am PDT) ```Agenda: 1. Common signing API (discuss proposed code from Indy perspective. Discuss differences between txn signing and block signing) 2. ZKLang next steps. (Please review slides from 4/18 meeting: http://researcher.watson.ibm.com/researcher/files/zurich-JCA/ZKLang%20-%20v4.pdf) ``` Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community Or iPhone one-tap : US: +16465588656,,4034983298# or +16699006833,,4034983298# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free) Meeting ID: 403 498 3298 International numbers available: https://zoom.us/u/bAaJoyznp

Dan (Tue, 29 May 2018 15:40:09 GMT):
Reminder we have a meeting Wed at 2-3pm GMT (8am PDT) Agenda: 1. Common signing API (discuss proposed code from Indy perspective. Discuss differences between txn signing and block signing) 2. ZKLang next steps. (Please review slides from 4/18 meeting: http://researcher.watson.ibm.com/researcher/files/zurich-JCA/ZKLang%20-%20v4.pdf) _Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community Or iPhone one-tap : US: +16465588656,,4034983298# or +16699006833,,4034983298# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free) Meeting ID: 403 498 3298 International numbers available: https://zoom.us/u/bAaJoyznp_

jwaup (Wed, 30 May 2018 13:53:21 GMT):
Has joined the channel.

sheehan (Wed, 30 May 2018 14:03:44 GMT):
Has joined the channel.

VipinB (Wed, 30 May 2018 14:06:20 GMT):
Has joined the channel.

VipinB (Wed, 30 May 2018 14:08:46 GMT):
minutes https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit

PoojaVarshneya (Wed, 30 May 2018 16:06:18 GMT):
Has joined the channel.

rogerwilcos (Wed, 30 May 2018 21:56:45 GMT):
Has joined the channel.

harika.n (Fri, 01 Jun 2018 11:30:00 GMT):
Has joined the channel.

RyanWest (Thu, 07 Jun 2018 21:07:29 GMT):
Has joined the channel.

abraham (Fri, 08 Jun 2018 04:03:28 GMT):
Has joined the channel.

hartm (Wed, 13 Jun 2018 01:38:03 GMT):
@here Just a reminder we have a meeting tomorrow at the usual time (7:00 AM bright and early Pacific time). Hope to hear from many of you then! Thanks!

abraham (Wed, 13 Jun 2018 09:17:54 GMT):
Hi, i'm new here, the exact starting time is 8 am PDT?

haggs (Wed, 13 Jun 2018 13:49:28 GMT):
Has joined the channel.

hartm (Wed, 13 Jun 2018 13:50:43 GMT):
@abraham It's 7 am pacific time--so in about 10 minutes.

MALodder (Wed, 13 Jun 2018 14:41:24 GMT):
Here is link to a document of possible signature types https://docs.google.com/spreadsheets/d/1ms2q-oKkfIkoloz1SFq-_IAWdTHb7XzpUgaXdQsTPh0/edit?usp=sharing Please feel free to add to it if you are using a signature type that is not there

manu (Wed, 13 Jun 2018 14:55:12 GMT):
ECRYPT document mentioned in the call: http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf

VipinB (Wed, 13 Jun 2018 15:22:03 GMT):
@manu approved labs, I will ask for +1 from another steward to get this merged- the repo name and lab name has to be same

manu (Wed, 13 Jun 2018 15:31:05 GMT):
thanks!

VipinB (Wed, 13 Jun 2018 18:51:19 GMT):
Just ensure that you do -s option when you drop in code

ryanwest6 (Thu, 14 Jun 2018 02:29:33 GMT):
Has joined the channel.

nhelmy (Mon, 18 Jun 2018 21:08:17 GMT):
Has joined the channel.

nvxtien (Fri, 22 Jun 2018 11:46:36 GMT):
Has joined the channel.

VipinB (Mon, 25 Jun 2018 13:13:54 GMT):
Is crypto-lib call on this week? @hartm

hartm (Mon, 25 Jun 2018 19:14:15 GMT):
@VipinB Not sure--we will need to see the final hackfest schedule and phone availability. If possible, I'll set up a call.

VipinB (Mon, 25 Jun 2018 20:15:47 GMT):
It may not be at the same time? anyway...

hartm (Wed, 27 Jun 2018 07:58:05 GMT):
Looks like it will be in the 6:00-8:00 range (AM, Pacific time) on Thursday, among other times, although the schedule is never firm on hackfests. Not sure whether we'll be able to set up a call though.

alain2sf (Wed, 27 Jun 2018 13:36:11 GMT):
Has joined the channel.

dhuseby (Wed, 27 Jun 2018 14:25:15 GMT):
I'm sorry I couldn't make the call today

dhuseby (Wed, 27 Jun 2018 14:25:24 GMT):
I'm literally on a plane to New Orleans

dhuseby (Wed, 27 Jun 2018 14:25:36 GMT):
I tried to call in using Zoom and it seems to be working but I'm hearing no audio

dhuseby (Wed, 27 Jun 2018 14:25:53 GMT):
have fun in amsterdam

dhuseby (Wed, 27 Jun 2018 14:25:56 GMT):
I wish I was there

hartm (Thu, 28 Jun 2018 11:06:58 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

hartm (Thu, 28 Jun 2018 11:07:09 GMT):
Above is the project proposal document.

nage (Thu, 28 Jun 2018 11:13:56 GMT):
Introduction deck we are shared at the Hackfest https://docs.google.com/presentation/d/1lz3AcHSoHR0xZ_fML--8I2lsUUO3L0WmXeZXqVNU27c

nage (Thu, 28 Jun 2018 11:14:16 GMT):
If you would like edit rights for the doc PM your google account address and I will add you

dimaxgl (Thu, 28 Jun 2018 11:49:53 GMT):
Has joined the channel.

chilipepper (Thu, 28 Jun 2018 12:03:23 GMT):
Has joined the channel.

sativ (Thu, 28 Jun 2018 12:21:34 GMT):
Has joined the channel.

rjones (Thu, 28 Jun 2018 12:25:15 GMT):
Has joined the channel.

rjones (Thu, 28 Jun 2018 12:25:20 GMT):
https://lists.hyperledger.org/g/labs

iserikov (Thu, 28 Jun 2018 12:26:31 GMT):
Has joined the channel.

hartm (Thu, 28 Jun 2018 12:28:51 GMT):
Everyone, please join the labs list (listed above) if you're interested in following along until we have an email list. Thanks!

neewy (Thu, 28 Jun 2018 12:29:01 GMT):
Has joined the channel.

rjones (Thu, 28 Jun 2018 12:47:00 GMT):
https://github.com/hyperledger/fabric-amcl go implementation

hartm (Thu, 28 Jun 2018 13:11:05 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

RyanBennett (Thu, 28 Jun 2018 13:11:56 GMT):
Has joined the channel.

alexeykoren (Thu, 28 Jun 2018 13:17:30 GMT):
Has joined the channel.

alkopnin (Thu, 28 Jun 2018 13:17:39 GMT):
Has joined the channel.

doom2doom (Thu, 28 Jun 2018 13:27:57 GMT):
Has joined the channel.

Dan (Thu, 28 Jun 2018 16:42:03 GMT):
I can't tell from the online notes.. does zmix = zklang?

Dan (Thu, 28 Jun 2018 16:42:31 GMT):
Also notes imply indy is dropping BLS signatures in favor of something in zmix?

hvandurme (Fri, 29 Jun 2018 07:54:06 GMT):
Has joined the channel.

nage (Fri, 29 Jun 2018 08:27:48 GMT):
no zmix is the CL signature implementation. ZKLang will be part of the ZMix interface (eventually)

nage (Fri, 29 Jun 2018 08:27:56 GMT):
we are keeping our BLS signature stuff in the ZMix repo for now

nage (Fri, 29 Jun 2018 08:28:43 GMT):
I'm working on replacing "indy crypto" names in the indy-crypto repo with "zmix", but essentially the ZMix repo will start with the code in indy-crypto

jlaw (Fri, 29 Jun 2018 08:55:02 GMT):
Here's the draft of the applications track document from the ZKProof.org conference: https://docs.google.com/document/d/1spgtYG8iXZ_NjUXdN8AEdKdGmaulE8r-mf7NsQ-_y4E

AbidiBassem (Fri, 29 Jun 2018 11:07:43 GMT):
Has joined the channel.

jaromil (Fri, 29 Jun 2018 11:57:16 GMT):
Has joined the channel.

jaromil (Fri, 29 Jun 2018 11:59:36 GMT):
hi everyone from hyperledger hackfest in Amsterdam. I've been attending some talks and interactions, while I'm working on the integration of my VM (zenroom.dyne.org) into some projects. I've been told I should join this group too, since I have experience of using amcl (milagro) in C and succesfully build it to wasm too (that's one of the zenroom targets). I'm a sporadic and mostly docs related contributor to the C milagro implementation.

jaromil (Fri, 29 Jun 2018 12:03:36 GMT):
I think it was @nage suggesting that. You got me sooo interested that I've even accepted to leave IRC for a web interface :^) I'd be happy to help with milagro if needed and to reply any question about zenroom. I'm hacking away on my laptop in the big room and will attend next sessions if you like to meet in person. @nage if you are still around today would like to have a brief talk before leaving!

nage (Fri, 29 Jun 2018 12:04:12 GMT):
Please!

jaromil (Fri, 29 Jun 2018 22:13:49 GMT):
I'd like to write an email so subscribed hyperledger-technical-discuss writing text in emacs <3 hope someone is attending the moderated queue

jaromil (Fri, 29 Jun 2018 22:14:31 GMT):
chat is unwieldy. so sorry i missed the meeting in person about crypto-lib, was there one?. i'd like to shill langsec for a moment :^D

bbehlendorf (Sat, 07 Jul 2018 21:48:38 GMT):
Has joined the channel.

MALodder (Mon, 09 Jul 2018 16:57:39 GMT):
@manu Do you have any specific tests for z-mix that you have so far? It would be nice to build on your starting point if any

manu (Mon, 09 Jul 2018 17:24:16 GMT):
Not yet, but i think the big picture should be fairly straightforward: we test parsing of valid JSON ZKL statements, test whether we can successfully create a proof with a valid corresponding witness, and check that the proof verifies. And the proof components should allow for individual unit tests

MALodder (Mon, 09 Jul 2018 22:27:25 GMT):
okay I'm starting with some initial documentation for z-mix that I can have committed this week

lovesh (Tue, 10 Jul 2018 19:16:29 GMT):
Hello, who has merge rights to https://github.com/hyperledger-labs/z-mix? Can someone give Mike Lodder the merge rights? His github name is `mikelodder7`

MALodder (Tue, 10 Jul 2018 20:26:52 GMT):
Lovesh and I have created some PR's for z-mix and need them reviewed. Who has write access to z-mix?

lovesh (Tue, 10 Jul 2018 21:34:41 GMT):
I am assuming we will use Apache milagro crypto for our implementation. For that we need to build a rust crate from the amcl source which requires us to choose curves we want to work with. Which curves do we wanna support? I am assuming we can start with BLS12-381 (supports pairing).

lovesh (Tue, 10 Jul 2018 22:00:19 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=RNe58vhaAJgw6rM4y) @MALodder Both of us have access, thanks to Tracy

lovesh (Tue, 10 Jul 2018 22:18:18 GMT):
Also, do we need a separate repository like hyperledger-labs/amcl or we are ok with amcl being a sub crate inside z-mix

lovesh (Tue, 10 Jul 2018 22:18:18 GMT):
Also, do we need a separate repository like hyperledger-labs/amcl or are we ok with amcl being a sub crate inside z-mix

hartm (Wed, 11 Jul 2018 02:40:12 GMT):
@here Just a reminder--we have a meeting tomorrow at the usual time. I've emailed the (rough) agenda to the labs email list--sign up for it if you haven't already. Thanks!

n3m4nja (Wed, 11 Jul 2018 06:54:42 GMT):
Has joined the channel.

n3m (Wed, 11 Jul 2018 07:33:06 GMT):
Has joined the channel.

manu (Wed, 11 Jul 2018 07:41:54 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=yo7Z3PZeFYXRb8Rjn) @lovesh Sure, but I think at some point we should have it configurable and at least support a couple of curves, what do you think?

manu (Wed, 11 Jul 2018 07:51:57 GMT):
@lovesh @MALodder Didn't we say we won't do direct commits but do everything through PRs? Also, the license headers are missing on every file.

gudkov (Wed, 11 Jul 2018 09:19:23 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=3cNKWRcDzRJiobcjj) @manu We already updated AMCL crate to support different curves through build configuration and PR was accepted to upstream, but it isn't possible to select different curves in runtime for now.

hartm (Wed, 11 Jul 2018 14:02:06 GMT):
Meeting notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

Dan (Wed, 11 Jul 2018 14:04:04 GMT):
~~~~~~ Begin Meeting ~~~~~

hartm (Wed, 11 Jul 2018 14:36:11 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

hartm (Wed, 11 Jul 2018 14:36:29 GMT):
(Above is the very tentative project proposal document).

manu (Wed, 11 Jul 2018 14:38:33 GMT):
zmix deck: https://docs.google.com/presentation/d/1lz3AcHSoHR0xZ_fML--8I2lsUUO3L0WmXeZXqVNU27c/edit

MALodder (Wed, 11 Jul 2018 14:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=mGrpJkBd3kqyJQoaK) @manu Yes Lovesh and I are doing everything through PR's

hartm (Wed, 11 Jul 2018 14:40:39 GMT):
https://docs.google.com/presentation/d/1DbRUxM19vgL15_ivSuCFiq0t7UInv6NODVf0OMNAP5g/edit#slide=id.p6

Dan (Wed, 11 Jul 2018 14:58:30 GMT):
@dhuseby can you please double check that the lab repo prevents direct pushing to master?

Dan (Wed, 11 Jul 2018 15:00:01 GMT):
~~~~~~ End Meeting ~~~~

dhuseby (Wed, 11 Jul 2018 15:48:29 GMT):
@Dan I just pinged Ry about the repo question, I'll let you know what he says.

dhuseby (Wed, 11 Jul 2018 18:06:21 GMT):
@Dan @rjones said that we'll probably have to use the PR process.

dhuseby (Wed, 11 Jul 2018 18:06:24 GMT):
he wasn't sure

MALodder (Wed, 11 Jul 2018 20:39:35 GMT):
I have updated the repo to include the initial interface for the parser. If anyone has any objections please post them here or create a an issue in github

david.b.crypto (Thu, 12 Jul 2018 01:42:11 GMT):
Has joined the channel.

Dan (Thu, 12 Jul 2018 13:04:10 GMT):
Thanks @dhuseby. @rjones question was whether the repo allowed force pushes. Definitely don't want that. Do want PR process and enforcement of DCO etc.

rjones (Thu, 12 Jul 2018 14:25:51 GMT):
it should not allow force pushes in the default config

Jan.Camenisch (Wed, 18 Jul 2018 14:07:06 GMT):
hej, it seem my zoom link for the call today is outdated. Could anyone send the recent link

hartm (Thu, 19 Jul 2018 01:01:06 GMT):
@Jan.Camenisch Hi Jan, the meetings are every other week (and this week is the off week). The Hyperledger calendar (https://wiki.hyperledger.org/community/calendar-public-meetings) has the schedule and all the meeting links.

Jan.Camenisch (Thu, 19 Jul 2018 09:13:08 GMT):
Thanks Hart - I did eventually realize that I was a week off :-) In any case thanks for the link, that will help to realize that faster next time!

sm1972 (Mon, 23 Jul 2018 14:30:43 GMT):
Has joined the channel.

hartm (Wed, 25 Jul 2018 01:47:00 GMT):
@here Just a reminder for tomorrow's meeting at the usual time (7:00 AM Pacific time). Hope to talk to everyone tomorrow! Thanks!

hartm (Wed, 25 Jul 2018 14:03:58 GMT):
https://docs.google.com/document/d/1BvAXUGR6Gur12yEPbqCegiAuOChiZqEMp6CO3z8RxMk/edit?usp=sharing

thiyagucse01 (Fri, 27 Jul 2018 10:44:21 GMT):
Has joined the channel.

MALodder (Fri, 27 Jul 2018 21:03:02 GMT):
Does anyone have a preference for the crypto-lib namespace

MALodder (Fri, 27 Jul 2018 21:03:48 GMT):
keep in mind that when it compiles, the library name will be prefixed with *lib* so libcrypto-lib would look weird to me

MALodder (Fri, 27 Jul 2018 21:04:43 GMT):
hypercrypto? hcrypto?

MALodder (Fri, 27 Jul 2018 21:05:07 GMT):
hyperledger-crypto?

MALodder (Fri, 27 Jul 2018 21:05:11 GMT):
hl-crypto?

MALodder (Fri, 27 Jul 2018 21:05:58 GMT):
I don't think hcl would work due to https://www.hcl.com

MALodder (Fri, 27 Jul 2018 21:07:18 GMT):
plus crypto and acid?

MALodder (Fri, 27 Jul 2018 21:12:17 GMT):
I'd like opinions before I give mine

hartm (Fri, 27 Jul 2018 22:19:51 GMT):
I have to attend the marketing committee meeting next week to discuss stuff around the publication of the whitepaper. Should I ask them to try to come up with something good?

manu (Mon, 30 Jul 2018 13:41:13 GMT):
HCl would be funny given that NaCl is a well-known crypto library. But i agree that the -lib is no good, so hyperledger-crypto or hl-crypto make sense to me. Given that e.g. hyperledger fabric's repo is called 'fabric', that would mean our repo should be called 'crypto'.

MALodder (Mon, 30 Jul 2018 19:49:34 GMT):
I'm think hl-crypto

amundson (Tue, 31 Jul 2018 00:55:36 GMT):
@MALodder any thoughts on approach we should take to merging sawtooth and indy signing libraries?

MALodder (Tue, 31 Jul 2018 01:15:13 GMT):
I was thinking that’s what the common signing interface was for. See https://docs.google.com/document/d/1BvAXUGR6Gur12yEPbqCegiAuOChiZqEMp6CO3z8RxMk @amundson [ ](https://chat.hyperledger.org/channel/crypto-lib?msg=SquDHu6ZP4dfnuwNn)

MALodder (Tue, 31 Jul 2018 01:15:34 GMT):
I’m going to be adding privacy preserving signatures to that as well

MALodder (Tue, 31 Jul 2018 01:15:54 GMT):
Let me know if what’s there doesn’t work. Feel free to add comments

MALodder (Tue, 31 Jul 2018 01:16:36 GMT):
I have submitted a PR to merge sawtooth and Indy into one repo. Then I’m going to take a try and merging the interface

amundson (Tue, 31 Jul 2018 01:22:18 GMT):
@MALodder the doc doesn't say much :)

MALodder (Tue, 31 Jul 2018 01:22:28 GMT):
Indy uses Ed25519 signatures and BLS-254

amundson (Tue, 31 Jul 2018 01:24:46 GMT):
what I'm wondering is what we find lacking in the Sawtooth signing API, so we can discuss specifics on how we would integrate those things. or if we don't have consensus with Sawtooth's signing API as a starting point, I think then it would be great to know why so we can attempt to address that in the new design.

rjones (Tue, 31 Jul 2018 01:25:31 GMT):
yeah open issue https://github.com/dear-github/dear-github/issues/157

amundson (Tue, 31 Jul 2018 01:32:19 GMT):
If we end up with something backward-compatible or at least reasonably close to the current sawtooth signing api, that will greatly help us port to crypto-lib (and may give us a boost in creating the other language implementations, if we can take code from Sawtooth to get them started)

hartm (Tue, 31 Jul 2018 13:07:04 GMT):
I think the Sawtooth signing interface is very close to what we had in mind in terms of an API.

hartm (Tue, 31 Jul 2018 14:09:26 GMT):
It wasn't that the Sawtooth API is "lacking", just that we need more general rules for signature APIs if we want to extend an API to more signature protocols.

MALodder (Tue, 31 Jul 2018 14:15:49 GMT):
Probably the biggest change we need to make is right now with the sawtooth signing api is the notion for type objects. Currently its using a factory method to create a context. We are proposing that we use type objects that encapsulate the algorithms. Taking what's currently there, we can create the ECDSA_Secp256K1_SHA256 type object. It could still be created using the factory method.

MALodder (Tue, 31 Jul 2018 14:17:08 GMT):
Maybe we could shorten the names to just SECP256K1_SHA256 but I like having the ECDSA prefix for crypto noobs

MALodder (Tue, 31 Jul 2018 14:17:27 GMT):
maybe that's not a problem with Hyperledger projects. Thoughts?

amundson (Tue, 31 Jul 2018 14:44:29 GMT):
@MALodder we could do a before/after of the secp256k1 test code (which is essentially examples for our purpose), so that it's not abstract; the rust code is https://github.com/hyperledger/sawtooth-core/blob/master/sdk/rust/src/signing/secp256k1.rs and the python code is https://github.com/hyperledger/sawtooth-core/blob/master/signing/tests/test_secp256k1_signer.py

amundson (Tue, 31 Jul 2018 14:47:41 GMT):
so, for example, we can take single_key_signing() which today looks like:

amundson (Tue, 31 Jul 2018 14:47:45 GMT):
```let context = create_context("secp256k1").unwrap(); let factory = CryptoFactory::new(&*context); let priv_key = Secp256k1PrivateKey::from_hex(KEY1_PRIV_HEX).unwrap(); let signer = factory.new_signer(&priv_key); let signature = signer.sign(&String::from(MSG1).into_bytes()).unwrap(); ```

amundson (Tue, 31 Jul 2018 14:47:56 GMT):
and mock up what it would look like after

MALodder (Tue, 31 Jul 2018 15:36:10 GMT):
sure

amundson (Tue, 31 Jul 2018 16:32:42 GMT):
FWIW, one of the enhancements we are talking about is a function we can combine the first four lines for things like CLI commands - "let signer = create_secp256k1_signer_from_hex(KEY1_PRIV_HEX)" or something like that since those four lines, while useful for more complex apps, are boiler plate for the simple case.

MALodder (Wed, 01 Aug 2018 14:30:41 GMT):
I have added content for randomizable signatures https://docs.google.com/document/d/1BvAXUGR6Gur12yEPbqCegiAuOChiZqEMp6CO3z8RxMk/edit#bookmark=id.wfot47f66ki4

manoj485 (Mon, 06 Aug 2018 09:52:17 GMT):
Has joined the channel.

manoj485 (Mon, 06 Aug 2018 09:52:49 GMT):
Hi , I need to create publickey when user registered and need send it to user, then user needs create privatekey it is possible in hyperledger? if possible how?

hartm (Wed, 08 Aug 2018 01:44:06 GMT):
@here Just a reminder of tomorrow's meeting. Looking forward to speaking with everyone. Thanks!

hartm (Wed, 08 Aug 2018 14:05:41 GMT):
Meeting Notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

hartm (Wed, 08 Aug 2018 14:31:04 GMT):
(Ancient, needs edits) "Proposal" document: https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

Dan (Wed, 08 Aug 2018 14:59:59 GMT):
@dhuseby I think LGPL is a compatible license but can you double check that's copacetic? (Per discussion that libsnarks has a downstream link dependency on https://gmplib.org/)

MALodder (Wed, 08 Aug 2018 16:08:21 GMT):
So I wasn't clear what the next steps that are required to move crypto-lib from labs to incubator. Can someone put those details here?

amundson (Wed, 08 Aug 2018 17:06:22 GMT):
has anyone looked at Ring, and if so, any thoughts? https://briansmith.org/rustdoc/ring/signature/index.html

MALodder (Wed, 08 Aug 2018 17:37:21 GMT):
I've looked at it and played around with it. If 1 was super easy to use and 10 was the hardest I would peg it at a 5. They've simplified some things but expose some things like passing RNG to key creation and signing which I think could be abstracted. We could use it for some things but if you include openssl and lib sodium then you have everything ring exposes but faster in performance

manoj485 (Thu, 09 Aug 2018 06:46:42 GMT):
how can i get block hash from ledger

MALodder (Thu, 09 Aug 2018 18:45:30 GMT):
Which ledger?

VipinB (Fri, 10 Aug 2018 13:42:34 GMT):
@manoj485 this is probably not the best channel for this question- if it is a specific ledger then ask in the appropriate channel i.e. #fabric #sawtooth #burrow etc. Or #hyperledger-explorer

alkopnin (Fri, 10 Aug 2018 15:25:54 GMT):
@hartm Hi there, ZKLang regular meetings on Mondays are mentioned in the last minutes. What is the time and is it every Monday? Do you already have the calendar event?

MALodder (Fri, 10 Aug 2018 15:42:01 GMT):
8AM MDT every Monday

MALodder (Fri, 10 Aug 2018 15:58:49 GMT):
@amundson do you have some time to discuss what you have in crypto-lib and consolidating that to the simple signature interface with me?

hartm (Fri, 10 Aug 2018 16:42:58 GMT):
@MALodder The ZKLang meeting doesn't appear to be in the Hyperledger calendar. Do you guys think you could ask to have it added? Thanks!

MALodder (Fri, 10 Aug 2018 16:43:24 GMT):
Yes

ericmvaughn (Fri, 10 Aug 2018 17:57:13 GMT):
Has joined the channel.

amundson (Fri, 10 Aug 2018 18:34:39 GMT):
@MALodder yeah, I'll ping you via DM

lovesh (Mon, 13 Aug 2018 19:40:07 GMT):
One way function interface https://github.com/hyperledger-labs/z-mix/pull/9

rjones (Mon, 13 Aug 2018 19:44:33 GMT):
@MALodder I'm one of the people who adds it to the calendar - shoot me an email rjones@linuxfoundation.org

rjones (Mon, 13 Aug 2018 19:44:33 GMT):
@MALodder I'm the person that adds it to the calendar - shoot me an email rjones@linuxfoundation.org

rjones (Mon, 13 Aug 2018 19:44:44 GMT):
s/the/one of &/

lovesh (Mon, 13 Aug 2018 19:51:48 GMT):
Hash function interface https://github.com/hyperledger-labs/z-mix/pull/10

lovesh (Mon, 13 Aug 2018 20:05:32 GMT):
This interface is sufficient for both fixed-length output hash functions and XOFs. Would it be preferable to have 2 interfaces? The difference appears in the signature of the `digest` method.

lovesh (Tue, 14 Aug 2018 08:45:54 GMT):
Signature scheme interface https://github.com/hyperledger-labs/z-mix/pull/11

lovesh (Tue, 14 Aug 2018 09:09:41 GMT):
BLS12-381 curve from amcl https://github.com/hyperledger-labs/z-mix/pull/12

hartm (Tue, 14 Aug 2018 15:39:01 GMT):
@lovesh Where are you using one-way functions in your protocols? I'm not sure why you need that interface.

MALodder (Tue, 14 Aug 2018 16:30:35 GMT):
@rjones here is info, every monday at 8AM MDT https://zoom.us/j/594175308 Agenda: https://docs.google.com/document/d/1CwVljF8fS5NwF6NAppCvD4jLtH9t2m1rkut54hYGLm0

rjones (Tue, 14 Aug 2018 17:05:41 GMT):
@MALodder I can't access that agenda - it says access denied. Does it have public read access?

MALodder (Tue, 14 Aug 2018 17:05:55 GMT):
I’ll check

MALodder (Tue, 14 Aug 2018 17:06:00 GMT):
But probably not

rjones (Tue, 14 Aug 2018 17:09:44 GMT):
what do you want the meeting named?

MALodder (Tue, 14 Aug 2018 17:21:02 GMT):
Zklang

lovesh (Wed, 15 Aug 2018 15:37:57 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=j9RDF9Jjj54QN57Nj) @hartm When we need modular exponentiation or exponentiation of hash which is needed in creating domain pseudonyms in idemix

hartm (Thu, 16 Aug 2018 07:56:51 GMT):
@lovesh Are you using more than the explicit guarantees of a one-way function though (i.e., pseudorandomness of the output)?

manu (Thu, 16 Aug 2018 07:59:40 GMT):
we should maybe call it PRF instead

lovesh (Thu, 16 Aug 2018 08:51:33 GMT):
@hartm Yes, we want the output to be pseudorandom.

hartm (Thu, 16 Aug 2018 13:57:25 GMT):
@lovesh Manu is right here. The output of one-way functions doesn't have to be pseudorandom. This primitive isn't named correctly.

lovesh (Thu, 16 Aug 2018 14:07:57 GMT):
@hartm @manu Alright, i will rename. Thanks

hartm (Thu, 16 Aug 2018 14:09:34 GMT):
@lovesh Are you using any properties besides pseudorandomness of the output?

lovesh (Thu, 16 Aug 2018 14:40:25 GMT):
@hartm No

hartm (Thu, 16 Aug 2018 14:43:23 GMT):
@lovesh OK, as Manu suggests, we should probably call it a PRF then.

lovesh (Thu, 16 Aug 2018 15:00:07 GMT):
Rename one way function to PRF https://github.com/hyperledger-labs/z-mix/pull/13

hartm (Thu, 16 Aug 2018 18:13:01 GMT):
@lovesh I just looked at your code again. It doesn't look like you're computing a PRF since there's no secret key defined in your interface. It looks like you're just computing g^x for some value x over a curve with a known generator g. Can you explicitly define what you want to compute, and what properties you want the input and output to have? Thanks!

iserikov (Fri, 17 Aug 2018 12:31:49 GMT):
Guys! Please, Could you open https://docs.google.com/document/d/1CwVljF8fS5NwF6NAppCvD4jLtH9t2m1rkut54hYGLm0/edit for goriangray@gmail.com? Thanks.

larry618 (Sun, 19 Aug 2018 07:42:31 GMT):
Has joined the channel.

harish.drish (Tue, 21 Aug 2018 11:28:48 GMT):
Has joined the channel.

harish.drish (Tue, 21 Aug 2018 11:29:50 GMT):
hello all I am using hybride crypto js with webpack.....when I am running webpack it gibves me error: ERROR in ../node_modules/hybrid-crypto-js/lib/keymanager.js Module not found: Error: Can't resolve 'react-native' in '/home/hyper1/Sawtooth-projects/webpkdemoo/node_modules/hybrid-crypto-js/lib' @ ../node_modules/hybrid-crypto-js/lib/keymanager.js 1:0-42 30:8-20 40:8-20 @ ../node_modules/hybrid-crypto-js/lib/index.js @ ../app/module/createHost.js npm ERR! code ELIFECYCLE npm ERR! errno 2 npm ERR! webpk@1.0.0 start: `webpack ./app/module/createHost.js --output ./dist/bundle.js --mode development` npm ERR! Exit status 2 npm ERR! npm ERR! Failed at the webpk@1.0.0 start script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! /home/hyper1/.npm/_logs/2018-08-21T11_12_22_353Z-debug.log

harish.drish (Tue, 21 Aug 2018 11:30:21 GMT):
here is webpack config file: var path = require("path"); var DIST_DIR = path.join(__dirname, "dist"), CLIENT_DIR = path.join(__dirname, "src"); module.exports = { context: CLIENT_DIR, entry: "./app/module/createHost.js",//path relative to this file mode: "development", output: { path: DIST_DIR, filename: "bundle.js" }, resolve: { extensions: ['.js', '.json', '.node','.pem'] }, module: { rules: [ { test: /\.exec\.js$/, use: [ 'script-loader' ] }, { test: /\.node$/, use: 'node-loader' }, { test: /\.(node)$/, use: 'file-loader' } ] }, node: { fs: 'empty', net: 'empty', tls: 'empty', AccessibilityInfo: 'empty' } }

lovesh (Tue, 21 Aug 2018 12:16:03 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=WBic5M7hnxP78XRrC) @hartm The PRF's `new` method takes `args` which can contain the key. The objective is to have a function which takes an input in a certain group and can produce any output with equal probability in a group, preimage resistance is not an objective of this function

hartm (Tue, 21 Aug 2018 15:07:07 GMT):
@lovesh Is the input randomly chosen by an honest person or adversarially chosen by an attacker (or somewhere in between, i.e. the input is selected by an honest user but without full entropy)?

lovesh (Tue, 21 Aug 2018 16:11:43 GMT):
@hartm Input can be chosen by anyone including an adversary, the input has to respect some constraints like being in a field

MALodder (Tue, 21 Aug 2018 18:28:13 GMT):
I have submitted a (PR)[https://github.com/hyperledger-labs/crypto-lib/pull/6] that I'm hoping Sawtooth folks with be okay with. Can Sawtooth folks look at that API and see if they are okay with it and put their comments in here either way

hartm (Tue, 21 Aug 2018 22:07:37 GMT):
@lovesh OK, it does look like you need (and are using) a random oracle model PRF.

hartm (Wed, 22 Aug 2018 07:12:21 GMT):
@here Just a brief reminder for the upcoming meeting tomorrow (today, for many). Thanks!

lovesh (Wed, 22 Aug 2018 12:32:33 GMT):
Please review "Hashing on BLS-12-381 curve" https://github.com/hyperledger-labs/z-mix/pull/15

lovesh (Wed, 22 Aug 2018 12:37:23 GMT):
Question: There are methods to hash to groups G1 and G2, does it need domain separation between the byte representations of those 2 hashes

lovesh (Wed, 22 Aug 2018 12:37:23 GMT):
Question: There are methods to hash to groups G1 and G2, does it need domain separation between the byte representations of those 2 hashes. Do we need (point) compressed representation too?

lovesh (Wed, 22 Aug 2018 12:37:52 GMT):
@manu @hartm @MALodder

lovesh (Wed, 22 Aug 2018 12:37:52 GMT):
@manu @hartm @MALodder ^^^

Dan (Wed, 22 Aug 2018 13:49:31 GMT):
If you mean that the output of the hashes could contain some extra bits to flag their respective fields, I think that would be unconventional. If you mean that the wrapping functions would add bits to the respective group hashes to avoid collisions in the two groups, I also don't think I've seen that. Totally open to the idea that I'm just not familiar or that you are suggesting something else. I do see the use of domain separation within the keccak functions to avoid collisions between those hashes when the same inputs are used. e.g. sha3-384(1) != sha3-256(1)

manu (Wed, 22 Aug 2018 13:50:56 GMT):
I would do domain separation yes

lovesh (Wed, 22 Aug 2018 14:00:27 GMT):
@Dan You understood it correct. I have heard that domain separation is needed for security proofs, it might not be useful in a particular scenario but as a general practice you should. Or use a different hash function like sha2 for G1 and sha3 for G2

Dan (Wed, 22 Aug 2018 14:08:17 GMT):
(example from Lovesh per meeting discussion: https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design)

Dan (Wed, 22 Aug 2018 14:54:15 GMT):
@MALodder our java sdk relies on bitcoinj for the language wrapping of the secp256k1 library. It appears they use JNI if I'm looking at their code right. https://github.com/bitcoinj/bitcoinj

MALodder (Wed, 22 Aug 2018 15:25:43 GMT):
thanks @Dan

lovesh (Thu, 23 Aug 2018 11:12:10 GMT):
Please review "Pedersen commitments over BLS12-381" https://github.com/hyperledger-labs/z-mix/pull/16

lovesh (Thu, 23 Aug 2018 11:14:00 GMT):
I can request code review from specific people using the github interface, who would be interested? I selected @MALodder, @manu and @hartm for my recent PRs

david.b.crypto (Thu, 23 Aug 2018 15:09:13 GMT):
Hi

david.b.crypto (Thu, 23 Aug 2018 15:10:11 GMT):
where would I look to get a view of which algorithms are targeted for the common hyperledger crypto in the short to medium term?

david.b.crypto (Thu, 23 Aug 2018 15:10:50 GMT):
specifically i am interested in accumulators, group signatures and threshold encryption

lovesh (Thu, 23 Aug 2018 16:42:21 GMT):
@manu @Dan Domain separation has been added in the hash function PR

MALodder (Thu, 23 Aug 2018 18:28:02 GMT):
@david.b.crypto we are working on that part still

MALodder (Thu, 23 Aug 2018 18:28:19 GMT):
if you attend the bi-weekly calls then we would be happy to know what you are looking to add to it

MALodder (Thu, 23 Aug 2018 18:30:31 GMT):
I finished the changes necessary to allow native and portable for crypto-lib for secp256k1

MALodder (Thu, 23 Aug 2018 18:31:06 GMT):
@Dan @amundson can you please review the [PR](https://github.com/hyperledger-labs/crypto-lib/pull/6#pullrequestreview-147585598) and let me know if this still works for you

MALodder (Thu, 23 Aug 2018 18:31:06 GMT):
@Dan @amundson can you please review the (PR)[https://github.com/hyperledger-labs/crypto-lib/pull/6#pullrequestreview-147585598] and let me know if this still works for you

amundson (Thu, 23 Aug 2018 18:38:01 GMT):
@MALodder is the plan to add another implementation here - https://github.com/hyperledger-labs/crypto-lib/tree/master/rust/src/signing , say sekp256k1_milagro.rs, that uses what you added to the libhl-crypto/ directory?

MALodder (Thu, 23 Aug 2018 18:39:44 GMT):
the plan is remove that folder and use https://github.com/mikelodder7/crypto-lib/tree/master/libhl-crypto/src/signatures

amundson (Thu, 23 Aug 2018 18:48:31 GMT):
ok, I thought we were going down a path of trying to keep the API sawtooth uses (with adjustments to make it better) so that it was fairly easy to adopt

amundson (Thu, 23 Aug 2018 18:50:55 GMT):
the test code in libhl-crypto/src/signatures/secp256k1.rs looks very secp256k1 specific; do you have an algorithm agnostic API in mind that projects would use?

amundson (Thu, 23 Aug 2018 18:51:11 GMT):
(just referencing the tests because I was looking for examples)

MALodder (Thu, 23 Aug 2018 18:51:31 GMT):
Like a context?

amundson (Thu, 23 Aug 2018 18:51:40 GMT):
like the sawtooth signing API

MALodder (Thu, 23 Aug 2018 18:52:01 GMT):
We could wrap any signature in a context like object

MALodder (Thu, 23 Aug 2018 18:52:11 GMT):
the interface didn't change that much if you look at it

MALodder (Thu, 23 Aug 2018 18:52:32 GMT):
Its like the simple signature interface that was signed off

MALodder (Thu, 23 Aug 2018 18:52:42 GMT):
by the group

MALodder (Thu, 23 Aug 2018 18:52:55 GMT):
it supports two versions, the native version and the portable version

MALodder (Thu, 23 Aug 2018 18:53:06 GMT):
portable is milagro, native is libsecp256k1 version

amundson (Thu, 23 Aug 2018 18:56:31 GMT):
```let context = create_context("secp256k1").unwrap(); let factory = CryptoFactory::new(&*context); let priv_key = Secp256k1PrivateKey::from_hex(KEY1_PRIV_HEX).unwrap(); let signer = factory.new_signer(&priv_key); let signature = signer.sign(&String::from(MSG1).into_bytes()).unwrap();```

amundson (Thu, 23 Aug 2018 18:57:06 GMT):
so if we had that code today, what would that look like translated to this API?

MALodder (Thu, 23 Aug 2018 19:01:39 GMT):
``` let priv_key = secp256k1::Ecdsa256K1Sha256PrivateKey::from_hex(KEY1_PRIV_HEX).unwrap(); let signature = priv_key.sign(&String::from(MSG1).into_bytes()).unwrap() ```

MALodder (Thu, 23 Aug 2018 19:03:15 GMT):
I see yours expects a hexit signature so to add another line ``` let final_sig = bin2hex(signature.as_slice()); ```

amundson (Thu, 23 Aug 2018 19:04:12 GMT):
how are you sharing libsecp256k1 context between keys? context creation is super expensive. global variables?

MALodder (Thu, 23 Aug 2018 19:04:41 GMT):
each key has their own context

MALodder (Thu, 23 Aug 2018 19:04:59 GMT):
its not quite as expensive if you say signing only or verify only

amundson (Thu, 23 Aug 2018 19:09:41 GMT):
but, presumably in your API the priv_key signing and pub_key has to do verification since you don't have a separation between the data object (a private key or public key) and the algorithm code (signer, verifier); so if you have a lot of public keys, you are going to end up with a lot of contexts, and that is going to be slow. The app would have to do smart caching of public keys especially as recreating them would be very bad indeed.

MALodder (Thu, 23 Aug 2018 19:11:28 GMT):
so you're assuming only one context is created and passed around am I right

amundson (Thu, 23 Aug 2018 19:12:57 GMT):
so, say I'm getting a transaction off the network and it's associated public key. I create the public_key object and then verify that transaction. Today within sawtooth, we don't cache any public key objects, because that is all very efficient since there is only one verifier (and context). If public key and verifier are the same, then I need to either take the efficiency hit (because of the creation of a context), or I need to cache public key objects so I can avoid recreating it. (Because it is likely to see the same public keys come up over and over, the caching would work but not something we need to do today.)

MALodder (Thu, 23 Aug 2018 19:13:02 GMT):
the only other option would be to create a shared global variable

MALodder (Thu, 23 Aug 2018 19:15:12 GMT):
I can do that

amundson (Thu, 23 Aug 2018 19:15:18 GMT):
which we rejected on principle (we would probably have to deal with side effects we can't describe easily before we run into them), which is why we create the context and derive a signer or verifier from it, and treat the key as just data until we need to use it. so we can pass the signer or verifier around when we startup the validator (once).

MALodder (Thu, 23 Aug 2018 19:15:43 GMT):
the problem is that is very secp256k1 specific

MALodder (Thu, 23 Aug 2018 19:16:25 GMT):
specifically libsecp256k1 specific

MALodder (Thu, 23 Aug 2018 19:16:36 GMT):
milagro secp256k1 or openssl do not have this

MALodder (Thu, 23 Aug 2018 19:16:56 GMT):
libsodium or secp384r1 libraries I've used don't use context either

amundson (Thu, 23 Aug 2018 19:21:46 GMT):
that just makes context creation a no-op for those implementations

amundson (Thu, 23 Aug 2018 19:22:11 GMT):
have you done any performance testing of milagro vs. libsecp256k1?

MALodder (Thu, 23 Aug 2018 19:22:14 GMT):
okay but now its complicating every other library

MALodder (Thu, 23 Aug 2018 19:22:15 GMT):
yes

MALodder (Thu, 23 Aug 2018 19:22:24 GMT):
libsecp256k1 is 4 times faster

amundson (Thu, 23 Aug 2018 19:23:20 GMT):
it's not complicating every other library. it is a slightly more complex API for the user of the API.

amundson (Thu, 23 Aug 2018 19:25:28 GMT):
but even then, the lines above could be reduce to two with a convenience function for the users of the API that don't care about performance (or are only using algorithms where re-creating context is efficient)

MALodder (Thu, 23 Aug 2018 19:33:05 GMT):
it just doesn't make sense to me to have every other class use a no-op

MALodder (Thu, 23 Aug 2018 19:39:30 GMT):
what I'm saying is that its not necessary for those other libraries to do that. They don't require it. So to make every consumer of the crypto-lib create a context that does nothing for the 99% doesn't make sense to me so the 1% can be happy.

MALodder (Thu, 23 Aug 2018 19:41:07 GMT):
I'd like to find another solution is what I'm saying

DavorKljajic (Fri, 24 Aug 2018 11:33:19 GMT):
Has joined the channel.

DavorKljajic (Fri, 24 Aug 2018 11:33:24 GMT):
hello, I'm wondering if someone has worked custom implementation mps with idemix, and where i can find the setup, on official site is not clear to much.

Bhanu (Fri, 24 Aug 2018 16:53:07 GMT):
Has joined the channel.

lovesh (Mon, 27 Aug 2018 06:42:04 GMT):
@amundson Regarding the `context` object, the constructor of the signature interface in z-mix `SignatureScheme`'s `new` method, https://github.com/hyperledger-labs/z-mix/blob/master/src/signatures/mod.rs#L25 can be used to create the context and then subsequent calls to sign and verify can be used to with different keys without re-creating the context object. There is sample code above in that file that should clarify my proposal

lovesh (Mon, 27 Aug 2018 06:42:04 GMT):
@amundson Regarding the `context` object, the constructor of the signature interface in z-mix `SignatureScheme`'s `new` method, https://github.com/hyperledger-labs/z-mix/blob/master/src/signatures/mod.rs#L25 can be used to create the context and then subsequent calls to sign and verify can be used with different keys without re-creating the context object. There is sample code above in that file that should clarify my proposal

MALodder (Mon, 27 Aug 2018 14:56:15 GMT):
@amundson I have implemented *SignatureScheme* that should address the *context* object issue and doesn't complicate things. I believe you should be happy with it. I will be pushing as part of the open PR

MALodder (Mon, 27 Aug 2018 14:56:24 GMT):
Look for it in about 2 hours

Dan (Mon, 27 Aug 2018 15:06:21 GMT):
I tried the zoom link for the zmix meeting but it's complaining the meeting is for 3/6

Dan (Mon, 27 Aug 2018 15:14:58 GMT):
Maybe it's a ghost invite and there is no crypto-lib meeting this morning.

amundson (Mon, 27 Aug 2018 16:12:40 GMT):
@MALodder I'm concerned about backward compatibility since Sawtooth has the SDKs at 1.0.x and we have committed to not breaking the API. We have a little flexibility with the Rust SDK, but we don't want it to substantially deviate from our other language SDKs too much, and we have quite a bit of code now that uses the Rust SDK so it is "almost 1.0".

MALodder (Mon, 27 Aug 2018 16:38:29 GMT):
I believe this won't change it too much

MALodder (Mon, 27 Aug 2018 20:52:17 GMT):
pushed please look at the [PR #6](https://github.com/hyperledger-labs/crypto-lib/pull/6)

hartm (Mon, 27 Aug 2018 21:36:18 GMT):
@Dan The calendar invite (at least for me) is wrong for Zmix. It's at 7:00 AM pacific time--for some reason my (personal) calendar did not get updated and says 8:00 AM.

Dan (Mon, 27 Aug 2018 22:44:35 GMT):
oh, thanks I think I have the same relative skew despite being in a different timezone.

Dan (Mon, 27 Aug 2018 22:45:10 GMT):
so we're going to meet mondays at 7am pacific? and then every-other week on Wednesdays?

silasdavis (Tue, 28 Aug 2018 10:22:58 GMT):
Has joined the channel.

Dan (Tue, 28 Aug 2018 14:05:23 GMT):
@MALodder what was it you wanted to draw attention to in # 6?

MALodder (Tue, 28 Aug 2018 14:06:04 GMT):
The signature scheme interface

MALodder (Tue, 28 Aug 2018 14:08:18 GMT):
Is Sawtooth okay with it

MALodder (Tue, 28 Aug 2018 14:08:48 GMT):
I implemented the secp256k1 and ed25529 versions

MALodder (Tue, 28 Aug 2018 14:52:27 GMT):
@Dan Yes Monday's for now for ZMix, once it finalizes then I think we will reduce the frequency

amundson (Tue, 28 Aug 2018 18:06:36 GMT):
@MALodder how would I generate these amcl/ files?

MALodder (Tue, 28 Aug 2018 19:48:23 GMT):
In the repo https://github.com/milagro-crypto/amcl/tree/master/version3/rust there is a python script config64.py. If you run that and select the same curves and rsa as I did you will get the same folder

MALodder (Tue, 28 Aug 2018 19:48:44 GMT):
So I clone the project and run that file

amundson (Wed, 29 Aug 2018 00:47:44 GMT):
@MALodder cool. do you remember what you selected?

MALodder (Wed, 29 Aug 2018 00:49:55 GMT):
I selected secp256k1, nist256, secp384r1, secp521r1, bls12-381, BN-254, and all the RSA options

Dan (Wed, 29 Aug 2018 03:06:56 GMT):
@MALodder thanks for updating the interface to try to close/eliminate our backwards compatibility concern!! I will take a close look at it before our next meeting (hopefully well before).

MALodder (Wed, 29 Aug 2018 16:28:17 GMT):
@Dan Please let me know when you have reviewed it and your thoughts

silasdavis (Wed, 29 Aug 2018 17:18:41 GMT):
Hello all... just began lurking - will try and get along to meetings

silasdavis (Wed, 29 Aug 2018 17:23:32 GMT):
has there been any conversation about BLS signature schemes (https://en.wikipedia.org/wiki/Boneh%E2%80%93Lynn%E2%80%93Shacham) - they have some really useful properties for verifiable random functions and I would love to seem them in a solid library

hartm (Wed, 29 Aug 2018 17:24:44 GMT):
@silasdavis Yes, and we will have implementations in crypto-lib.

MALodder (Thu, 30 Aug 2018 04:56:38 GMT):
Yes Indy uses them and I’ve added them to the crypto lib library

lovesh (Thu, 30 Aug 2018 08:39:27 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=bqT2YWTRocTsYS4ri) @silasdavis Hyperledger Indy crypto has BLS signatures (and they have been added in shared crypto lib) that use the BN-254 curve. Some time ago i did a Rust implementation on BLS12-381 curve here https://github.com/lovesh/signature-schemes/tree/master/src/bls, it has 2 implementation, 1 which is a older, faster but vulnerable to certain attack implementation and the other is based on a new paper, it is not vulnerable to that attack but slower. Though the older implementation can be prevented from that attack and there is a fix (from the paper) there

lovesh (Thu, 30 Aug 2018 08:39:27 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=bqT2YWTRocTsYS4ri) @silasdavis Hyperledger Indy crypto has BLS signatures (and they have been added in shared crypto lib) that use the BN-254 curve. Some time ago i did a Rust implementation on BLS12-381 curve here https://github.com/lovesh/signature-schemes/tree/master/src/bls, it has 2 implementation, 1 which is a older, faster but vulnerable to certain attack and the other is based on a new paper, it is not vulnerable to that attack but slower. Though the older implementation can be prevented from that attack and there is a fix (from the paper) there. It can be used as Rust crate.

Dan (Fri, 31 Aug 2018 01:50:41 GMT):
@MALodder made some time to review today. It looks very close. I need to check whether we are using the existing (sawtooth) factory in a certain way, but even that might be irrelevant if its just wrapping this approach. And then I wasn't clear on how the secp256k1 context is managed. When we first adopted the bitcoin library we found that it didn't buy us nearly as much performance if we didn't hang onto the context and kept recreating it. I have some other rambling thoughts about when sawtooth would adopt this and whether that would buy us any more flexibility.. like if at a major release we could alter some things if that was valuable and also maybe a good point to pick up edwards so impact of the secp library weirdness less important .. so yeah rambling thoughts. :)

MALodder (Fri, 31 Aug 2018 01:52:21 GMT):
We manage the context with the Signaturescheme so it’s only created once

MALodder (Fri, 31 Aug 2018 02:11:11 GMT):
I did implement ed25519 to compare against secp256k1

Dan (Fri, 31 Aug 2018 14:09:12 GMT):
Yeah I saw that. Got me thinking about moving off of secp256k1 again. I don't have my data anymore but I did some lightweight benchmarking on those two last year and ed25519 was faster than secp - but not wildly faster. Given some other risks and sdk availability for other languages we decided not to make the switch back then.

Dan (Fri, 31 Aug 2018 14:09:12 GMT):
Yeah I saw that. Got me thinking about moving off of secp256k1 again. I don't have my data anymore but I did some lightweight benchmarking on those two last year and ed25519 was faster than secp. Given some other risks and sdk availability for other languages we decided not to make the switch back then.

MALodder (Fri, 31 Aug 2018 14:46:06 GMT):
My benchmarks for this rust code for secp256k1 for signing and verifying 200 signatures is 40ms

MALodder (Fri, 31 Aug 2018 14:46:20 GMT):
And ed25519 is 30ms

MALodder (Fri, 31 Aug 2018 14:46:53 GMT):
Signatures are the same size

RyanWest (Fri, 31 Aug 2018 15:12:54 GMT):
Has left the channel.

hartm (Mon, 03 Sep 2018 04:15:13 GMT):
Are we having the Z-mix meeting tomorrow morning? It seems like a lot of the US people might be off on labor day.

MALodder (Mon, 03 Sep 2018 13:53:06 GMT):
I’m not planning to attend due to the US holiday

iserikov (Mon, 03 Sep 2018 15:08:42 GMT):
So, as I see, I am celebrating US holiday in zoom chat alone)

Dan (Tue, 04 Sep 2018 21:17:11 GMT):
I hope it was fun :)

hartm (Tue, 04 Sep 2018 22:32:29 GMT):
@here Hi Everyone--just a reminder of tomorrow's meeting. I won't be able to make it, but Mike will be around to make sure things run smoothly. Thanks!

Maria (Wed, 05 Sep 2018 11:59:10 GMT):
Hi all, I am on vacation this week, so wont be able to dial in as well.

VipinB (Wed, 05 Sep 2018 13:03:20 GMT):
Is meeting hapening? If so, is it on the hyperledger community site?

VipinB (Wed, 05 Sep 2018 13:03:33 GMT):
zoom channel I mean

lovesh (Wed, 05 Sep 2018 14:07:33 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=rujw2ofHkgtwxguCX) @VipinB https://zoom.us/my/hyperledger.community

VipinB (Wed, 05 Sep 2018 14:23:08 GMT):
@lovesh thanks!

Dan (Fri, 07 Sep 2018 18:17:24 GMT):
Can someone recommend a good reference for range proofs?

hartm (Sun, 09 Sep 2018 08:28:54 GMT):
What application do you have in mind, and do you want something general or specific?

Dan (Mon, 10 Sep 2018 14:49:36 GMT):
I think this is one of the features for z-mix? So anything directly related to that would be good. Especially anything foundational. But in general it seems like checking in zero knowledge that a committed value is in range seems applicable all over blockchains. A trivial example .. we use a transaction family called intkey (integer key:value transactions) in a lot of our smoke tests. The main rule for those transactions is the resulting value has to be 0 <= n <= 2^32-1.

Dan (Mon, 10 Sep 2018 14:51:10 GMT):
Oh and is there a zmix meeting in ~10 min. I recall the invite had been off before and I don't remember if I locally corrected it or not.

Dan (Mon, 10 Sep 2018 14:51:10 GMT):
Oh and is there a zmix meeting in ~10 min? I recall the invite had been off before and I don't remember if I locally corrected it or not.

Dan (Mon, 10 Sep 2018 15:04:59 GMT):
Ok, so zoom error implies my time is still off an hr. :-/

rjones (Mon, 10 Sep 2018 15:53:30 GMT):
@Dan you just missed the meeting when you posted "zoom error"

rjones (Mon, 10 Sep 2018 15:53:30 GMT):
@Dan you just missed the meeting.

rjones (Mon, 10 Sep 2018 15:54:02 GMT):
but I am super interested in what the error was

Dan (Mon, 10 Sep 2018 16:26:37 GMT):
it said something like `this meeting is scheduled for 2018/3/6`

rjones (Mon, 10 Sep 2018 19:24:16 GMT):
you must have a super old invite or something

Dan (Mon, 10 Sep 2018 21:37:13 GMT):
it's ok I'm used to it. That's how I got invites to parties in high school.

MALodder (Tue, 11 Sep 2018 21:35:47 GMT):
@Dan RSA based range proofs have existed for awhile and Indy is using them for zero-knowledge proofs. There is some research into using elliptic curve based range proofs for bitcoin by [Dan Boneh et. al](https://crypto.stanford.edu/bulletproofs/)

MALodder (Tue, 11 Sep 2018 21:36:11 GMT):
Z-Mix will implement range proofs

MALodder (Tue, 11 Sep 2018 21:36:44 GMT):
more research needs to be done on elliptic curve based range proofs like cryptanalysis and time to bake but the initial results look good

Dan (Tue, 11 Sep 2018 21:37:48 GMT):
thanks @MALodder !

kelly_ (Wed, 12 Sep 2018 22:34:16 GMT):
@dan have you read this - https://people.xiph.org/~greg/confidential_values.txt

kelly_ (Wed, 12 Sep 2018 22:34:22 GMT):
@Dan rather

kelly_ (Wed, 12 Sep 2018 22:35:07 GMT):
this was published afterwards by bunz and boneh - https://eprint.iacr.org/2017/1066.pdf

kelly_ (Wed, 12 Sep 2018 22:35:45 GMT):
last but not least, this by Chain - https://blog.chain.com/faster-bulletproofs-with-ristretto-avx2-29450b4490cd

kelly_ (Wed, 12 Sep 2018 22:39:29 GMT):
oh looks like @MALodder link provided a couple of those

Dan (Thu, 13 Sep 2018 16:12:08 GMT):
no I haven't read any of that .. thanks .. I think ;)

kdenhartog (Thu, 13 Sep 2018 17:12:28 GMT):
Has joined the channel.

hartm (Thu, 13 Sep 2018 17:25:07 GMT):
Those aren't necessarily good introductions to the topic, but they will give you some background. I don't think there is a survey paper specifically on range proofs, so those may be your best bet.

hartm (Thu, 13 Sep 2018 17:25:44 GMT):
If you are learning, I'd focus on the elliptic curve stuff rather than the RSA based stuff though.

MALodder (Thu, 13 Sep 2018 21:21:20 GMT):
NOTICE: instead of the zklang meeting on Mondays at 8AM MDT, we will now be holding a Sovrin crypto call meeting. Expected attendees include Jason Law, Brent Zundel, Lovesh Harchandani from Evernym, [Dmitry Khovratovich](https://www.linkedin.com/in/khovratovich/), and me but its open to anyone else who would like to come. We will be discussing various crypto topics like ZKPs, crypto currency optimizations, ZKSnarks, Hyperledger Indy, and more. @rjones

MALodder (Thu, 13 Sep 2018 21:21:35 GMT):
if you could update the calendar to reflect this change that would be great

MALodder (Thu, 13 Sep 2018 21:21:42 GMT):
I will post the zoom id shortly

MALodder (Thu, 13 Sep 2018 21:25:10 GMT):
https://zoom.us/j/3441735212

MALodder (Thu, 13 Sep 2018 21:29:37 GMT):
sorry its this one https://zoom.us/j/567114224

MALodder (Thu, 13 Sep 2018 22:04:23 GMT):
Here is the [calendar](https://calendar.google.com/event?action=TEMPLATE&tmeid=b3ZlMjNyM2ZxMXRpYTdtYzdvbGIzMGFqYWtfMjAxODA5MTdUMTQwMDAwWiBtaWtlQHNvdnJpbi5vcmc&tmsrc=mike%40sovrin.org&scp=ALL) if that helps

Dan (Fri, 14 Sep 2018 14:04:47 GMT):
is that because the zmix stuff requires less discussion now or because the newer meeting is just higher priority?

hartm (Fri, 14 Sep 2018 17:06:42 GMT):
By the way, I've updated the proposal document.

hartm (Fri, 14 Sep 2018 17:06:46 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

hartm (Fri, 14 Sep 2018 17:06:56 GMT):
Let me know what you think, and if you want an editable link, let me know. Thanks!

rjones (Fri, 14 Sep 2018 21:25:59 GMT):
@tkuhrt could I ask you to update the calendar per @MALodder since I'm not here until Wednesday?

MALodder (Fri, 14 Sep 2018 22:01:53 GMT):
Zmix stuff will be merged with the crypto lib meeting because there isn’t a lot more to add by having a separate meeting

MALodder (Fri, 14 Sep 2018 22:02:25 GMT):
@hartm after this doc is reviewed would it be ready for the TSC to vote?

wip-abramson (Mon, 17 Sep 2018 08:15:41 GMT):
Has joined the channel.

hartm (Wed, 19 Sep 2018 01:46:48 GMT):
@here Just a reminder we have a meeting tomorrow. I sent out the agenda to the labs email list. Thanks everyone!

luckydogchina (Wed, 19 Sep 2018 02:14:16 GMT):
Has joined the channel.

Ryan2 (Wed, 19 Sep 2018 02:34:48 GMT):
Has joined the channel.

binhn (Wed, 19 Sep 2018 14:43:51 GMT):
links Maria posted in the meeting chat From Maria Dubovitskaya to Everyone: (10:36 AM)  https://docs.google.com/document/d/1yodOwQw3ErYMmHSfLn7RyI_h84S7k3AINIXnaSNgUn8/edit https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit  https://docs.google.com/document/d/1CLdkd70Mfa-AhnrqwTMVwBdF-HdvVNBiOKcq13lPstY/edit ZKlang spec  https://docs.google.com/document/d/1HQ7c2PpwGXIxZZyPVoQDzi0rQjA_pk6Kc6bAWf7J8NM/edit?ouid=116858714271757981044&usp=docs_home&ths=true

dhuseby (Wed, 19 Sep 2018 15:07:58 GMT):
From lovesh: Hello. Didn't get a chance on call but as part of hackfest, would we like to have basic Rust wrapper for libsnark in crypto-lib? I can contribute

dhuseby (Wed, 19 Sep 2018 15:08:10 GMT):
@lovesh ^^^

DavorKljajic (Thu, 20 Sep 2018 12:36:55 GMT):
davor

PrakharShukla (Mon, 24 Sep 2018 19:19:48 GMT):
Has joined the channel.

Dan (Tue, 25 Sep 2018 13:13:48 GMT):
I tried to join what I thought was the zmix/indy-crypto call on monday at 7am PT but there was only one chap on (who didn't seem to be listening... possibly he just wanted to ignore my poor russian.) :rocket: was down so there was no-one to ping here. Looking at the HL Community calendar I only see an indy maintainers meeting on Mondays at 8am PT. @MALodder can you clarify the schedule and then maybe @dhuseby can add it to the community calendar (assuming I'm not just looking past it).

hartm (Tue, 25 Sep 2018 18:02:40 GMT):
@Dan I guess they used a different zoom than the Hyperledger community channel. I was in the meeting--there were a bunch of people.

Dan (Tue, 25 Sep 2018 18:04:22 GMT):
hmmm I must still have a bad invite then. My one-sided conversation in broken russian wasn't too interesting. well, I mean it was interesting to 100% of the participants but .. Could we get that on the regular community calendar with a hyperledger-friendly zoom link? @dhuseby

dhuseby (Tue, 25 Sep 2018 18:46:41 GMT):
@Dan let me see what I can do

Dan (Tue, 25 Sep 2018 19:02:52 GMT):
I believe in you!

dhuseby (Tue, 25 Sep 2018 20:54:19 GMT):
@Dan I can't add things to the Hyperledger Community Events calendar

dhuseby (Tue, 25 Sep 2018 20:54:37 GMT):
You should ping Tracy and Ry

dhuseby (Tue, 25 Sep 2018 20:54:42 GMT):
that's what I'd be doing if I handled it

Dan (Wed, 26 Sep 2018 13:09:08 GMT):
Oh sorry, thought you all had the same keys. I still believe in you though. ;)

Dan (Wed, 26 Sep 2018 13:10:10 GMT):
@MALodder can you coordinate your desired timeslot with @rjones and he can get you on the `official` calendar with an `official` _zoom_ link?

peter.li (Thu, 27 Sep 2018 01:59:03 GMT):
Has joined the channel.

nnsgmsone (Thu, 27 Sep 2018 02:08:36 GMT):
Has joined the channel.

nnsgmsone (Thu, 27 Sep 2018 02:09:20 GMT):
hello

guolidong (Thu, 27 Sep 2018 02:16:38 GMT):
Has joined the channel.

Dan (Thu, 27 Sep 2018 02:57:33 GMT):
aloha

nnsgmsone (Thu, 27 Sep 2018 03:08:46 GMT):
Do you think gmsm meets the requirements for adding to fabric?

Dan (Thu, 27 Sep 2018 04:44:48 GMT):
maybe try over in the #fabric channel

AltifBrown (Tue, 02 Oct 2018 21:34:25 GMT):
Has joined the channel.

hartm (Wed, 03 Oct 2018 00:38:50 GMT):
@here Hi everyone! I'm going to cancel tomorrow's meeting due to the hackfest--I think many of our regular participants will be here in Montreal. I'm hoping to come out of this with a proposal document that we can finally submit to the TSC.

AltifBrown (Wed, 03 Oct 2018 00:45:44 GMT):
:ok_hand:

szewong (Wed, 03 Oct 2018 15:42:22 GMT):
Has joined the channel.

cloud1230 (Wed, 03 Oct 2018 15:42:24 GMT):
Has joined the channel.

hartm (Wed, 03 Oct 2018 15:43:05 GMT):
https://github.com/hyperledger-labs/z-mix

hartm (Wed, 03 Oct 2018 15:43:41 GMT):
https://github.com/hyperledger-labs/crypto-lib

dhuseby (Wed, 03 Oct 2018 15:43:45 GMT):
welcome

GmoneyCoder (Wed, 03 Oct 2018 15:52:48 GMT):
Has joined the channel.

jsmitchell (Wed, 03 Oct 2018 15:59:00 GMT):
`cargo build` succeeded for me on macos mojave with a `xcode-select --install` to fix some git issues and a `brew install libsodium`

jsmitchell (Wed, 03 Oct 2018 15:59:19 GMT):
`cargo test` fails with:

jsmitchell (Wed, 03 Oct 2018 15:59:22 GMT):
``` Compiling rustlibsecp256k1 v0.1.0 (file:///Users/mitchell/work/bitwiseio/crypto-lib/rustlibsecp256k1) Compiling crypto_lib v0.1.0 (file:///Users/mitchell/work/bitwiseio/crypto-lib/libhl-crypto) error[E0463]: can't find crate for `rcrypto` --> src/lib.rs:21:1 | 21 | extern crate crypto as rcrypto; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate error: aborting due to previous error ```

szewong (Wed, 03 Oct 2018 18:07:56 GMT):
I did xcode-select --install and cargo build is still failing on libsodium.

jsmitchell (Wed, 03 Oct 2018 18:08:22 GMT):
`brew install libsodium`

szewong (Wed, 03 Oct 2018 18:08:31 GMT):
Did that too

jsmitchell (Wed, 03 Oct 2018 18:08:43 GMT):
try a `cargo clean; cargo build`

jsmitchell (Wed, 03 Oct 2018 18:09:31 GMT):
some folks in the room at the hackfest were saying they were having issues with `brew install libsodium` as well cc @dhuseby

szewong (Wed, 03 Oct 2018 18:09:58 GMT):
I am one of those. ;)

szewong (Wed, 03 Oct 2018 18:11:33 GMT):
Still failing on libsodium.

szewong (Thu, 04 Oct 2018 04:03:59 GMT):
Yeah. `cargo build` and `cargo test` both passed!

snowy13 (Thu, 04 Oct 2018 12:31:19 GMT):
Has joined the channel.

greg2git (Thu, 04 Oct 2018 13:26:53 GMT):
Has joined the channel.

hartm (Thu, 04 Oct 2018 13:26:54 GMT):
https://crypto.stanford.edu/~dabo/papers/broadcast.pdf

hartm (Thu, 04 Oct 2018 13:27:10 GMT):
Broadcast encryption with \sqrt(n) ciphertexts

hartm (Thu, 04 Oct 2018 13:32:53 GMT):
Private broadcast encryption: https://crypto.stanford.edu/portia/papers/bb-bcc.pdf

MALodder (Thu, 04 Oct 2018 13:34:53 GMT):
https://cwtch.im/

jsmitchell (Thu, 04 Oct 2018 14:16:40 GMT):
https://github.com/hyperledger/sawtooth-core/blob/master/sdk/rust/src/signing/secp256k1.rs

jsmitchell (Thu, 04 Oct 2018 14:16:51 GMT):
https://github.com/hyperledger-labs/crypto-lib/blob/master/libhl-crypto/src/signatures/secp256k1.rs

jsmitchell (Thu, 04 Oct 2018 14:17:30 GMT):
https://github.com/hyperledger-labs/crypto-lib/blob/master/libhl-crypto/src/signatures/secp256k1.rs#L417

jsmitchell (Thu, 04 Oct 2018 14:17:35 GMT):
sign test ^

kdenhartog (Thu, 04 Oct 2018 16:24:24 GMT):
Thanks @hartm for posting those broadcast encryption schemes

amundson (Thu, 04 Oct 2018 17:58:10 GMT):
In a discussion at the hackfest, it was proposed to change the name. One proposal that seemed generally liked was 'Ursa' with a bear logo.

kelly_ (Thu, 04 Oct 2018 19:53:33 GMT):
https://aumasson.jp/data/talks/balccon18.pdf

kelly_ (Thu, 04 Oct 2018 19:53:48 GMT):
^ @hartm @Dan you guys may find that interesting. list of crypto bugs in blockchains

Dan (Fri, 05 Oct 2018 13:33:45 GMT):
Nice.. "Don’t use any open-source utility in production!"

VipinB (Fri, 05 Oct 2018 14:57:22 GMT):
Should be called Blockchain Insecurity?

jlin (Fri, 05 Oct 2018 15:08:41 GMT):
Has joined the channel.

dhuseby (Mon, 08 Oct 2018 14:43:16 GMT):
@MALodder @jsmitchell people are still having trouble getting libsodium installed on their mac's to try the cryptolib

dhuseby (Mon, 08 Oct 2018 14:48:44 GMT):
@jsmitchell there is a solution that @MALodder figured out to get libsodium installed on a mac

jsmitchell (Mon, 08 Oct 2018 14:53:53 GMT):
It worked for me first time with `brew install`. If there are alternate instructions for those running into trouble, it would be good to drop them here

MALodder (Mon, 08 Oct 2018 15:01:02 GMT):
I put instructions in the README.md for both methods

MALodder (Mon, 08 Oct 2018 15:01:17 GMT):
@dhuseby ^^

dhuseby (Mon, 08 Oct 2018 15:09:07 GMT):
great! thanks

kdenhartog (Mon, 08 Oct 2018 16:48:03 GMT):
@MALodder I think you meant to link a different link. That readme file goes to kitchenware

MALodder (Mon, 08 Oct 2018 17:35:55 GMT):
@kdenhartog this link https://github.com/hyperledger-labs/crypto-lib/blob/master/README.md

hartm (Mon, 08 Oct 2018 18:27:21 GMT):
The links to the API Documentation seem to be broken in that document.

MALodder (Tue, 09 Oct 2018 17:37:51 GMT):
okay I

MALodder (Tue, 09 Oct 2018 17:37:51 GMT):
okay I'll fix it

raccoonrat (Wed, 10 Oct 2018 02:50:30 GMT):
Has joined the channel.

hartm (Wed, 10 Oct 2018 15:45:07 GMT):
Thanks Mike!

tobowers (Fri, 12 Oct 2018 09:21:42 GMT):
broken in the README too

MALodder (Fri, 12 Oct 2018 21:22:24 GMT):
@towbowers that’s what hart is referring to

wip-abramson (Mon, 15 Oct 2018 11:07:20 GMT):
Hi, is the zk lang call on today? I have started to get my head around Rust and am hoping to get more involved with the crypto stuff. Thanks

hartm (Mon, 15 Oct 2018 14:06:41 GMT):
Is there a call this morning? I don't see anyone on the zoom meetings.

hartm (Mon, 15 Oct 2018 14:22:36 GMT):
For the record, the meeting link is: https://www.zoom.us/j/567114224

hartm (Mon, 15 Oct 2018 14:43:21 GMT):
http://www.scs.stanford.edu/~dm/home/papers/corrigan-gibbs:riposte.pdf

MALodder (Mon, 15 Oct 2018 15:25:42 GMT):
@wip-abramson Sorry I didn't see this until now. Yes @hartm put the correct link

MALodder (Mon, 15 Oct 2018 15:26:20 GMT):
@wip-abramson let me know how you would like to help and I'll try to point you in the right direction

wip-abramson (Tue, 16 Oct 2018 10:59:31 GMT):
Well currently I am just getting up to speed with both Rust and the Crypto. But I want to get involved with development, I will work on setting up my environment and let you know if I run into any issues

wip-abramson (Tue, 16 Oct 2018 11:00:08 GMT):
The zklang call is no longer in the calendar, what time is it usually at on Mondays?

Dan (Tue, 16 Oct 2018 12:57:09 GMT):
[ ](https://chat.hyperledger.org/channel/crypto-lib?msg=uPTZsPp2drEBmAWAw)

Dan (Tue, 16 Oct 2018 12:59:08 GMT):
That probably flew by. If you get a chance to coordinate with Ry that would be good. Even better though might be seeing how well we can do over email or chat without meetings.

rjones (Tue, 16 Oct 2018 16:05:54 GMT):
@MALodder shoot me an email with the details rjones@linuxfoundation.org

MALodder (Tue, 16 Oct 2018 17:09:01 GMT):
There is no longer a zklang call. We now do a Sovrin crypto meeting at the same time. https://zoom.us/j/3441735212

MALodder (Tue, 16 Oct 2018 17:10:22 GMT):
sorry wrong zoom number, the correct one is: https://zoom.us/j/567-114-224

MALodder (Tue, 16 Oct 2018 17:12:56 GMT):
Here is the agenda https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit?usp=sharing

rjones (Tue, 16 Oct 2018 18:13:05 GMT):
@MALodder I don't see a zklang call. what time is your call? what time zone? how often does it repeat?

Dan (Tue, 16 Oct 2018 18:24:53 GMT):
If it's a sovrin thing maybe that's out of scope for us. We could consider like a monthly call specifically for crypto-lib and really focus on trying to communicate asynch the rest of that time. See how that goes and if it isn't working then shoot for something higher frequency?

rjones (Tue, 16 Oct 2018 18:27:14 GMT):
@hartm does run an every-two-weeks crypto-lib call

MALodder (Tue, 16 Oct 2018 20:13:12 GMT):
It’s a Sovrin thing but it is open to anyone. It runs every week at 8am MDT

hartm (Wed, 17 Oct 2018 01:39:30 GMT):
@here Just a reminder of tomorrow's meeting at 7:00 AM Pacific time (the usual time). Hope to talk to many of you tomorrow!

hartm (Wed, 17 Oct 2018 01:39:50 GMT):
I sent out an agenda to the labs list as well.

wip-abramson (Wed, 17 Oct 2018 13:02:43 GMT):
What is the link for the crypto-lib meeting? I would like to join

rjones (Wed, 17 Oct 2018 13:38:44 GMT):
@wip-abramson check out the community calendar

rjones (Wed, 17 Oct 2018 13:40:36 GMT):
@wip-abramson Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community it starts in ~19 minutes

wip-abramson (Wed, 17 Oct 2018 13:50:02 GMT):
Ah thanks, I thought it was at 40 minutes ago

Dan (Wed, 17 Oct 2018 14:22:03 GMT):
pr comments https://github.com/hyperledger-labs/crypto-lib/pull/9

Dan (Wed, 17 Oct 2018 14:38:44 GMT):
https://docs.google.com/document/d/1yodOwQw3ErYMmHSfLn7RyI_h84S7k3AINIXnaSNgUn8/edit# regarding threshold choices

Dan (Wed, 17 Oct 2018 14:42:22 GMT):
BLS for aggregation BBS for proof of sig Poincheval for proof of aggregated sig CL for proof of knowledge but over rsa.

Dan (Wed, 17 Oct 2018 14:43:19 GMT):
https://docs.google.com/document/d/1HQ7c2PpwGXIxZZyPVoQDzi0rQjA_pk6Kc6bAWf7J8NM/edit

Dan (Wed, 17 Oct 2018 14:44:43 GMT):
the above items moved to github issues

Dan (Wed, 17 Oct 2018 14:45:24 GMT):
https://github.com/hyperledger-labs/z-mix/issues

hartm (Wed, 17 Oct 2018 14:47:46 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

hartm (Wed, 17 Oct 2018 14:47:50 GMT):
Minutes document above.

hartm (Wed, 17 Oct 2018 14:52:47 GMT):
https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

MALodder (Wed, 17 Oct 2018 14:56:14 GMT):
There is a CL sig that is ECC based but not as efficient as BBS+

MALodder (Wed, 17 Oct 2018 14:56:40 GMT):
correct me if I'm wrong

manu (Wed, 17 Oct 2018 14:57:07 GMT):
the name CL sig is a bit vague, as you could also call BBS+ a CL sig, so above I'd just say CL-RSA and then its clear

Dan (Wed, 17 Oct 2018 14:57:36 GMT):
EPID uses BN .. i guess it's a derivative of CL.

manu (Wed, 17 Oct 2018 14:58:13 GMT):
epid uses somewhat broken version of BBS+

manu (Wed, 17 Oct 2018 14:58:13 GMT):
epid uses a somewhat broken version of BBS+

hartm (Wed, 17 Oct 2018 14:58:22 GMT):
Did I immediately just go to thesaurus.com after the meeting ended? Yes, yes I did.

MALodder (Wed, 17 Oct 2018 14:59:13 GMT):
haha

Dan (Wed, 17 Oct 2018 14:59:49 GMT):
oh interesting @manu .. what aspect is broken?

manu (Wed, 17 Oct 2018 15:08:39 GMT):
See https://eprint.iacr.org/2016/663.pdf section 2.2. In short, what EPID uses is a shortened BBS+ sig where one element is dropped which was introduced with an invalid security proof

manu (Wed, 17 Oct 2018 15:08:39 GMT):
@Dan See https://eprint.iacr.org/2016/663.pdf section 2.2. In short, what EPID uses is a shortened BBS+ sig where one element is dropped which was introduced with an invalid security proof

Dan (Wed, 17 Oct 2018 15:10:02 GMT):
thanks!

MALodder (Wed, 17 Oct 2018 19:50:46 GMT):
Did dropping the element make it slightly broken?

MALodder (Wed, 17 Oct 2018 19:51:27 GMT):
And they said it was okay with a security proof that actually doesn’t work?

MALodder (Wed, 17 Oct 2018 19:53:05 GMT):
That’s what I gather from your comments and the paper

manu (Thu, 18 Oct 2018 13:52:34 GMT):
Right, they removed a part of the signature and presented that with a security proof that is incorrect. So there is no reason to believe that the EPID signature is unforgeable, but I also don't immediately know how to forge them.

hartm (Thu, 18 Oct 2018 18:25:11 GMT):
Just sent out the proposal to the TSC list. Hopefully we will get some good feedback.

Dan (Thu, 18 Oct 2018 18:25:57 GMT):
I'm going to immediately claim it's out of scope ;)

Dan (Thu, 18 Oct 2018 18:53:25 GMT):
If this image was ccby we'd have a logo: http://www.naturallynorthidaho.com/wp-content/uploads/2013/11/Nocturnal-animals-21.jpg From (http://www.naturallynorthidaho.com/2013/11/nocturnal-animals-specially-adapted-to.htm)

hartm (Thu, 18 Oct 2018 20:13:50 GMT):
Nice!

jsmitchell (Thu, 18 Oct 2018 20:22:59 GMT):
yep, add some glowing bear teeth to make it obvious what it is

jsmitchell (Thu, 18 Oct 2018 20:25:41 GMT):
the nightmares I've had since you told me that tale have involved glowing teeth, anyway

kh.nguyen (Fri, 19 Oct 2018 00:18:20 GMT):
Has joined the channel.

MALodder (Fri, 19 Oct 2018 03:22:35 GMT):
Teeth and claws

MALodder (Fri, 19 Oct 2018 21:42:02 GMT):
FYI there will be no Sovrin Crypto call the Monday as I will be out of town and half of those who normally attend will be in other conferences.

MALodder (Fri, 19 Oct 2018 21:42:30 GMT):
It will resume the following week on Oct 29th

hartm (Fri, 19 Oct 2018 22:10:07 GMT):
Thanks for letting us know!

Dan (Tue, 23 Oct 2018 18:42:19 GMT):
I was trying to review @MALodder 's PR and got sidetracked into the bowels of Milagro. Can someone remind me what our goal with that codebase is? Is it solely to provide a 0 dependency build option? And looking at the milagro project itself I'm trying to discern the structure.. There's an amcl repo that seems to have all the languages and then there's a few peer level repos that are language specific. I'm guessing they are generated from the amcl repo and then have ... other stuff?

hartm (Tue, 23 Oct 2018 19:31:49 GMT):
@Dan I assume you are talking about https://github.com/hyperledger-labs/crypto-lib/pull/13? The goal is to modularize out the hash functions (and, in general, the symmetric key cryptography) since we have some potential users who have region-specific requirements for these.

hartm (Tue, 23 Oct 2018 19:32:47 GMT):
Mike is taking his kids to Disney World this week so I'd suggest we can talk about this more next week (including at the crypto-lib meeting).

Dan (Tue, 23 Oct 2018 20:47:06 GMT):
Well that's the PR I started at but it had a milagro patch in it, which led me back to why we have milagro in there to begin with. So that's really more my question. Is milagro there purely for a no-dependency build? I think that's the reason but I want to make sure. Following from that I'm trying to assess the relative risk of the milagro project. I started poking around in there but wouldn't mind a map from someone who's been there before - especially around the repo structure I mention above.

Dan (Tue, 23 Oct 2018 20:48:50 GMT):
Also I would like some Tonga Toast :bread: so I can go into a carb coma.

hartm (Wed, 24 Oct 2018 00:08:39 GMT):
We need Milagro in order to build things for which there aren't standard libraries (i.e. threshold signatures). It is also useful for no-dependency builds, but I think the primary reason is building functionalities for which there aren't implementations we can shim.

hartm (Wed, 24 Oct 2018 00:08:52 GMT):
If you're ever in the bay area, I can point you to a place with great french toast!

amundson (Wed, 24 Oct 2018 14:58:00 GMT):
@MALodder @hartm @Dan FYI - some work being done on the sawtooth java sdk signing library currently to bring it to the same level as the rust/python sdks - https://github.com/hyperledger/sawtooth-sdk-java/pull/5

amundson (Wed, 24 Oct 2018 15:03:14 GMT):
re:milagro, I think we should move to a model were we don't check in generated code, but rather generate it as part of the project's build. otherwise, doing the code generation becomes a specialized non-repeatable task (except by specific people obviously)

amundson (Wed, 24 Oct 2018 15:05:08 GMT):
@MALodder did you previously mention some existing java JNA signing example code to look at?

boydjohnson (Thu, 25 Oct 2018 17:42:05 GMT):
Has joined the channel.

Dan (Mon, 29 Oct 2018 14:03:41 GMT):
Is there a sovrin crypto call now?

brentzundel (Mon, 29 Oct 2018 14:07:51 GMT):
yes https://zoom.us/j/567114224

Dan (Mon, 29 Oct 2018 14:11:23 GMT):
thx

Dan (Mon, 29 Oct 2018 14:25:16 GMT):
are you working from an agenda posted somewhere?

hartm (Mon, 29 Oct 2018 14:26:28 GMT):
Yes:

hartm (Mon, 29 Oct 2018 14:26:31 GMT):
https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit?usp=sharing

Dan (Mon, 29 Oct 2018 14:26:36 GMT):
gracias

wip-abramson (Mon, 29 Oct 2018 20:30:09 GMT):
Hi, can anyone recommend a good attribute based encryption library in Rust? thanks

wip-abramson (Mon, 29 Oct 2018 20:33:05 GMT):
is this crypto-lib going to be one actually?

hartm (Mon, 29 Oct 2018 20:59:30 GMT):
@wip-abramson What kind of attribute-based encryption do you need? I don't know of any existing libraries.

wip-abramson (Tue, 30 Oct 2018 12:15:14 GMT):
I am just looking to play around with it, my professor mentioned it. I looked at charm crypto but it doesnt seem to work and would prefer something in Rust. Just wanting to try something like this https://jhuisi.github.io/charm/charm/schemes/abenc/abenc_bsw07.html. I am still pretty new to all this so just trying to figure things out.

wip-abramson (Tue, 30 Oct 2018 12:15:24 GMT):
https://github.com/Fraunhofer-AISEC/rabe this could be okay

wip-abramson (Tue, 30 Oct 2018 12:21:27 GMT):
In terms of using or working with the crypto-lib as a dependency are there any examples of this? How would it be used? I would love to understand the code base better, is there a best way for me to do this? Struggling to get my head round it

Dan (Tue, 30 Oct 2018 13:05:06 GMT):
crypto-lib is still in it's infancy.. or maybe gestation. :baby_symbol: the code organization is still in flux.

Dan (Tue, 30 Oct 2018 13:08:07 GMT):
If you want to see mature code organization maybe checkout openssl. I found libsnarks a little difficult to navigate but that's another project you might look at. More crypto novelty but the code organization is atypical - at least to me. Of course neither of those are rusty.

wip-abramson (Tue, 30 Oct 2018 14:46:13 GMT):
Okay, thanks Dan I will look into them. I am working towards understanding the cryptography used in hyperledger indy and more generally in identity systems so I figured the crypto-lib would be a good place to get involved. Ill keep working at it, still got a lot to learn with cryptography first

Dan (Tue, 30 Oct 2018 14:55:22 GMT):
Ok, some of my suggestions might be tangents then. It's useful to see how other libraries are organized but maybe not central to your objective.

ryanwest6 (Tue, 30 Oct 2018 23:40:52 GMT):
Has left the channel.

hartm (Wed, 31 Oct 2018 01:55:33 GMT):
@here Just a reminder of tomorrow's meeting (at the usual time). I've sent out the agenda to the labs list. Thanks, and hope to talk to many of you tomorrow!

MALodder (Wed, 31 Oct 2018 13:55:18 GMT):
@hartm can you post the link to the agenda?

hartm (Wed, 31 Oct 2018 13:56:18 GMT):
From the email:

hartm (Wed, 31 Oct 2018 13:56:22 GMT):
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?

hartm (Wed, 31 Oct 2018 13:58:06 GMT):
Proposal document: https://docs.google.com/document/d/1JtFT5L-82egj6shgGXzTsNAg6_UHuMheKfsst6NS_Xo/edit?usp=sharing

hartm (Wed, 31 Oct 2018 13:58:31 GMT):
Meeting Notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

anr09 (Wed, 31 Oct 2018 14:14:06 GMT):
Has joined the channel.

Dan (Wed, 31 Oct 2018 14:19:24 GMT):
motivating pull request: https://github.com/hyperledger-labs/crypto-lib/pull/13

Dan (Wed, 31 Oct 2018 14:58:51 GMT):
#SharedCrypto

Dan (Wed, 31 Oct 2018 14:59:39 GMT):
https://lists.hyperledger.org/g/labs/topic/sharedcrypto_3rd_party/27631934?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27631934

MALodder (Wed, 31 Oct 2018 15:01:52 GMT):
thanks dan

MALodder (Wed, 31 Oct 2018 15:15:09 GMT):
@Dan When sending an email do I send it to labs@lists.hyperledger.org with #SharedCrypto in the subject line?

Dan (Wed, 31 Oct 2018 15:16:22 GMT):
yep

MALodder (Wed, 31 Oct 2018 15:19:04 GMT):
just sent one and it appears to work

dhuseby (Wed, 31 Oct 2018 15:37:12 GMT):
@hartm link to the config/attributes/tier document?

hartm (Wed, 31 Oct 2018 15:52:55 GMT):
@dhuseby Here is a link with what we have in the proposal:

hartm (Wed, 31 Oct 2018 15:52:58 GMT):
https://docs.google.com/document/d/1zubstmrVvVUKikni3U750QcFPJ8QBVnoJJ06zimRduA/edit?usp=sharing

hartm (Wed, 31 Oct 2018 15:53:07 GMT):
Please feel free to edit that as you all see fit.

dhuseby (Wed, 31 Oct 2018 17:42:29 GMT):
To put a finer point on what I was proposing earlier for the config/attribute system is this:

dhuseby (Wed, 31 Oct 2018 17:43:40 GMT):
1) we define a set of standard "attributes" like: designed in the open, experimental, government approved, etc

dhuseby (Wed, 31 Oct 2018 17:44:38 GMT):
2) every library under the ursa banner has an attributed that is the same as it's name (e.g. the "sodium" attribute selects for libsodium)

dhuseby (Wed, 31 Oct 2018 17:46:06 GMT):
3) we define pre-determined, common configurations that are combinations of attributes of the #2 type (e.g. open_strong == blake2 + sodium)

dhuseby (Wed, 31 Oct 2018 17:47:08 GMT):
The way I envision it being used by a consumer is to say: open_strong - blake2 + sha3 + zksnarks

dhuseby (Wed, 31 Oct 2018 17:47:56 GMT):
or: fips_compliant + zksnarks

dhuseby (Wed, 31 Oct 2018 17:49:13 GMT):
The attributes described as #1 are just lists of libraries under the ursa banner that have that attribute

dhuseby (Wed, 31 Oct 2018 17:50:04 GMT):
so I could define my config as "government_approved" and I would get all of the NIST and Chinese govt approved primitives

hartm (Wed, 31 Oct 2018 17:54:07 GMT):
@dhuseby Can you add this to the document I linked just before?

dhuseby (Wed, 31 Oct 2018 20:30:14 GMT):
yessir

dhuseby (Wed, 31 Oct 2018 20:48:25 GMT):
@hartm done

adamgering (Thu, 01 Nov 2018 14:43:29 GMT):
Has joined the channel.

hartm (Thu, 01 Nov 2018 14:56:23 GMT):
@here We just got the project approved for incubation by the TSC. Thanks everyone for all of the work you've done on this! It's been an effort by a quite large group of people, so thank you all.

MicBowman (Thu, 01 Nov 2018 14:56:38 GMT):
congratulations, all!!!

MALodder (Thu, 01 Nov 2018 15:02:58 GMT):
:cartwheel_tone2:

Dan (Thu, 01 Nov 2018 15:03:10 GMT):
You cannot fight the :bear: !

Dan (Thu, 01 Nov 2018 15:04:54 GMT):
@tkuhrt the desired repos will be something like ursa-lib and ursa-rfcs. the latter is for capturing design and decisions .. very much like sawtooth-rfcs repo.

rjones (Thu, 01 Nov 2018 15:23:00 GMT):
@Dan I assume you'll be creating these in Gerrit? Good choice

dhuseby (Thu, 01 Nov 2018 15:33:35 GMT):
woohoo!!

MALodder (Thu, 01 Nov 2018 16:33:07 GMT):
Let me know when the project repos have been created and crypto-lib has been moved

Dan (Thu, 01 Nov 2018 16:38:15 GMT):
@rjones I don't dislike anyone here enough to force gerrit on them. :D

hartm (Thu, 01 Nov 2018 17:22:21 GMT):
By the way, I also emailed the marketing folks about checking out the name Ursa. Hopefully that will go through.

Dan (Thu, 01 Nov 2018 17:47:14 GMT):
Marketing cannot fight the :bear:

rjones (Thu, 01 Nov 2018 18:10:58 GMT):
@Dan be careful or I'll lowercase your username

jsmitchell (Thu, 01 Nov 2018 18:33:32 GMT):
@Dan you cannot have hamburgers or candy canes until you do your homework

rjones (Thu, 01 Nov 2018 18:36:29 GMT):
if I had known that was at stake I would have worked harder in school

Dan (Thu, 01 Nov 2018 19:46:58 GMT):
but @jsmitchell I have no homework

amundson (Thu, 01 Nov 2018 19:49:07 GMT):
I think @rjones should definitely lower-case @Dan

jsmitchell (Thu, 01 Nov 2018 19:49:28 GMT):
@Dan THEN YOU MUST FIGHT THE :bear: !

MALodder (Thu, 01 Nov 2018 20:48:24 GMT):
Proof that even **formally verified** code still has issues. https://github.com/Inria-Prosecco/proscript-messaging/issues/1 The funny part is they closed the issue and reopened it. Probably for public relations

Johnjam (Fri, 02 Nov 2018 09:00:33 GMT):
Has joined the channel.

hartm (Fri, 02 Nov 2018 18:23:39 GMT):
That's pretty funny. I have to agree that "side channels being out of scope" doesn't mean "choose the implementation that makes side channel attacks trivial." We will have to have an in-depth discussion about similar issues at some point...

Dan (Mon, 05 Nov 2018 15:03:28 GMT):
is there a sovrin crypto meeting this morning? I'm on https://zoom.us/j/567114224 but I'm all alone ... and afraid of bears.

Dan (Mon, 05 Nov 2018 15:07:44 GMT):
... and daylight savings time changes.

hartm (Mon, 05 Nov 2018 15:10:16 GMT):
Yes, there is.

hartm (Mon, 05 Nov 2018 15:10:20 GMT):
You are invited to a Zoom meeting now. Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/567114224 Or iPhone one-tap: US: +16465588656,,567114224# or +16699006833,,567114224# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 567 114 224 International numbers available: https://zoom.us/u/cFq6UzUSw

hartm (Mon, 05 Nov 2018 15:11:04 GMT):
You sure you clicked on the right meeting link?

Dan (Mon, 05 Nov 2018 15:25:56 GMT):
weird .. thanks

adamgering (Mon, 05 Nov 2018 19:41:46 GMT):
is this library ready to used in the context of development in python, signing using Secp256k1?

adamgering (Mon, 05 Nov 2018 19:42:26 GMT):
is there (or going to be) an installer via pip?

MALodder (Mon, 05 Nov 2018 20:43:59 GMT):
@adamgering once the project has an official incubation project, I can imagine it will in the future. The first thing we need to do is get a CI/CD pipeline being built for Rust. Next would be the wrappers like python

MALodder (Mon, 05 Nov 2018 20:44:32 GMT):
I believe we are just waiting on legal review then we should be good to go to be in incubation

hartm (Mon, 05 Nov 2018 21:29:50 GMT):
@MALodder @adamgering We have been approved for incubation (happened at the meeting last Thursday). We are just waiting on final approval from legal for the name (which we need for repo creation).

Dan (Tue, 06 Nov 2018 03:18:48 GMT):
@adamgering I think for the near term, you are fine to rely on the sawtooth python signing package. The API's align closely. What we have in crypto-lib || ursa now is only a rust interface. My intent is that Ursa will replace all the sawtooth signing libraries. That probably won't happen for a quarter or so though. I'm not sure exactly the timeline but we want to get Ursa stable and then tested with Sawtooth before we make big changes.

PadmavathyMohan (Thu, 08 Nov 2018 07:17:57 GMT):
Has joined the channel.

tkuhrt (Thu, 08 Nov 2018 18:09:52 GMT):
Hey, all. I am going to rename this chat channel to ursa to match the project name. I just wanted to give everyone a heads up that I will be doing that this afternoon.

greg2git (Thu, 08 Nov 2018 18:35:53 GMT):
very bearish, thx for the update

Dan (Thu, 08 Nov 2018 19:22:02 GMT):
that was barely enough notice _(buckle in... i'm going to use that same pun repeatedly for the next 5 years)_

Dan (Thu, 08 Nov 2018 19:22:02 GMT):
that was barely enough notice (buckle in... i'm going to use that same pun repeatedly for the next 5 years)

hartm (Thu, 08 Nov 2018 20:01:58 GMT):
Thanks Tracy!

hartm (Thu, 08 Nov 2018 20:02:53 GMT):
Going to send out an email to the labs list making sure people know.

tkuhrt (Thu, 08 Nov 2018 20:17:30 GMT):
FYI, I also created the Ursa mailing list: https://lists.hyperledger.org/g/ursa

hartm (Thu, 08 Nov 2018 20:23:14 GMT):
Thanks Tracy!

tkuhrt (Thu, 08 Nov 2018 20:24:14 GMT):
Hyperledger Ursa is a shared cryptographic library that would enable people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library would be an opt-in repository for projects (and, potentially others) to place and use crypto.

tkuhrt (Thu, 08 Nov 2018 20:24:14 GMT):
Discussions related to the Hyperledger Ursa project

tkuhrt (Thu, 08 Nov 2018 20:24:14 GMT):
Room name changed to: ursa by tkuhrt

tkuhrt (Thu, 08 Nov 2018 20:24:56 GMT):
Discussions related to the Hyperledger Ursa project

tkuhrt (Thu, 08 Nov 2018 20:24:56 GMT):
Hyperledger Ursa is a shared cryptographic library that would enable people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library would be an opt-in repository for projects (and, potentially others) to place and use crypto.

Dan (Thu, 08 Nov 2018 20:31:08 GMT):
:bear:

MALodder (Fri, 09 Nov 2018 12:57:09 GMT):
Have repos been created?

kelly_ (Fri, 09 Nov 2018 16:12:15 GMT):
https://medium.com/interstellar/bulletproofs-pre-release-fcb1feb36d4b

MALodder (Fri, 09 Nov 2018 17:42:27 GMT):
I'd love to put this into z-mix for range proofs in anonymous credentials

MALodder (Fri, 09 Nov 2018 17:46:13 GMT):
I know Indy would like to take advantage of it

Dan (Fri, 09 Nov 2018 18:00:38 GMT):
:bear: ?

hartm (Fri, 09 Nov 2018 20:03:11 GMT):
Yeah, it would defnitely be nice to have an implementation like this included.

rjones (Sat, 10 Nov 2018 05:33:13 GMT):
@MALodder I think we're waiting on the final blessing on the name

greg2git (Sat, 10 Nov 2018 13:39:40 GMT):
who's doing the blessing? ursa is kind of stuck in my mind, considering how polaris is in it

Dan (Sat, 10 Nov 2018 14:17:23 GMT):
_“We have top men working on it now.”_

Dan (Sat, 10 Nov 2018 14:18:03 GMT):
_“…Who?”_ _“…Top… men.”_

MALodder (Sun, 11 Nov 2018 03:16:27 GMT):
_"Not that Jones the other Jones"_

rjones (Sun, 11 Nov 2018 22:34:58 GMT):
As a Jones I heard enough of that Mister Jones song the first time I heard it thank you

hartm (Mon, 12 Nov 2018 05:27:59 GMT):
I think we have enough of a blessing at this point to get going.

hartm (Mon, 12 Nov 2018 05:28:54 GMT):
(There isn't a formal process for this by the way, as I found out when trying to make sure the name was OK).

tkuhrt (Mon, 12 Nov 2018 21:23:54 GMT):
The name is blessed. What we are waiting on is a ticket that will provide us with the details of what we are looking for. @hartm : Are you working on this? Have you already submitted ticket? What can we do to help?

tkuhrt (Mon, 12 Nov 2018 21:23:54 GMT):
The name is blessed. What we are waiting on is a ticket that will provide us with the details of what we are looking to do with the Github repos and settings. @hartm : Are you working on this? Have you already submitted ticket? What can we do to help?

hartm (Mon, 12 Nov 2018 21:57:21 GMT):
@tkuhrt We have an outline but there are still some differences of opinion about how to set things up. We're planning on discussing this at our Wednesday meeting. Can we get back to you after that! Thanks for all of your help!

MALodder (Mon, 12 Nov 2018 22:41:10 GMT):
@tkuhrt I believe Dan said we needed two repos, hyperledger/ursa and hyperledger/ursa-rfcs

tkuhrt (Mon, 12 Nov 2018 23:27:13 GMT):
@hartm : Let us know. We will wait until we hear from you. We will also need to understand if we are moving the labs repos or archiving them.

Dan (Tue, 13 Nov 2018 01:38:50 GMT):
I think we move crypto-lib to ursa or do we want ursa-lib? And then yes, we'll want an rfc repo. What do you guys what to do with zmix? Is that ursa-zmix or does it stay in the lab until some milestone?

Dan (Tue, 13 Nov 2018 01:39:34 GMT):
Or do we just commit the zmix directory tree into the ursa-lib repo?

Dan (Tue, 13 Nov 2018 01:39:57 GMT):
I think the decision kind of depends on evolving the tier concept. (division by namespace, path, etc. ?)

hartm (Tue, 13 Nov 2018 16:06:42 GMT):
I believe we want to incorporate Zmix, but, as Dan points out, clearly separate it from the base signature/symmetric primitive library (because it is, in fact, a separate tier by our definitions, and most people will be less confident in its security). I know very little about build processes compared to some people on this channel. How do you all want to do it? @Dan @MALodder @amundson @binhn.

nage (Tue, 13 Nov 2018 16:22:05 GMT):
@mike is on a plane today, so he can't weigh in, but I believe we already incorporated most of the code together from a repository perspective

nage (Tue, 13 Nov 2018 16:22:05 GMT):
@MALodder is on a plane today, so he can't weigh in, but I believe we already incorporated most of the code together from a repository perspective

nage (Tue, 13 Nov 2018 16:22:25 GMT):
in the way that @hartm describes

MALodder (Tue, 13 Nov 2018 22:27:58 GMT):
I believe we’ll just have in ursa as another folder

MALodder (Tue, 13 Nov 2018 22:28:20 GMT):
I want to merge it into crypto lib/ursa as soon as we agree to

hartm (Wed, 14 Nov 2018 03:30:02 GMT):
@here Just a reminder of our meeting tomorrow! Thanks!

MALodder (Wed, 14 Nov 2018 10:24:22 GMT):
I most likely won't make the call tomorrow but please consider my PRs and comments on the email list for tomorrow's discussion and let me know the outcomes

MALodder (Wed, 14 Nov 2018 13:32:27 GMT):
Jet lag I got my days mixed. I can attend the crypto lib call

Dan (Wed, 14 Nov 2018 14:41:39 GMT):
it is no longer the crypto-lib call tho! :bear:

dhuseby (Wed, 14 Nov 2018 15:04:21 GMT):
Morning. I’m back from the wilderness. Still traveling. But on the call.

hartm (Wed, 14 Nov 2018 15:10:28 GMT):
Meeting notes:

hartm (Wed, 14 Nov 2018 15:10:33 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

hartm (Wed, 14 Nov 2018 15:25:03 GMT):
Rough draft of our project announcement PR: https://docs.google.com/document/d/1FtIq2F7XeGoibz0Hbbn7-n-sRuvCjePh9FAeP-EZ7A8/edit?usp=sharing

hartm (Wed, 14 Nov 2018 15:25:13 GMT):
Please comment if you have questions, comments, or suggestions!

dhuseby (Wed, 14 Nov 2018 18:03:25 GMT):
@here I made a pass on the PR. Mostly changing passive voice to active voice. Other than that, it is great.

hartm (Wed, 14 Nov 2018 18:04:28 GMT):
@dhuseby Busy right now but I'll take a look today. Thanks a lot for making a pass!

dhuseby (Wed, 14 Nov 2018 18:06:04 GMT):
you're welcome

dhuseby (Wed, 14 Nov 2018 18:06:10 GMT):
thanks for putting it together

n3m (Fri, 16 Nov 2018 13:29:30 GMT):
Has left the channel.

nage (Fri, 16 Nov 2018 16:24:02 GMT):
Do we have a plan to track project plans and efforts in JIRA? Or is this a topic we have yet to discuss in the calls?

nage (Fri, 16 Nov 2018 16:24:24 GMT):
(getting asks from the Indy community on how to log issues, track progress, etc)

Dan (Fri, 16 Nov 2018 16:56:11 GMT):
I don't think we discussed yet, but yeah I think jira is the conventional path for HL projects. maybe the variant that our projects have both been using is this rfc process that is a predecessor of creating a user story / epic in jira for new features .. esp features that impact APIs.

hartm (Fri, 16 Nov 2018 17:28:18 GMT):
We haven't discussed this yet in meetings. Someone brought it up near the end of our last meeting, but we didn't have time to discuss it and decided it was a large enough topic that we should defer it to later.

hartm (Fri, 16 Nov 2018 17:28:36 GMT):
Do you all want to talk about it at our next meeting?

Dan (Fri, 16 Nov 2018 20:40:58 GMT):
I find libsnark mostly unmaintained atm. For those working on snarks (maybe @lovesh ?), are you relying on other projects?

MALodder (Sun, 18 Nov 2018 11:56:41 GMT):
we've only considered two snark libraries: libsnark and bellman

MALodder (Sun, 18 Nov 2018 11:57:05 GMT):
lovesh and dmitry said libsnark has been more stable during their tests

MALodder (Sun, 18 Nov 2018 14:36:23 GMT):
I will be traveling tomorrow and have asked @brentzundel to chair the sovrin crypto call tomorrow at 8AM MST.

richzhao (Thu, 22 Nov 2018 13:37:54 GMT):
Has joined the channel.

hartm (Wed, 28 Nov 2018 02:09:15 GMT):
@here Just a reminder of tomorrow's meeting. I've sent out a tentative agenda to the ursa list. Please feel free to respond and add things you'd like to discuss. Thanks!

Dan (Wed, 28 Nov 2018 14:46:43 GMT):
hrmmm i don't see the note. can you double check it hit the list?

Dan (Wed, 28 Nov 2018 14:47:53 GMT):
(I've found lots of other interesting emails I haven't openned yet but not that one. Now I wish i hadn't dug so deep. I'm going to have to re-bury some of these unopened emails. )

hartm (Wed, 28 Nov 2018 14:58:14 GMT):
Just resent it.

hartm (Wed, 28 Nov 2018 14:58:30 GMT):
For some reason it seemed to get black holed by the mail server on the initial send...

Dan (Wed, 28 Nov 2018 15:00:09 GMT):
source was not trustworthy :D

hartm (Wed, 28 Nov 2018 15:03:36 GMT):
Meeting notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

Dan (Wed, 28 Nov 2018 15:20:55 GMT):
https://github.com/hyperledger/ursa-rfcs/pull/2

MALodder (Wed, 28 Nov 2018 15:21:28 GMT):
go here to read https://github.com/hyperledger/ursa-rfcs/blob/77144a9f59aa1394f2ff6505b3284859d875d6ef/README.md

nage (Wed, 28 Nov 2018 15:41:57 GMT):
@dhuseby don't write it yourself if you can recruit new community members ;) https://gist.github.com/shahar96/1215cd1408328d8c5b88

dhuseby (Wed, 28 Nov 2018 17:21:29 GMT):
@nage nice!

dhuseby (Wed, 28 Nov 2018 17:21:51 GMT):
now I just need to write a small bf to asm translator so we can include it into the actual binary

dhuseby (Wed, 28 Nov 2018 19:56:40 GMT):
@MALodder @Dan @hartm just sent invite to sync on Friday.

MALodder (Wed, 28 Nov 2018 19:56:58 GMT):
@dhuseby thanks

MALodder (Wed, 28 Nov 2018 19:57:14 GMT):
did you send it to my email?

MALodder (Wed, 28 Nov 2018 19:57:21 GMT):
or to the ursa-list

dhuseby (Wed, 28 Nov 2018 19:58:02 GMT):
just sent it to your correct email address

dhuseby (Wed, 28 Nov 2018 19:58:16 GMT):
It's just you and me with hart and dan optional

MALodder (Wed, 28 Nov 2018 19:58:17 GMT):
got it

dhuseby (Wed, 28 Nov 2018 19:58:27 GMT):
I see us as forward air controllers

dhuseby (Wed, 28 Nov 2018 19:58:35 GMT):
let's dig into details and report back to the main group

dhuseby (Wed, 28 Nov 2018 19:58:48 GMT):
and have a broader discussion on the 19th

dhuseby (Wed, 28 Nov 2018 19:59:01 GMT):
or at the global summit

dhuseby (Wed, 28 Nov 2018 20:15:20 GMT):
@MALodder @Dan @hartm I just rescheduled the meeting. Same time, just added zoom conferencing.

hartm (Wed, 28 Nov 2018 20:15:54 GMT):
I may have to leave the meeting a bit early. I'm planning on attending https://bacrypto.github.io/events/bacryptoday-7.html on Friday.

dhuseby (Wed, 28 Nov 2018 20:46:23 GMT):
hrm...

dhuseby (Wed, 28 Nov 2018 20:46:33 GMT):
can we do tomorrow?

MALodder (Thu, 29 Nov 2018 02:50:25 GMT):
Works for me

MALodder (Thu, 29 Nov 2018 18:00:19 GMT):
@dhuseby trying to get into zoom and its not working yet

MALodder (Thu, 29 Nov 2018 18:03:41 GMT):
@hartm ^^ are you having this problem

hartm (Thu, 29 Nov 2018 18:07:11 GMT):
@MALodder Yes. It's not working for me either. Says the meeting is on the 30th.

MALodder (Thu, 29 Nov 2018 18:07:28 GMT):
@hartm its working now

MALodder (Thu, 29 Nov 2018 18:07:45 GMT):
https://zoom.us/j/600444473

MALodder (Thu, 29 Nov 2018 18:07:54 GMT):
@hartm ^^^

dhuseby (Thu, 29 Nov 2018 18:09:04 GMT):
https://docs.google.com/document/d/1-BZyrtRWDQFpudvR59NsAdf0_VSFCtz5OoXXAM0Hoy8/edit?usp=sharing

dhuseby (Thu, 29 Nov 2018 18:09:11 GMT):
link to the doc ^^^

MALodder (Fri, 30 Nov 2018 16:48:41 GMT):
@dhuseby @tkuhrt @rjones I'm supposed to be a maintainer on ursa, but I went to do something for the repo and I am not a maintainer

MALodder (Fri, 30 Nov 2018 16:48:49 GMT):
can I be added please?

MALodder (Fri, 30 Nov 2018 16:49:22 GMT):
github handle: mikelodder7

Dan (Fri, 30 Nov 2018 17:33:41 GMT):
I also don't appear to have what I would consider maintainer level permissions on either repo. On a related point, for repo configuration, I recommend copying the settings from Sawtooth as I know that's dialed in for things like requiring +2 reviewers on PR, no force pushing etc. I imagine that @jwagantall would not have gotten that direction. In general we should all issue tickets so that it's clear exactly what is being asked and who is doing it. Project genesis is maybe a little different because there is a lot of process that the Community Architects need to facilitate (has there been a TSC vote, who are the documented maintainers who would otherwise have issued the ticket, etc etc).

jwagantall (Fri, 30 Nov 2018 17:33:41 GMT):
Has joined the channel.

tkuhrt (Fri, 30 Nov 2018 17:37:59 GMT):
@MALodder : I just checked and you are in the Ursa maintainers team. Not sure if someone added you this morning. Can you check again and confirm with us

tkuhrt (Fri, 30 Nov 2018 17:39:41 GMT):
@Dan : You are also a maintainer. This gives write access to the two repositories. I know that we were removing Admin permissions from groups going forward. cc: @Silona

Silona (Fri, 30 Nov 2018 17:39:42 GMT):
Has joined the channel.

Dan (Fri, 30 Nov 2018 17:41:22 GMT):
I think that means we also can't do things like create branches which is a pretty fundamental thing for a maintainer to do. Ry has earlier sensitized me to the issues caused by lack of granularity in github's permissioning model. I do think that despite those challenges, it's appropriate for maintainers to have admin access to their repos.

MALodder (Fri, 30 Nov 2018 18:08:38 GMT):
@tkuhrt Yes I do now

amundson (Fri, 30 Nov 2018 20:08:43 GMT):
I agree with @Dan, at least a few of the maintainers should have admin

MALodder (Fri, 30 Nov 2018 21:02:09 GMT):
We should but which ones

amundson (Fri, 30 Nov 2018 21:11:13 GMT):
One criteria is who is involved in release mechanics

amundson (Fri, 30 Nov 2018 21:13:36 GMT):
Ideally, the most responsible people (which for this basically means people that will not disable or circumvent DCO, because that's about the only thing you could do wrong)

amundson (Fri, 30 Nov 2018 21:17:05 GMT):
There are good reasons for it not to be a large group, because you really do have to be sensitive to the fact that there is a small amount of overlap between things the HL folks would do and the things project repo admins might do, and they should never be in conflict. Like 3-4 folks at most, IMO.

amundson (Fri, 30 Nov 2018 21:22:25 GMT):
``` Sawtooth Github Permissions and Settings ---------------------------------------- Sawtooth has many repositories in Hyperledger's github organization, which all follow similar permissioning rules. Repositories generally have the following groups: - The "Sawtooth Core Admins" group consisting of a very small number of individuals who have admin priviliges on that specific repository. The bar for adding new members to this group is very high. (In the future, this group could be renamed "Sawtooth Admins".) - A repository-specific maintainers group with write permissions, which should match the maintainers list in MAINTAINERS.md. Rules governing maintainership are defined by Sawtooth's governance documentation (in the sawtooth-rfcs repo), and new maintainers are voted in by existing maintainers. Pattern always fits the pattern "Sawtooth X Maintainers", where X is derived from the name of the repository, such as "Core" for sawtooth-core. - The "Sawtooth Core Contributors" group, which has read permissions. Membership in this group need only meet a low threshold, and its general purpose is allowing additional reviewers to be added to the repositories. It includes all Sawtooth contributors, regardless of were they have contributed. (In the future, this group should be renamed "Sawtooth Contributors".) - A repository-specific committers group, which allows additional non-maintainers to be added with write permissions. Generally, this should never be done, because it is very confusing from a github approvals perspective. However, it can be used to grandfather in write permissions. This, most repositories will have exactly three groups: admin, maintainer, and contributor. A 'sawtooth-build' user is commonly added as a collaborator - this is for Sawtooth Jenkins integration. No other collaborators are commonly added. In addition to groups, the following settings apply to each repository: - Features: - Wikis: Unchecked - Sawtooth components use sphinx-doc (usually located in docs/, README.md, etc.). Facilitates project goal of maintaining high-quality peer-reviewed documentation. - Restrict editing to users in teams with push access only: Unchecked - Issues: Unchecked - Sawtooth components use Hyperledger JIRA. Helps facilitates cross-component issues. - Projects: Unchecked - Sawtooth components use Hyperledger JIRA. - Data services: - Vulnerability alerts: Checked - Merge button: - Allow merge commits: Checked - Allow squash merging: Unchecked - Facilitates project-level goal of good commits (https://chris.beams.io/posts/git-commit/); part of peer review includes commit granularity and messages. - Allow rebase merging: Checked - GitHub Pages - Source - None - Project does not use GitHub Pages - Branches - Default branch: master - Branch protection rules: At least one rule is required here, usually applied to '*'. - Require pull request reviews before merging": Checked - Required approving reviews: 2 - Dismiss stale pull request approvals when new commits are pushed: Unchecked - Require review from Code Owners: Unchecked - Restrict who can dismiss pull request reviews: Unchecked - Require status checks to pass before merging": Checked - DCO: Checked - This is required by HL rules and must always be enabled. - other: commonly continuous-integration/jenkins checks related to Jenkins integration - Required signed commits: Unchecked - Include administrators: Checked - very important due overlap between developers and "Sawtooth Core Admins" group - Restrict who can push to matching branches: Unchecked - Webhooks: - JIRA integration (not consistently applied) - RocketChat integration (broken - meant to post a message to #sawtooth-pr-review) ```

amundson (Fri, 30 Nov 2018 21:22:58 GMT):
^ that's a description of the Sawtooth perms and settings

amundson (Fri, 30 Nov 2018 21:26:17 GMT):
it has been helpful to have CODEOWNERS set such that it adds all maintainers as reviewers by default (we are still rolling that out for the Sawtooth repos, but its worked well were we have it)

MALodder (Fri, 30 Nov 2018 21:33:48 GMT):
I would like this responsibility

MALodder (Fri, 30 Nov 2018 21:36:33 GMT):
@Dan in collaboration with @jovan, I submitted the initial PR that merges the history from indy-crypto

jovan (Fri, 30 Nov 2018 21:36:33 GMT):
Has joined the channel.

MALodder (Fri, 30 Nov 2018 21:37:52 GMT):
@hartm @dan @amundson @dhuseby can I please have two reviewers on this [PR](https://github.com/hyperledger/ursa/pull/2)

hartm (Fri, 30 Nov 2018 23:55:08 GMT):
I would say Mike and Shawn, at minimum, should have admin access.

hartm (Fri, 30 Nov 2018 23:56:14 GMT):
Clearly, though, we need github to implement threshold cryptography so that we can allow admin actions with k out of n maintainers signing off!

MALodder (Sat, 01 Dec 2018 00:15:40 GMT):
At least we know a library they could use

MALodder (Sat, 01 Dec 2018 00:37:44 GMT):
😉

NursultanMakhanov (Sat, 01 Dec 2018 15:26:54 GMT):
Has joined the channel.

hartm (Mon, 03 Dec 2018 15:07:27 GMT):
https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit?usp=sharing

donqui (Tue, 04 Dec 2018 18:50:39 GMT):
Has joined the channel.

ashutosh_kumar (Tue, 04 Dec 2018 19:05:18 GMT):
Has joined the channel.

MiguelFJimenezSola (Tue, 04 Dec 2018 19:22:41 GMT):
Has joined the channel.

brentzundel (Tue, 04 Dec 2018 21:30:46 GMT):
https://www.google.com/amp/s/www.coindesk.com/hyperledger-launches-cryptography-toolbox-for-blockchain-developers/amp

JonathanLevi (Tue, 04 Dec 2018 21:45:17 GMT):
Has joined the channel.

kelly_ (Tue, 04 Dec 2018 22:12:32 GMT):
https://medium.com/aztec-protocol/confidential-transactions-have-arrived-a-dive-into-the-aztec-protocol-a1794c00c009

bbehlendorf (Wed, 05 Dec 2018 01:49:05 GMT):
Who will be in Basel and is interested in meeting with Bruce Schneier on Thursday morning to talk about Ursa? After his keynote. Would love to get his support for the project, mention it in his newsletters, etc

bbehlendorf (Wed, 05 Dec 2018 01:49:18 GMT):
Great work everyone on the announcement today, btw

JOYELIN (Wed, 05 Dec 2018 05:47:39 GMT):
Has joined the channel.

iamdm (Wed, 05 Dec 2018 08:22:16 GMT):
Has joined the channel.

kdenhartog (Wed, 05 Dec 2018 09:55:02 GMT):
I'm not actively working on Ursa, but have been following it. I'd love to be a fly on the wall in this at least.

alain2sf (Wed, 05 Dec 2018 10:40:44 GMT):
+1 Same as @kdenhartog would be glad to hear about this.

iamdm (Wed, 05 Dec 2018 10:50:58 GMT):
Has left the channel.

dagacha (Wed, 05 Dec 2018 12:29:52 GMT):
Has joined the channel.

MALodder (Wed, 05 Dec 2018 14:23:59 GMT):
Now you tell me about Bruce Schneier now that I'm not able to go

MALodder (Wed, 05 Dec 2018 14:25:25 GMT):
@Dan did I answer your question on github? We need to get moving on this as many are excited to start contributing

Dan (Wed, 05 Dec 2018 14:35:47 GMT):
There's that wrappers directory? I wasn't sure if that was intentional as it's not part of crypto-lib.

MALodder (Wed, 05 Dec 2018 14:47:58 GMT):
For now I plan to leave it and later expand it so ursa can use it

MALodder (Wed, 05 Dec 2018 14:48:39 GMT):
We can add to the wrappers as we go or did we decide to not have it there?

MALodder (Wed, 05 Dec 2018 14:49:00 GMT):
I’m mostly excited to have something to show before Basil

Dan (Wed, 05 Dec 2018 15:19:28 GMT):
Yeah I'm just trying to be clear on what I'm approving and what's intentionally part of the PR and what might have been swept up inadvertently. I don't want to rubber stamp a PR with 121 files and 47 kloc. (well actually I want to do that because it's easier and I'm lazy, but I feel I shouldn't do that) ;)

MALodder (Wed, 05 Dec 2018 15:23:32 GMT):
I get it Dan, I don't want you rubber stamping either, I just want discussion to happen and not let it sit there stale

Dan (Wed, 05 Dec 2018 15:25:30 GMT):
If only I could get reviews this fast on my other projects! :)

MALodder (Wed, 05 Dec 2018 15:35:56 GMT):
Yeah I prefer to at least have some feedback on going so contributors don’t feel ignored

MALodder (Wed, 05 Dec 2018 15:36:11 GMT):
But maybe it’s just me

dhuseby (Wed, 05 Dec 2018 15:36:21 GMT):
sorry

dhuseby (Wed, 05 Dec 2018 15:36:35 GMT):
In soviet russia the code reviews you!

dhuseby (Wed, 05 Dec 2018 15:36:51 GMT):
i'm super busy with the Iroha release review stuff

dhuseby (Wed, 05 Dec 2018 15:37:02 GMT):
Ive been ignoring everything else

MALodder (Wed, 05 Dec 2018 16:06:59 GMT):
I'm in Charlotte, the code here is basketball

donqui (Wed, 05 Dec 2018 16:09:53 GMT):
go Hornets!

MALodder (Wed, 05 Dec 2018 16:12:05 GMT):
Blue Devils, Wildcats, and 49ers

jsmitchell (Wed, 05 Dec 2018 20:12:28 GMT):
https://www.seattletimes.com/business/amazon-workers-treated-after-bear-repellant-releases-fumes/

jsmitchell (Wed, 05 Dec 2018 20:18:13 GMT):
even countermeasures can be dangerous

Dan (Wed, 05 Dec 2018 21:03:21 GMT):
when I was on my way into the BWCA I was told some guy had recently been rescued... his bear spray was strung on his vest and a tree branch snagged it and sprayed him point blank in the face. He wandered around blind trying to get back to the lake to wash is face.

jsmitchell (Wed, 05 Dec 2018 21:11:19 GMT):
you should have taken that as a sign to turn back

nekia (Thu, 06 Dec 2018 23:15:13 GMT):
Has joined the channel.

scott-long (Tue, 11 Dec 2018 06:02:40 GMT):
Has joined the channel.

MALodder (Tue, 11 Dec 2018 19:58:26 GMT):
So I do not have admin privileges on ursa and I noticed that DCO is not turned on

MALodder (Tue, 11 Dec 2018 19:58:45 GMT):
Can we please turn it on as a required check for PRs?

MALodder (Tue, 11 Dec 2018 19:58:54 GMT):
sorry the DCO is on

MALodder (Tue, 11 Dec 2018 19:59:30 GMT):
new [PR #3](https://github.com/hyperledger/ursa/pull/3)

alain2sf (Wed, 12 Dec 2018 14:50:28 GMT):
Hi Brian @bbehlendorf any news on a possible meet up with Bruce S tomorrow at HGF?

MALodder (Wed, 12 Dec 2018 18:21:05 GMT):
It would be nice to have my PR merged before that meeting with Bruce S

ingo_so (Thu, 13 Dec 2018 11:38:55 GMT):
Has joined the channel.

Abhinavgrg074 (Fri, 14 Dec 2018 06:19:15 GMT):
Has joined the channel.

alain2sf (Fri, 14 Dec 2018 20:52:03 GMT):
The NSA “equivalent” 😉 French organization ANSSI has published a guide to develop secure applications with Rust: https://github.com/ANSSI-FR/rust-guide

ksinkar (Sat, 15 Dec 2018 08:43:55 GMT):
Has joined the channel.

mogamboizer (Mon, 17 Dec 2018 20:50:03 GMT):
Has joined the channel.

bhawana (Tue, 18 Dec 2018 15:44:47 GMT):
Has joined the channel.

Dan (Tue, 18 Dec 2018 17:09:45 GMT):
@MALodder on my todo list this morning was looking at the rebase PR.. just saw you closed it. What's the plan there?

MALodder (Tue, 18 Dec 2018 17:10:27 GMT):
I opened another one to address concerns from Sergei

MALodder (Tue, 18 Dec 2018 17:10:32 GMT):
PR #6

MALodder (Tue, 18 Dec 2018 17:10:47 GMT):
trying to resolve a DCO issue from z-mix

MALodder (Tue, 18 Dec 2018 17:14:23 GMT):
okay its fixed now

MALodder (Tue, 18 Dec 2018 17:14:34 GMT):
https://github.com/hyperledger/ursa/pull/6

Dan (Tue, 18 Dec 2018 17:20:54 GMT):
Cool thanks

MALodder (Tue, 18 Dec 2018 17:30:06 GMT):
Basically PR #3 had some concerns with having the amcl folder dup multiple times, so I cleaned that up and hopefully everyone is happy. PR #6 has crypto-lib and z-mix in it

Dan (Tue, 18 Dec 2018 17:43:16 GMT):
cool. so looks like we can now import a crate from amcl rather than copying in the code that had been generated by amcl?

MALodder (Tue, 18 Dec 2018 18:29:10 GMT):
yes, the indy team helped amcl to do that

MALodder (Tue, 18 Dec 2018 18:29:21 GMT):
took quite an effort

Dan (Tue, 18 Dec 2018 19:19:40 GMT):
oh that's really cool!

Dan (Tue, 18 Dec 2018 20:23:58 GMT):
@MALodder what platform do you build on?

MALodder (Tue, 18 Dec 2018 20:25:53 GMT):
Mac OS x

MALodder (Tue, 18 Dec 2018 20:26:12 GMT):
I’ve built it on all platforms

MALodder (Tue, 18 Dec 2018 20:27:27 GMT):
The build and env setup are in the readme for every os

Dan (Tue, 18 Dec 2018 20:29:52 GMT):
Cool. Yeah following through those directions now. Had a little snag but I think my environment is just dirty. Cleaning up and retrying .. as .. network ... trickles.... a....long.

Dan (Tue, 18 Dec 2018 20:40:09 GMT):
Still hanging up. Any ideas @MALodder ? https://pastebin.com/sPf3p4LF

jsmitchell (Tue, 18 Dec 2018 20:48:59 GMT):
@Dan got a current rust?

Dan (Tue, 18 Dec 2018 20:50:20 GMT):
I did a `rustup update` after it failed the first time followed by a `cargo clean`. Currently at ```$ rustc --version rustc 1.31.0 (abe02cefd 2018-12-04)```

jsmitchell (Tue, 18 Dec 2018 20:53:53 GMT):
has ursa moved to rust 2018?

jsmitchell (Tue, 18 Dec 2018 20:55:02 GMT):
they changed the default allocator recently

jsmitchell (Tue, 18 Dec 2018 20:55:10 GMT):
and it looks like those symbols might be related to that

jsmitchell (Tue, 18 Dec 2018 20:59:20 GMT):
have you tried building it on nightly to see if the behavior is different?

Dan (Tue, 18 Dec 2018 21:00:42 GMT):
I haven't. But before I dig around too much.. @MALodder what version are you at?

jsmitchell (Tue, 18 Dec 2018 21:04:02 GMT):
`rustup install nightly; cargo +nightly build`

jsmitchell (Tue, 18 Dec 2018 21:04:15 GMT):
that lets you test that without changing any of your environment defaults

MALodder (Tue, 18 Dec 2018 21:12:23 GMT):
yes I have seen that error on Mac OS X

MALodder (Tue, 18 Dec 2018 21:12:32 GMT):
its caused from the FFI stuff

MALodder (Tue, 18 Dec 2018 21:13:14 GMT):
@Dan try running `cargo test --no-default-features --features=bn_openssl,pair_amcl,serialization,native,cl`

MALodder (Tue, 18 Dec 2018 21:20:02 GMT):
I'm using rust 2018

Dan (Tue, 18 Dec 2018 21:21:05 GMT):
That worked @MALodder :thumbsup:

MALodder (Tue, 18 Dec 2018 21:21:32 GMT):
great to hear

MALodder (Tue, 18 Dec 2018 21:21:39 GMT):
that command is only dropping the ffi stuff

MALodder (Tue, 18 Dec 2018 21:21:51 GMT):
when I run `cargo build` on windows or linux it just works

MALodder (Tue, 18 Dec 2018 21:22:09 GMT):
Mac OS X must have some wierd thing with the new allocator in C

Dan (Tue, 18 Dec 2018 21:22:36 GMT):
Nice work on the PR. that must have been a ton of work to get all that stuff rebased and mixed in with some new changes. I left a couple minor questions on the PR.

Dan (Tue, 18 Dec 2018 21:22:52 GMT):
Going to pop offline for a bit.

MALodder (Tue, 18 Dec 2018 21:23:13 GMT):
okay I'll go look

MALodder (Tue, 18 Dec 2018 21:29:43 GMT):
@Dan answered your questions

hartm (Wed, 19 Dec 2018 03:08:44 GMT):
@here : We discussed having a meeting tomorrow at our last meeting, but I am going ahead and cancelling it (see the email). Have a great holiday season!

MALodder (Wed, 19 Dec 2018 04:20:31 GMT):
Please review PRs instead

Dan (Wed, 19 Dec 2018 20:03:03 GMT):
Btw, it's not too late for people to send me gifts. ;) Anyone have an abstract algebra text that they really like? I've got one by John Fraleigh that's good but I'd like a complementary text.

hartm (Thu, 20 Dec 2018 01:01:14 GMT):
I believe the Artin textbook is the classic, and best choice for learning traditionally.

hartm (Thu, 20 Dec 2018 01:02:26 GMT):
@Dan Here's a gift idea for you: https://www.hammacher.com/product/backyard-dunk-tank?cm_cat=ProductSEM&cm_pla=AdWordsPLA&source=PRODSEM&gclid=CjwKCAiA9efgBRAYEiwAUT-jtIwsRTAVfTbALfpg1xtq2TSRRRpR2heF-ekU-BhxFetYPoGlY71f7xoCi5oQAvD_BwE

guoger (Thu, 20 Dec 2018 04:14:33 GMT):
Has joined the channel.

Dan (Thu, 20 Dec 2018 15:34:21 GMT):
is that the Euler Totient Tank 500?

mervecankus (Sat, 22 Dec 2018 10:04:14 GMT):
Has joined the channel.

mervecankus (Sat, 22 Dec 2018 10:11:08 GMT):
Hi! Are there any plans to implement homomorphic encyption in Ursa?

infominer33 (Sun, 23 Dec 2018 22:12:45 GMT):
Has joined the channel.

guillermo.correa (Fri, 28 Dec 2018 14:11:20 GMT):
Has joined the channel.

JonGeater (Mon, 31 Dec 2018 12:43:13 GMT):
What's the use case?

JonGeater (Mon, 31 Dec 2018 12:47:23 GMT):
Sorry, being a little less obtuse, what feature of what relevant dependent product needs that, and in what timeframe?

nathanaw (Tue, 01 Jan 2019 12:05:08 GMT):
Has joined the channel.

nathanaw (Tue, 01 Jan 2019 12:06:23 GMT):
hello all, like to enquire when will be the monthly ursa call? - Nathan Aw from Singapore

hartm (Wed, 02 Jan 2019 06:58:26 GMT):
@mervecankus I don't think anyone is planning on implementing HE in Ursa in the near future, although I don't know for sure. At least for most of us (or, for the people that I know about), functional encryption is tied much more closely to our crypto-related use cases than HE. It's also much more challenging to build for general functionalities than HE. As @JonGeater asks, what use case do you have in mind for HE? We are curious here.

hartm (Wed, 02 Jan 2019 06:58:42 GMT):
@nathanaw It's biweekly. The next call is a week from now on the 9th.

dexhunter (Thu, 03 Jan 2019 09:53:59 GMT):
Has joined the channel.

adamgering (Thu, 03 Jan 2019 23:28:39 GMT):
I'd love to see some libraries that utilize the Intel SGX secure enclave.

JonGeater (Fri, 04 Jan 2019 14:55:30 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=4ttyAam2M9Mbhxfab) @adamgering Wouldn't we all :-) There are multiple angles to this though: architecturally do we want to have a top level interface that knows the difference between enclave and non-enclave implementaions? Or have a build option that creates different flavoured builds of the same interface? Or simply have people who care deploy the library into an enclave themselves? And then there's the management angle: if the enclave functionality is somehow pre-created by Ursa, who signs it? And also what about other types of enclave? I could put code in a Secure Element, for example, talkig over GP protocols or SCP11 or something. Or in ARM TrustZone or RISC-V containers. At what layer of a shared crypto library do we expose conscious knowledge of these differences? This could the subject of quite deep discussion, which has started already - Hart and others can probably point to meeting archives where it's been discussed already so we can all get up to speed with the group's thinking on the matter.

JonGeater (Fri, 04 Jan 2019 14:56:19 GMT):
I also want to mod Sawtooth to be able to use general HSMs and ARM TrustZone in additional to SGX for PoET, but that's a different matter

MALodder (Fri, 04 Jan 2019 20:07:01 GMT):
@JonGeater Amen, let me add to that. I think the key management side of it could be done with Ursa to start, where you would pass a key id or key reference for basic crypto operations like signing and key wrapping. The complicated stuff you mention I believe would require many discussions and probably be more advanced features of ursa eventually.

MALodder (Fri, 04 Jan 2019 20:08:35 GMT):
I don't think enclaves are as simple as people think, when they say can it use the enclave, what does that mean? Does it mean the entire crypto operation for calculating a zero knowledge proof in order to keep the data protected, or does it mean simpler stuff like key management

frankz (Sun, 06 Jan 2019 07:33:49 GMT):
Has joined the channel.

gokulalex (Sun, 06 Jan 2019 13:52:41 GMT):
Has joined the channel.

hartm (Mon, 07 Jan 2019 19:54:41 GMT):
@here I think a lot of people on this list are attending real world crypto this week. If you are, please feel free to mention it, and let's meet up! Thanks!

JonGeater (Mon, 07 Jan 2019 20:54:17 GMT):
_is sadly not attending RWC_

Dan (Mon, 07 Jan 2019 21:24:57 GMT):
@hartm I gather you are busy at the conference, but if you get some time could you please re-review https://github.com/hyperledger/ursa-rfcs/pull/2. I think I've satisfied your feedback.

hartm (Mon, 07 Jan 2019 22:18:29 GMT):
@Dan Going to be a bit slow since I am more or less one handed, but I should have some time tomorrow. Thanks!

Dan (Tue, 08 Jan 2019 21:27:49 GMT):
That sounds like a very handy conference.

hartm (Wed, 09 Jan 2019 05:29:22 GMT):
@here Just a reminder of our biweekly meeting tomorrow. Hope to see many of you tomorrow! Thanks!

MALodder (Wed, 09 Jan 2019 14:58:50 GMT):
is the zoom room still https://zoom.us/my/hyperledger.community?

MALodder (Wed, 09 Jan 2019 14:59:05 GMT):
@hartm

MALodder (Wed, 09 Jan 2019 14:59:08 GMT):
^^^

MALodder (Wed, 09 Jan 2019 15:00:21 GMT):
There is another call going on right now in that zoom meeting

hartm (Wed, 09 Jan 2019 15:00:48 GMT):
Fabric maintainer meeting before us.

MALodder (Wed, 09 Jan 2019 15:00:52 GMT):
I can create a zoom room but others probably won't get the notice

MALodder (Wed, 09 Jan 2019 15:01:17 GMT):
can we take over the current call and say something

manu (Wed, 09 Jan 2019 15:02:08 GMT):
i guess they're pretty much done now

MALodder (Wed, 09 Jan 2019 15:03:05 GMT):
@manu you can just stay on

hartm (Wed, 09 Jan 2019 15:05:02 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

lovesh (Wed, 09 Jan 2019 15:07:30 GMT):
Bulletproofs for a pairing friendly curve using milagro crypto, https://github.com/lovesh/bulletproofs-amcl

lovesh (Wed, 09 Jan 2019 15:08:37 GMT):
Currently works on BLS12-381 and BN-254

dhuseby (Wed, 09 Jan 2019 15:47:43 GMT):
https://wiki2.hyperledger.org/display/ursa/

dhuseby (Wed, 09 Jan 2019 15:48:05 GMT):
That’s the ursa homepage on confluence.

MALodder (Wed, 09 Jan 2019 15:51:31 GMT):
@lovesh really cool

cam-parra (Wed, 09 Jan 2019 16:16:38 GMT):
Has joined the channel.

huxiangdong (Thu, 10 Jan 2019 02:13:52 GMT):
Has joined the channel.

DmitriPlakhov (Thu, 10 Jan 2019 12:07:26 GMT):
Has joined the channel.

dhuseby (Thu, 10 Jan 2019 18:47:14 GMT):
@MALodder I am writing the build configuration RFC and the build configuration tool RFC and discovered something that might be a PITA about cargo.

dhuseby (Thu, 10 Jan 2019 18:47:36 GMT):
you can't have build scripts in a workspace root and have it get executed separate from the workspace members

dhuseby (Thu, 10 Jan 2019 18:48:26 GMT):
that means, if you want to do conditional compilation of a workspace (e.g. specify which packages do and do not get build) we have to make our own custom cargo sub-command

dhuseby (Thu, 10 Jan 2019 18:49:58 GMT):
I was already planning on creating cargo-cfg custom subcommand to execute a tool similar to the make menuconfig in the linux kernel. the proposal is to have a tool that gives a nice interface to selecting the components and features included in a build of Ursa. The output from cargo-cfg is a build configuration file that I was going to use as the inputs for a top-level workspace build script

dhuseby (Thu, 10 Jan 2019 18:50:17 GMT):
but a top-level workspace build script isn't a thing

dhuseby (Thu, 10 Jan 2019 18:51:53 GMT):
so I'm now considering also creating cargo-bygge (Norwegian for build) or cargo-schnell or something named like that, that will take a build configuration file and execute cargo in the workspace root with the correct command line arguments (e.g. cargo build -p z-mix --features=....)

dhuseby (Thu, 10 Jan 2019 18:52:14 GMT):
what do you think?

dhuseby (Thu, 10 Jan 2019 18:53:05 GMT):
I've written quite a lot in the build RFC and will shelve it until I get feedback...sending this also to the list.

st (Thu, 10 Jan 2019 20:50:35 GMT):
Has joined the channel.

MALodder (Fri, 11 Jan 2019 00:10:51 GMT):
I like `cargo-schnell` (mostly because I'm too white to pronounce `bygge`)

MALodder (Fri, 11 Jan 2019 00:11:46 GMT):
agree with this as long as builds are reproducible without creating or moving files around

MALodder (Fri, 11 Jan 2019 00:12:10 GMT):
@Dan this is an interesting paper, https://eprint.iacr.org/2019/023.pdf

MALodder (Fri, 11 Jan 2019 00:12:44 GMT):
since Sawtooth uses secp256k1, you might consider double checking that this doesn't affect you

MALodder (Fri, 11 Jan 2019 00:13:20 GMT):
I think you should be okay since you are using the bitcoin library so the nonces should be generated properly

MALodder (Fri, 11 Jan 2019 00:29:01 GMT):
but @Dan this might be a problem https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-van_bulck.pdf

MALodder (Fri, 11 Jan 2019 01:02:00 GMT):
https://foreshadowattack.eu

MALodder (Fri, 11 Jan 2019 01:02:20 GMT):
Don’t trust sgx now

mboyd (Fri, 11 Jan 2019 01:20:33 GMT):
Has joined the channel.

vikpande (Fri, 11 Jan 2019 06:43:22 GMT):
Has joined the channel.

Dan (Fri, 11 Jan 2019 14:00:17 GMT):
lol. foreshadow is old news ;) In general though defense in depth is always good. Mic has some good sgx patterns. For example, in poet, we use a z-test to make sure that if an enclave is broken it can't run amok.. if it wins statistically improbably often then the other nodes distrust it. For key management the risk model is easier.

hartm (Fri, 11 Jan 2019 22:07:09 GMT):
Yeah, Mike, you're a couple of papers behind ;)

hartm (Fri, 11 Jan 2019 22:09:16 GMT):
Lots of people here at RWC are wondering about SGX stuff, though.

JonGeater (Sat, 12 Jan 2019 21:32:09 GMT):
EVeryone knew SGX v1 was broken before it was released. V2 became very questionable after release. V3's the charm :-)

JonGeater (Sat, 12 Jan 2019 21:33:02 GMT):
Seriously, *no* enclave technology will be fully foolproof. As long as there are APIs there will be attacks. If there's a common bus then you get what you pay for,

JonGeater (Sat, 12 Jan 2019 21:34:09 GMT):
The advance that we need now is in system thinking understand what the enclave *can* do for you, and designing around those promises. Many great heroes died searching for the grail. It ain't there.

jleders (Sun, 13 Jan 2019 01:17:35 GMT):
Has joined the channel.

MALodder (Mon, 14 Jan 2019 16:03:29 GMT):
I'm going to use that quote in one of my presentations

JonasM (Mon, 14 Jan 2019 16:03:58 GMT):
Has joined the channel.

DirkKrueger (Mon, 14 Jan 2019 16:53:12 GMT):
Has joined the channel.

vikpande (Mon, 14 Jan 2019 17:44:22 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=ccneTqoBdumnhQKtG) @JonGeater :thumbsup: totally second that statement. like they say "one weak link can break the chain"

hartm (Mon, 14 Jan 2019 18:31:05 GMT):
I'll go even further: *nothing in security* will be fully foolproof...

MALodder (Mon, 14 Jan 2019 21:15:26 GMT):
New [PR](https://github.com/hyperledger/ursa/pull/8)

MALodder (Mon, 14 Jan 2019 21:16:17 GMT):
Would love to have at least one cryptographer like @manu or @hartm look at it to verify modular inverse and pow are correct

MALodder (Mon, 14 Jan 2019 21:17:36 GMT):
Would love to have at least one rust programmer review it too: @lovesh, @Dan, @dhuseby, or @amundson

tylerwince (Wed, 16 Jan 2019 15:07:47 GMT):
Has joined the channel.

NoLimitHoldem (Thu, 17 Jan 2019 07:44:15 GMT):
Has joined the channel.

lovesh (Fri, 18 Jan 2019 12:50:15 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=ugquuF8abk7rvLr2K) @MALodder Added comments

cam-parra (Fri, 18 Jan 2019 14:29:08 GMT):
Silly @MALodder I am a rust programmer as well ;P

MALodder (Fri, 18 Jan 2019 14:54:30 GMT):
@cam-parra feel free to review

cam-parra (Fri, 18 Jan 2019 15:02:45 GMT):
@MALodder and everyone else. I am think that we can break up the main README.md. It seems like we can have different docs for things like installation

MALodder (Fri, 18 Jan 2019 15:12:14 GMT):
@cam-parra feel free to do that and contribute :wink:

Hengming (Fri, 18 Jan 2019 15:17:43 GMT):
Has joined the channel.

cam-parra (Tue, 22 Jan 2019 16:05:34 GMT):
```** Process for ursa-rfcs 1. Declare in ursa-rfcs the exact dependencies that your change will bring in a) give a brief explanation on why you need the dependency b) include link to the dependencies c) how you will handle upgrades d) dependency must come from crates e) if using external library include steps on how to use it d) no nightly dependencies can be brought include 2. Dependency must have an Apache 2.0 license or MIT 3. ** Process for PR in ursa 1. highest level of review a. any change to the rust code b. any change to dependency c. 2. mid tier level of review a. adding new wrapper or modifying new one b. ci/cd pipeline changes ** Process for CI 1. Dependency must come from crates.io a) this means that the dependency cannot be pulling and building from a github repo 2. No nightly dependencies will be accepted ```

cam-parra (Tue, 22 Jan 2019 16:07:49 GMT):
@dhuseby :arrow_up: this are some of the security guidelines that I've come up with for URSA. Not polished but I'd like to get some eyes on it before tomorrow

cam-parra (Tue, 22 Jan 2019 16:08:14 GMT):
@MALodder @lovesh @hartm

MALodder (Tue, 22 Jan 2019 16:08:50 GMT):
nice I'll take a look at it

cam-parra (Tue, 22 Jan 2019 16:12:54 GMT):
If we agree on this then it should be added to the agenda tomorrow

MALodder (Tue, 22 Jan 2019 16:13:13 GMT):
sure let @hartm know

dhuseby (Wed, 23 Jan 2019 04:12:09 GMT):
@MALodder why the requirement for packages coming from crates.io?

dhuseby (Wed, 23 Jan 2019 04:12:14 GMT):
otherwise, this looks good.

hartm (Wed, 23 Jan 2019 04:30:42 GMT):
@here Reminder of tomorrow's meeting, at the usual time. Hope to talk to many of you tomorrow!

cam-parra (Wed, 23 Jan 2019 07:16:15 GMT):
@dhuseby It's because the crates that go into crates.io have been looked at by people like RustSec and are accepted by the community.

MALodder (Wed, 23 Jan 2019 14:58:05 GMT):
@cam-parra there are some exceptions to this rule, if you look in ursa I had to make a package that is local to ursa that wraps a crate

MALodder (Wed, 23 Jan 2019 14:59:38 GMT):
The statement about requiring crates should be the norm but not required. If a dependency is not at crates.io there should be a justification for it

hartm (Wed, 23 Jan 2019 15:06:42 GMT):
Meeting notes:

hartm (Wed, 23 Jan 2019 15:06:45 GMT):
https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

cam-parra (Wed, 23 Jan 2019 16:08:43 GMT):
@hartm @MALodder @dhuseby What is the process to become a mid tier (crypto engineer) maintainer on URSA? I know we have many cryptographers to check major contributions but not enough crypto engineers to do the smaller tasks. I'd love to volunteer for this :)

cam-parra (Wed, 23 Jan 2019 16:10:06 GMT):
I am the maintainer of the sovrin token projects... so I have some experience :smirk:

hartm (Wed, 23 Jan 2019 17:02:10 GMT):
@cam-parra It's just an (informal) vote by the other maintainers.

hartm (Wed, 23 Jan 2019 17:02:27 GMT):
I think we also need more cryptographers too...

david.b.crypto (Wed, 23 Jan 2019 17:07:36 GMT):
Test

david.b.crypto (Wed, 23 Jan 2019 17:12:15 GMT):
Hi Cam, we had mentioned an Indy crypto group in the call

david.b.crypto (Wed, 23 Jan 2019 17:12:40 GMT):
Is there a separate rocket chat channel for that

david.b.crypto (Wed, 23 Jan 2019 17:12:43 GMT):
?

cam-parra (Wed, 23 Jan 2019 17:28:27 GMT):
@hartm How do we start this informal vote? :)

cam-parra (Wed, 23 Jan 2019 17:30:05 GMT):
@david.b.crypto there shouldn't be another channel for indy-crypto. Indy-crypto is now considered legacy. @MALodder correct me if I am wrong but you'd like all the sovrin crypto conversations to stay here correct?

MALodder (Wed, 23 Jan 2019 17:30:31 GMT):
for now yes

MALodder (Wed, 23 Jan 2019 17:31:43 GMT):
On Sovrin rocketchat we have a #crypto channel that would work as well

hartm (Wed, 23 Jan 2019 17:31:45 GMT):
@cam-parra Ask at the next meeting? We haven't done it yet.

hartm (Wed, 23 Jan 2019 17:32:01 GMT):
Or send out an email, perhaps.

cam-parra (Wed, 23 Jan 2019 17:37:46 GMT):
@david.b.crypto I think we're all pretty active on both :) so just shout out in either rocket chats and someone will come to help out

cam-parra (Wed, 23 Jan 2019 17:38:34 GMT):
@hartm I am going to become "that guy" sending daily emails :laughing:

rjones (Wed, 23 Jan 2019 19:44:38 GMT):
@MALodder @hartm I started new threads with Silona and the TSC and Ursa mailing lists. I request your assistance in raising the profile of what you need.

MALodder (Wed, 23 Jan 2019 19:45:25 GMT):
will do

MALodder (Wed, 23 Jan 2019 19:45:25 GMT):
@Hezaveh what version of rust are you using

rjones (Wed, 23 Jan 2019 19:48:31 GMT):
https://lists.hyperledger.org/g/tsc/message/1967

rjones (Wed, 23 Jan 2019 19:48:35 GMT):
thank you @MALodder

Hezaveh (Wed, 23 Jan 2019 20:40:36 GMT):
Has joined the channel.

Hezaveh (Wed, 23 Jan 2019 20:42:26 GMT):
Hi. I was able to run cargo build --release for libzmixt but when I run it in libursa, I get errors:

Hezaveh (Wed, 23 Jan 2019 20:42:58 GMT):
error[E0658]: scoped lint `clippy::too_many_arguments` is experimental (see issue #44690) --> libursa/src/cl/issuer.rs:217:13 | 217 | #[allow(clippy::too_many_arguments)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^

Hezaveh (Wed, 23 Jan 2019 20:43:27 GMT):
it is about 11 of them.

Hezaveh (Wed, 23 Jan 2019 20:43:41 GMT):
error: aborting due to 11 previous errors For more information about this error, try `rustc --explain E0658`. error: Could not compile `ursa`.

Hezaveh (Wed, 23 Jan 2019 20:44:00 GMT):
any help to solve it?

dhuseby (Wed, 23 Jan 2019 21:29:31 GMT):
@cam-parra this is do-ocracy. to become a maintainer, I suggest you pick a part of Ursa that interests you and volunteer to take responsibility for it. Ursa by its very nature is modular. If there isn't an obvious module you want to own, we can come up with maintenance tasks that you can work on. Submitting and landing PR's is how you get maintainer status.

hartm (Thu, 24 Jan 2019 00:01:26 GMT):
@rjones Thanks! Will do.

MALodder (Thu, 24 Jan 2019 03:48:54 GMT):
@Hezaveh what version of rust are you running `rustup show`

amundson (Thu, 24 Jan 2019 07:00:06 GMT):
@hartm @MALodder have you put any more thought into what a "pluggable"? hashing API should look like? we are doing some work were we could adopt and/or work on it if we had an idea of what the design should look like.

amundson (Thu, 24 Jan 2019 07:01:09 GMT):
(as in, allowing the hashing algorithm to be swapped easily, etc.)

hartm (Thu, 24 Jan 2019 07:13:12 GMT):
@amundson I believe that @dhuseby has been preparing an RFC for this.

hartm (Thu, 24 Jan 2019 07:14:08 GMT):
There is some pretty interesting stuff we can do around this. Check this paper out: https://eprint.iacr.org/2018/770

cam-parra (Thu, 24 Jan 2019 12:40:31 GMT):
@dhuseby I can take responsibility for URSA wrappers and security and culture of the repo. Basically the smaller tasks that don't require a Cryptographer

Hezaveh (Thu, 24 Jan 2019 12:53:18 GMT):
@MALodder rustc 1.32.0 (9fda7c223 2019-01-16)

MALodder (Thu, 24 Jan 2019 15:01:59 GMT):
@Hezaveh interesting, I'm running rust 1.31 and I don't see that error. Let me upgrade to that and see if I reproduce it

MALodder (Thu, 24 Jan 2019 15:04:16 GMT):
@amundson yes some work has been done already in ursa but I'm not entirely sold on it and would love to work with you to improve it

MALodder (Thu, 24 Jan 2019 15:05:30 GMT):
@Hezaveh try running this command and recompiling `rustup component add clippy`

amundson (Thu, 24 Jan 2019 16:25:11 GMT):
@MALodder @dhuseby ok, I'm looking at this - https://github.com/hyperledger/ursa/blob/master/libursa/src/hash/mod.rs - if there are some thoughts on making this better, even if its rough ideas, maybe I can work that in.

amundson (Thu, 24 Jan 2019 16:26:32 GMT):
any thoughts on starting to publish ursa as a crate? If I start to pull it in, I'd like to be able to pin the version as presumably these APIs aren't stable yet.

MALodder (Thu, 24 Jan 2019 16:46:15 GMT):
@amundson yeah We definitely want to publish as a crate. The question becomes who does this

amundson (Thu, 24 Jan 2019 16:51:36 GMT):
I could probably find someone to help from my team, that does it for sawtooth, if that's what you mean.

amundson (Thu, 24 Jan 2019 16:52:49 GMT):
what we did for sawtooth is set it up so multiple people have access to the create so it's not just one person, but in practice it is usually one or two people doing the process

amundson (Thu, 24 Jan 2019 16:52:49 GMT):
what we did for sawtooth is set it up so multiple people have access to the crate so it's not just one person, but in practice it is usually one or two people doing the process

MALodder (Thu, 24 Jan 2019 16:53:00 GMT):
Sure totally agree

MALodder (Thu, 24 Jan 2019 16:53:21 GMT):
as long as multiple people can do it

Hezaveh (Thu, 24 Jan 2019 21:50:47 GMT):
@MALodder I did rustup component add clippy, same errors ...

MALodder (Thu, 24 Jan 2019 22:32:51 GMT):
@Hezaveh what OS are you running?

dhuseby (Fri, 25 Jan 2019 01:11:52 GMT):
@cam-parra that's awesome, thanks for volunteering

dhuseby (Fri, 25 Jan 2019 01:11:58 GMT):
we could certainly use your help

dhuseby (Fri, 25 Jan 2019 01:12:27 GMT):
Hey everybody, we have our JIRA project set up now: https://jira.hyperledger.org/projects/URSA/

dhuseby (Fri, 25 Jan 2019 01:13:06 GMT):
to answer your question: we're not using Github issues because they don't support confidential security bugs which are required for our responsible disclosure policy

dhuseby (Fri, 25 Jan 2019 01:13:27 GMT):
I will be setting up a bot that will auto-close any github issues filed and tell the submitter to go to our JIRA to file bugs.

dhuseby (Fri, 25 Jan 2019 01:13:37 GMT):
the bot was written by a volunteer on the Iroha team

cam-parra (Fri, 25 Jan 2019 09:41:35 GMT):
From past experience working on INDY I would suggest that all who do submit bugs try to submit steps to reproduce and logs. The more details we get from the reporter the easier it makes it for the volunteers to fix. Also if you have the experience and the time it's best to report assign to yourself and fix the bug :)

Silona (Fri, 25 Jan 2019 18:15:33 GMT):
Also @dhuseby 's security bug process... https://wiki2.hyperledger.org/display/HYP/Security+Bug+Process

amundson (Fri, 25 Jan 2019 19:19:53 GMT):
@dhuseby why don't you just turn off github issues?

sg777 (Sat, 26 Jan 2019 04:44:59 GMT):
Has joined the channel.

VipinB (Sun, 27 Jan 2019 00:08:18 GMT):
https://medium.com/@vipinsun/real-world-crypto-2019-b011922858d1 Real world crypto 2019, a summary report by yours truly

Hezaveh (Sun, 27 Jan 2019 20:17:20 GMT):
@MALodder ubuntu 16.04

cam-parra (Mon, 28 Jan 2019 11:24:02 GMT):
Thanks @VipinB ! Enjoyed the read

MALodder (Mon, 28 Jan 2019 15:00:14 GMT):
@Hezaveh here's what you could do to see if you can compile. Delete the lines that have the text `#[allow(clippy::too_many_arguments)]`

MALodder (Mon, 28 Jan 2019 15:00:29 GMT):
then try to compile and see if you still get the error

Hezaveh (Mon, 28 Jan 2019 15:18:37 GMT):
@MALodder It worked. Thank yoy. I basically commented these lines: #[allow(clippy::many_single_char_names)] #[allow(clippy::too_many_arguments)] #[allow(clippy::not_unsafe_ptr_arg_deref)]

MALodder (Mon, 28 Jan 2019 15:19:07 GMT):
@Hezaveh glad to hear that, but still confused as to why that doesn't work for you

MALodder (Mon, 28 Jan 2019 15:19:23 GMT):
why does clippy intefere with your build

MALodder (Mon, 28 Jan 2019 15:19:30 GMT):
I'll have to investigate that one

Hezaveh (Mon, 28 Jan 2019 15:20:26 GMT):
@MALodder Thanks again.

MALodder (Mon, 28 Jan 2019 15:20:39 GMT):
@Hezaveh no problem

MALodder (Mon, 28 Jan 2019 16:27:51 GMT):
@amundson Whats the best way to setup the rust crate for ursa so multiple people can publish?

dhuseby (Mon, 28 Jan 2019 16:50:53 GMT):
@amundson we have a bot we are deploying that auto-closes github issues and directs reporters to the HL JIRA.

dhuseby (Mon, 28 Jan 2019 16:51:15 GMT):
that's for existing projects that have github issues that are informative and shouldn't be lost forever.

dhuseby (Mon, 28 Jan 2019 16:51:23 GMT):
if we turn off GH issues, old issues disappear

dhuseby (Mon, 28 Jan 2019 16:51:30 GMT):
for new projects like Ursa we can disable them

dhuseby (Mon, 28 Jan 2019 16:51:48 GMT):
but then we need to document in the README.md that issues should be filed in the JIRA

dhuseby (Mon, 28 Jan 2019 16:52:06 GMT):
personally, I like the idea of not disabling GH issues and using the bot, even on new projects like URsa

dhuseby (Mon, 28 Jan 2019 16:52:26 GMT):
that way we're actively targeting bug reporters with the message: hey, please file bugs in JIRA

amundson (Mon, 28 Jan 2019 22:42:54 GMT):
@dhuseby has the disadvantage that you let people enter bugs in the wrong place, with kind of a slap after they do it.

rberg2 (Mon, 28 Jan 2019 22:47:14 GMT):
Has joined the channel.

amundson (Mon, 28 Jan 2019 22:47:34 GMT):
@MALodder I asked @rberg2 and @rbuysse to pop in here to help, they do the publishing for Sawtooth

rbuysse (Mon, 28 Jan 2019 22:47:34 GMT):
Has joined the channel.

rberg2 (Mon, 28 Jan 2019 22:49:51 GMT):
Hello

MALodder (Tue, 29 Jan 2019 03:06:59 GMT):
@rberg2 hello, we would like to deploy ursa as a crate but since this is a community project, we need several maintainers to be able to do so once an agreed upon release has been reached, what is the best way to do this?

rbuysse (Tue, 29 Jan 2019 15:46:34 GMT):
@MALodder crates.io supports that pretty nicely

duckthatquantum (Thu, 31 Jan 2019 01:39:12 GMT):
Has joined the channel.

MuthuT (Thu, 31 Jan 2019 05:39:55 GMT):
Has joined the channel.

cam-parra (Thu, 31 Jan 2019 12:10:12 GMT):
@MALodder @dhuseby Do we have a final decision for the URSA logo? I am working on REAME.md's and would like to include the logo if we have one

MALodder (Thu, 31 Jan 2019 14:54:34 GMT):
I don't know

hartm (Thu, 31 Jan 2019 15:03:51 GMT):
I don't think we do. We need to though...

cam-parra (Thu, 31 Jan 2019 15:12:13 GMT):
Should be a matter of just setting a deadline and sending out a final warning and then counting up the votes

cam-parra (Thu, 31 Jan 2019 15:12:36 GMT):
Also @MALodder Could you merge my PR please and thank you!

MALodder (Thu, 31 Jan 2019 15:13:24 GMT):
Ursa requires two reviewers/PR. I already approved it, need to have another maintainer approve it first

MALodder (Thu, 31 Jan 2019 15:13:54 GMT):
@lovesh @hartm @dhuseby @amundson usually are good at looking at PRs

cam-parra (Thu, 31 Jan 2019 15:15:11 GMT):
Okay no worries. I will just make the next PR from another branch. Also if we could consider adding me to the maintainers list and given write access I can help with these kinds of PRs

MALodder (Thu, 31 Jan 2019 15:16:37 GMT):
yeah we can discuss that on the next call next week

dhuseby (Thu, 31 Jan 2019 15:45:06 GMT):
I’ll take a look at the PR’s today

dhuseby (Thu, 31 Jan 2019 15:45:46 GMT):
As for the logo, we just need to put together the options and run a vote on the mailing list or surveymonkey.

cam-parra (Thu, 31 Jan 2019 15:46:34 GMT):
People voted on the mailing list last time as we asked on the call :)

amundson (Thu, 31 Jan 2019 16:35:25 GMT):
can we recap were we are at with the logo discussion here? I saw a lot of initial support for the wire bear. is there similar support for the other logos as well? Are we debating them all, or just a couple?

rjones (Thu, 31 Jan 2019 18:59:42 GMT):
Has left the channel.

VipinB (Thu, 31 Jan 2019 19:05:36 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=5wX2Qqi7fQz4y6Mb8) Has this disappeared?

VipinB (Thu, 31 Jan 2019 19:18:56 GMT):
It does automatically redirect to wiki.

dhuseby (Thu, 31 Jan 2019 22:21:25 GMT):
Ursa logo survey is now open: https://www.surveymonkey.com/r/XN7VG2T

dhuseby (Thu, 31 Jan 2019 22:21:38 GMT):
please take a moment to give us your top 2 choices

dhuseby (Thu, 31 Jan 2019 22:21:42 GMT):
@here ^^

VipinB (Thu, 31 Jan 2019 22:24:38 GMT):
Done!

danielhardman (Thu, 31 Jan 2019 22:25:02 GMT):
I responded. However, I think the variations in color cloud the issue. I'd prefer to vote on the concept, and then vote on color separately. Otherwise I think you may get color variations watering down the weight of a concept.

MALodder (Thu, 31 Jan 2019 22:29:30 GMT):
agreed

MALodder (Thu, 31 Jan 2019 22:33:25 GMT):
https://lwn.net/Articles/776688/

MALodder (Thu, 31 Jan 2019 22:33:35 GMT):
interesting ^^, maybe we can use it for ursa

JonGeater (Fri, 01 Feb 2019 13:54:37 GMT):
Gosh I hope we get at least as many voters as there are logo choices :-)

JonGeater (Fri, 01 Feb 2019 13:55:52 GMT):
I've done my civic duty

VipinB (Fri, 01 Feb 2019 13:59:21 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=TE7G7TkafKg2mGF7a) Great, thanks for the link- another step towards true E2EE

MALodder (Fri, 01 Feb 2019 15:12:36 GMT):
Lets hope they actually do integrity checking unlike AMD's version

brentzundel (Fri, 01 Feb 2019 17:36:02 GMT):
https://github.com/lovesh/bulletproofs

dhuseby (Fri, 01 Feb 2019 19:24:22 GMT):
@here so there was no standout winner from yesterday's logo survey so I put together more choices for us. Please take a few minutes and cast your vote on these: https://www.surveymonkey.com/r/KCM92WV

VipinB (Fri, 01 Feb 2019 19:41:27 GMT):
@dhuseby where are these choices from? Do we have #logofatigue??

dhuseby (Fri, 01 Feb 2019 20:12:34 GMT):
@VipinB the first survey resulted in a 3-way tie for first and a 4-way tie for second

dhuseby (Fri, 01 Feb 2019 20:12:58 GMT):
this second batch comes from a logo marketplace

dhuseby (Fri, 01 Feb 2019 20:13:11 GMT):
super cheap and we get documented transfer of copyright so we can trademark

dhuseby (Fri, 01 Feb 2019 20:13:43 GMT):
I really like #12 in the second batch. It's simple and assertive. When a bear makes that posture in the wild, it means "fuck off"

dhuseby (Fri, 01 Feb 2019 20:14:38 GMT):
Plus we can do fun things with it

dhuseby (Fri, 01 Feb 2019 20:14:47 GMT):

IMG_4833.jpeg

dhuseby (Fri, 01 Feb 2019 20:15:13 GMT):
If you rotate it a little you get the expression, “did you just try to write your own crypto? Srsly?”

dhuseby (Fri, 01 Feb 2019 20:15:49 GMT):
And because it’s a simple outline, we can do all kinds of fun swag.

dhuseby (Fri, 01 Feb 2019 20:16:14 GMT):
This is an example of the kind of things we can do with swag:

dhuseby (Fri, 01 Feb 2019 20:16:32 GMT):

57068182878__29A2267C-E890-400A-9718-172B276BA211.jpeg

dhuseby (Fri, 01 Feb 2019 20:16:58 GMT):
We can make custom embroidered hats or t-shirts as prizes for significant contributions.

dhuseby (Fri, 01 Feb 2019 20:17:50 GMT):
BTW, I call that hat my “hide and seek world champion” hat 😂😂😂

tomislav (Sat, 02 Feb 2019 02:10:58 GMT):
Has joined the channel.

JonGeater (Mon, 04 Feb 2019 09:41:37 GMT):
@dhuseby Do you want to come to the UK and design our new Brexit referendum question? I'd like like a forced vote of "not what we decided last time" ;-)

jcarpenter (Mon, 04 Feb 2019 19:35:16 GMT):
Has joined the channel.

dhuseby (Mon, 04 Feb 2019 20:40:06 GMT):
LOL, totally

dhuseby (Mon, 04 Feb 2019 20:40:21 GMT):
of course I'll just throw your tea in the harbor and burn your forts down.

dhuseby (Mon, 04 Feb 2019 20:40:34 GMT):
it's my reflexive response to British bullshit

dhuseby (Mon, 04 Feb 2019 20:40:35 GMT):
; )

dhuseby (Mon, 04 Feb 2019 20:40:53 GMT):
@JonGeater ^^^

dhuseby (Mon, 04 Feb 2019 20:41:51 GMT):
soooo, we've narrowed the logos down to 4, two from the first batch, two from the second batch. Final poll going out today with winner presentation on Wednesday meeting.

JonGeater (Mon, 04 Feb 2019 21:02:20 GMT):
OK cool, I'll continue to turn out to vote then

ursamajor666 (Tue, 05 Feb 2019 03:35:02 GMT):
Has joined the channel.

ursamajor666 (Tue, 05 Feb 2019 03:35:40 GMT):
love the hat guys its top notch it really is

ursamajor666 (Tue, 05 Feb 2019 03:35:40 GMT):
Greetings @dhuseby nice hat!

cam-parra (Tue, 05 Feb 2019 14:34:18 GMT):
@dhuseby I am ready for that URL

cam-parra (Tue, 05 Feb 2019 14:35:07 GMT):
If you can let me know the winner by sometime tonight (MST) I can have our readme updated with the logo for the unveiling

cam-parra (Tue, 05 Feb 2019 14:41:51 GMT):
Also any chance of us getting a URSA twitter account? It be a nice way to update all our social friends

JonGeater (Tue, 05 Feb 2019 15:06:26 GMT):
There doesn’t seem to be a consistent theme around sub-project twitter handles. Perhaps should check with the marketing committee

hartm (Tue, 05 Feb 2019 15:20:35 GMT):
Yeah, I think the marketing committee would not be thrilled if we started a twitter account without telling them.

hartm (Tue, 05 Feb 2019 15:23:02 GMT):
We can reach out to them, but I would be surprised if they let us have a twitter that "officially" spoke for a project.

hartm (Tue, 05 Feb 2019 15:27:27 GMT):
You can ask though, if you like.

hartm (Tue, 05 Feb 2019 15:27:33 GMT):
You never know what they will say.

cam-parra (Tue, 05 Feb 2019 15:27:37 GMT):
I see. Interesting... I don't think its a hill I want to die on

hartm (Tue, 05 Feb 2019 15:27:48 GMT):
Definitely not, but you can ask if you want.

dhuseby (Tue, 05 Feb 2019 18:17:55 GMT):
@here So there was some last minute voting going on yesterday so I waited until this morning to put together the last survey. There were clear winners from both batches that I have put together into one last poll. Please vote today and come to the meeting tomorrow morning to discuss the final logo decision. Here's the final survey: https://www.surveymonkey.com/r/YWGSSTT

dhuseby (Tue, 05 Feb 2019 18:18:14 GMT):
I included the other colors of the Bear+Star logo because collectively, they got the most votes for both first and second choice

dhuseby (Tue, 05 Feb 2019 18:18:28 GMT):
if the BearStar logo wins, then we'll have to decide on the color.

dhuseby (Tue, 05 Feb 2019 18:24:27 GMT):
@here VOTE TODAY: https://www.surveymonkey.com/r/YWGSSTT

vikpande (Tue, 05 Feb 2019 18:26:46 GMT):
:thumbsup:

lovesh (Tue, 05 Feb 2019 20:09:14 GMT):
Seems Apache milagro has disappeared from github https://github.com/milagro-crypto/amcl Does anyone know why?

cam-parra (Tue, 05 Feb 2019 20:26:28 GMT):
@lovesh https://github.com/apache/incubator-milagro-crypto

ursamajor666 (Tue, 05 Feb 2019 20:39:25 GMT):
twitter is not our main focus when a logo hang in fate

cam-parra (Tue, 05 Feb 2019 21:15:24 GMT):
@hartm I've added some house keeping items to the agenda

cam-parra (Tue, 05 Feb 2019 21:15:24 GMT):
@hartm I've added some house keeping items to the agenda for tomorrows call. Hope that helps a bit

hartm (Tue, 05 Feb 2019 22:18:32 GMT):
@cam-parra Yep! Thanks! Please don't be shy about adding stuff.

JonGeater (Tue, 05 Feb 2019 23:46:41 GMT):
_has disagreed and committed ;-)_

danintel (Wed, 06 Feb 2019 00:42:20 GMT):
Has joined the channel.

hartm (Wed, 06 Feb 2019 00:43:11 GMT):
@here Just a reminder of tomorrow's Ursa meeting. Agenda is here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=6422924. Please add things as you see appropriate. Thanks!

ElSqueakador (Wed, 06 Feb 2019 01:11:38 GMT):
Has joined the channel.

lovesh (Wed, 06 Feb 2019 04:26:57 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=sdwPSQrKRNPKQKST3) @cam-parra That is not the one we used to use. Secondly its missing the new pairing implementation

arsulegai (Wed, 06 Feb 2019 11:23:50 GMT):
Has joined the channel.

JonGeater (Wed, 06 Feb 2019 12:14:20 GMT):
We still don't seem to have the call-in details on the wiki (now Confluence). Can we do this please? I've finially managed to clear Wednesday at 07:00 so I can start joining :-)

hartm (Wed, 06 Feb 2019 14:50:03 GMT):
@JonGeater They're in the Hyperledger calendar (for this and all other hyperledger meetings).

hartm (Wed, 06 Feb 2019 15:01:10 GMT):
Meeting notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

dhuseby (Wed, 06 Feb 2019 15:42:47 GMT):
https://wiki.hyperledger.org/display/BOOTHK/Sessions

nage (Wed, 06 Feb 2019 15:43:56 GMT):
@mboyd and I will be there at the Bootcamp

nage (Wed, 06 Feb 2019 15:44:22 GMT):
We can help with some basic Ursa stuff as we can fold it into the Indy track

dhuseby (Wed, 06 Feb 2019 15:50:39 GMT):
@VipinB I cover a lot of that in the blog post on Iroha's CVE bug: https://www.hyperledger.org/blog/2019/02/04/hyperledger-iroha-security-audit-results

arsulegai (Wed, 06 Feb 2019 15:55:27 GMT):
Please add me to the Tuesday's meeting mail list

ArnabChatterjee (Wed, 06 Feb 2019 18:31:26 GMT):
Has joined the channel.

deepikav (Thu, 07 Feb 2019 19:27:34 GMT):
Has joined the channel.

JonGeater (Sat, 09 Feb 2019 17:46:58 GMT):
The Tuesday meeting still doesn’t appear to be on the calendar on the wiki nor mailed out. Have I missed something?

hartm (Sat, 09 Feb 2019 23:30:58 GMT):
@JonGeater No. Maybe ask Mike? It's technically the "Sovrin crypto meeting" but really only covers Hyperledger stuff at this point.

JonGeater (Sun, 10 Feb 2019 17:54:15 GMT):
@dhuseby were you going to action this? I'm happy to join the Tuesday call if I get the details.

MALodder (Mon, 11 Feb 2019 15:39:40 GMT):
@JonGeater I sent the information to @dhuseby but here is the information. 8AM MST Tuesday. https://zoom.us/j/567114224 Agenda: https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit

hartm (Mon, 11 Feb 2019 19:23:20 GMT):
@MALodder Is there anything Sovrin-specific left in this meeting? Sure, there are applications that Sovrin wants to build, but all of this is being done in the open and many other people are interested in these applications. Should we rebrand this as the zmix meeting?

MALodder (Mon, 11 Feb 2019 19:23:50 GMT):
hmmm, yes like anonymous read/write to the ledger

hartm (Mon, 11 Feb 2019 19:23:52 GMT):
Also, unfortunately, I can't make tomorrow's meeting--I have an appointment with the shoulder surgeon. Hopefully he will let me do more stuff.

MALodder (Mon, 11 Feb 2019 19:23:57 GMT):
consensus stuff

MALodder (Mon, 11 Feb 2019 19:24:10 GMT):
so its not all zmix

MALodder (Mon, 11 Feb 2019 19:24:18 GMT):
alot of it is zmix though

hartm (Mon, 11 Feb 2019 19:24:23 GMT):
Anonymous read/write to the ledger is definitely in the crypto purview, so that would count as zmix.

hartm (Mon, 11 Feb 2019 19:24:55 GMT):
As far as I know, we haven't discussed pure consensus in quite some time.

MALodder (Mon, 11 Feb 2019 19:36:19 GMT):
that is true

MALodder (Mon, 11 Feb 2019 19:36:41 GMT):
tomorrow I want to discuss TEE and HSMs. That's an ursa item but how it applies to Sovrin

MALodder (Mon, 11 Feb 2019 19:43:29 GMT):
Good luck on your appt

rekmarks (Mon, 11 Feb 2019 23:20:34 GMT):
Has joined the channel.

hartm (Tue, 12 Feb 2019 02:14:39 GMT):
Thanks!

ashokkj (Tue, 12 Feb 2019 03:44:59 GMT):
Has joined the channel.

JonGeater (Tue, 12 Feb 2019 08:13:59 GMT):
Lol, and sorry...after making a fuss I can’t make a call at 8:00 MST today...surprise shareholder visit. Next time, for sure. Thanks for the details

nage (Tue, 12 Feb 2019 16:52:43 GMT):
@dhuseby is this the paper that came up in the Sovrin crypto call today? https://raw.githubusercontent.com/ianopolous/Peergos/master/papers/wuala-cryptree.pdf

dhuseby (Tue, 12 Feb 2019 21:30:41 GMT):
@nage yes

dhuseby (Tue, 12 Feb 2019 21:30:58 GMT):
Tahoe-LAFS uses a variant of Cryptree

dhuseby (Tue, 12 Feb 2019 21:31:38 GMT):
there was a ton of great technology that came out of the Wuala project...to bad La Cie bought it to kill it : /

dhuseby (Tue, 12 Feb 2019 21:32:28 GMT):
the other key piece of tech is their ungamable, decentralized reputation system called Havelaar: http://netecon.seas.harvard.edu/NetEcon06/Papers/gromilund_06.pdf

dhuseby (Tue, 12 Feb 2019 21:33:00 GMT):
I think havelaar would be a nice addition to any consensus network for judging reliability of nodes

dhuseby (Tue, 12 Feb 2019 21:33:36 GMT):
it could be used to incetivize reliability by weighting consensus votes by uptime

dhuseby (Tue, 12 Feb 2019 21:38:23 GMT):
@nage BTW, I have a toy implementation of Cryptree in Python using PyNaCl primitives somewhere in my backups

dhuseby (Tue, 12 Feb 2019 21:38:50 GMT):
it's just a library of classes that handle the key links and the data structure itself

nage (Tue, 12 Feb 2019 22:58:34 GMT):
_looks forward to talking about this some more in the Crypto calls and in Hong Kong_

MALodder (Wed, 13 Feb 2019 23:22:47 GMT):
I like cryptree, its similar but better to ideas I had for a wallet

MALodder (Thu, 14 Feb 2019 16:05:21 GMT):
So where did everyone go? I haven't seen or heard any comments or anything for PRs on RFCs or the repo

MALodder (Thu, 14 Feb 2019 16:08:21 GMT):
Is there an opinion for which documentation framework we should use for Ursa?

MALodder (Thu, 14 Feb 2019 16:09:03 GMT):
readthedocs, gitbook?

MALodder (Thu, 14 Feb 2019 16:10:16 GMT):
readme.io, gelato.io?

MALodder (Thu, 14 Feb 2019 16:14:27 GMT):
I've been looking at mdBook and quite like it

MALodder (Thu, 14 Feb 2019 16:15:29 GMT):
Also would it make sense to create a separate repo for documentation called ursa-docs

hartm (Thu, 14 Feb 2019 16:31:12 GMT):
@MALodder I have been kidnapped by the Crypto deadline, which was yesterday.

hartm (Thu, 14 Feb 2019 16:31:29 GMT):
I'll go over everything today or tomorrow.

mp (Fri, 15 Feb 2019 08:31:18 GMT):
Has joined the channel.

JonGeater (Fri, 15 Feb 2019 13:29:35 GMT):
And I just found out how to turn off spam filtering on my corporate Office365 (grrrr) so I'm receiving Hyperledger email again :-)

kdenhartog (Fri, 15 Feb 2019 22:29:40 GMT):
@MALodder If you go with readthedocs you can basically copy and paste Michael B's work on Indy and get that stood up in a very short time period.

cam-parra (Sat, 16 Feb 2019 17:59:25 GMT):
I'd prefer gitbooks not a fan of read the docs

nanspro (Mon, 18 Feb 2019 02:04:18 GMT):
Has joined the channel.

MALodder (Mon, 18 Feb 2019 15:46:03 GMT):
@JonGeater for interfaces to HSM's and TPMs, do they mostly use PKCS11 or have they evolved to a different API description?

JonGeater (Tue, 19 Feb 2019 11:27:20 GMT):
Both

JonGeater (Tue, 19 Feb 2019 11:28:46 GMT):
PKCS#11 is not particularly good in its own right but it does allow interop for relatively trivial use cases so everybody supports it as a pluggable interface for application interop, but everybody also promotes their own interfaces for more nuanced operations, especially where complex administrative oiperations or shared key management comes into the frame

JonGeater (Tue, 19 Feb 2019 11:30:13 GMT):
TPM is so very far away from PKCS#11 that it's almost not worth doing, but it does just about work to crudely map enough of the basic functions to make key gen, wrap/unwrap, and sign operations work

JonGeater (Tue, 19 Feb 2019 11:31:58 GMT):
For HSMs it really depends who we're looking at. The old Crysalis tokens and some smartcards did do PKCS#11 natively, although note that complex things like changing ACLs, making bacups and so on tended to use extensions and out-of-band operations even so. nCipher and Utimaco are wrappers (and so you have to look REALLY carefully for security gaps between the interfaces)

JonGeater (Tue, 19 Feb 2019 11:33:18 GMT):
Lastly, we've had KMIP for 10 years now, so that should be considered too. PKCS#11 V3 out of OASIS is quite well integraed with KMIP, and is (as a consequence) rather diffreent to PKCS#11 V2.x. I'd argue it's a lot better in most ways, but unfortauntely it's going to take a very long time before people adopt it

danintel (Tue, 19 Feb 2019 16:36:55 GMT):
PKCS#11 is hardware token based and the API could be cumbersome with sessions and all. But it is a common API to all the hardware that you mention, along with networked KMIP.

sureshtedla (Wed, 20 Feb 2019 11:23:40 GMT):
Has joined the channel.

hartm (Wed, 20 Feb 2019 15:02:02 GMT):
Meeting notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

JonGeater (Wed, 20 Feb 2019 15:05:37 GMT):
I'm going to add myself to the minutes now while I fight with Zoom. Be with you in a second

MHBauer (Wed, 20 Feb 2019 18:02:41 GMT):
Has joined the channel.

david.b.crypto (Thu, 21 Feb 2019 15:42:24 GMT):
i miss the call yesterday, double booked

MALodder (Thu, 21 Feb 2019 15:59:30 GMT):
is JIRA setup for ursa yet

MALodder (Thu, 21 Feb 2019 15:59:44 GMT):
I don't see it as a project at https://jira.hyperledger.org

MALodder (Thu, 21 Feb 2019 16:00:13 GMT):
I'm happy to create it if that's how to get started

david.b.crypto (Thu, 21 Feb 2019 16:10:11 GMT):
in meetingt notes from yesterday, we had 'Discussion on encryption API" status: "tabled to email list"

david.b.crypto (Thu, 21 Feb 2019 17:05:33 GMT):
i may be able to help from an HSM perspective

david.b.crypto (Thu, 21 Feb 2019 17:05:49 GMT):
looking forward to that conversation\

david.b.crypto (Thu, 21 Feb 2019 17:06:00 GMT):
also

david.b.crypto (Thu, 21 Feb 2019 17:07:41 GMT):
I want to start towards wrapping cl signatures for fabric

david.b.crypto (Thu, 21 Feb 2019 17:08:07 GMT):
are we in a position where we can crate that stuff with ffi?

MALodder (Thu, 21 Feb 2019 17:16:25 GMT):
so I created a crate for dev purposes already

MALodder (Thu, 21 Feb 2019 17:16:37 GMT):
and we already expose the CL stuff with an FFI

MALodder (Thu, 21 Feb 2019 17:16:47 GMT):
I'm working writing documentation for all of this

MALodder (Thu, 21 Feb 2019 17:17:08 GMT):
the decision yesterday was to create a separate repo for that documention `ursa-docs`

MALodder (Thu, 21 Feb 2019 17:17:24 GMT):
@hartm was looking into getting that started

MALodder (Thu, 21 Feb 2019 17:17:36 GMT):
I believe we can start doing that for fabric

david.b.crypto (Thu, 21 Feb 2019 19:08:31 GMT):
thanks mike the documentation will be useful if you want to tag team on writing it, wed can do that too..

hartm (Thu, 21 Feb 2019 20:15:00 GMT):
I just sent out the emal about the docs.

nanspro (Fri, 22 Feb 2019 06:30:03 GMT):
Has left the channel.

twshelton (Fri, 22 Feb 2019 17:13:50 GMT):
Has joined the channel.

runiner (Fri, 22 Feb 2019 17:13:58 GMT):
Has joined the channel.

lovesh (Sat, 23 Feb 2019 20:53:46 GMT):
Using Bulletproofs (dalek's implementation) to create zero knowledge proofs for arithematic statements. https://medium.com/@loveshharchandani/zero-knowledge-proofs-using-bulletproofs-4a8e2579fc82

lovesh (Sat, 23 Feb 2019 20:53:46 GMT):
Using Bulletproofs (dalek's implementation) to create zero knowledge proofs for arithematic statements. https://medium.com/coinmonks/zero-knowledge-proofs-using-bulletproofs-4a8e2579fc82

mike_texnik (Mon, 25 Feb 2019 11:41:48 GMT):
Has joined the channel.

MALodder (Tue, 26 Feb 2019 03:53:44 GMT):
@JonGeater Sovrin has investigated decentralized revocation registries or policies controlled by the user to essentially allow a user to authorize and revoke devices under their control and prove authorization in zero-knowledge. A policy is created by a user, the only information on the ledger in the policy is authorized public keys for various permissions. E.g. a user puts in three keys, one for each device perse uses, a laptop, a phone, and a tablet. When user presents ZKPs for anonymous credentials, perse also presents a proof that the device itself is authorized. Which policy is used is not revealed (which be correlatable if it was). When a device is lost or compromised, the user can revoke the bad device which halts an attacker from presenting valid proofs. The user can modify the policy to allow various permissions like 2 out of 3 devices are needed to add a new device but 1 out of 3 to revoke. This makes it harder for an attacker who manages to take over a device thru brute force or coercion to authorize his own new devices into the domain. Could this concept be applied to decentralize hardware based attestations by manufacturers? Basically we can have CRLs on the ledger and do proofs in zero knowledge. We talked about the need for decentralization in this area on the last Sovrin call. We plan to discuss this further on the Sovrin crypto call tomorrow https://zoom.us/j/567114224 at 8AM MST.

MALodder (Tue, 26 Feb 2019 03:54:43 GMT):
Anyone can attend the Sovrin Crypto Call

MALodder (Tue, 26 Feb 2019 03:55:01 GMT):
Look forward to seeing attendees tomorrow

MALodder (Tue, 26 Feb 2019 04:25:00 GMT):
Maybe we can use these in ursa: https://github.com/RustCrypto/traits

david.b.crypto (Tue, 26 Feb 2019 15:17:54 GMT):
has the sovrin crypto call been placed on a public calendar or can someone just forward me an invite?

nage (Tue, 26 Feb 2019 15:24:14 GMT):
@MALodder ^^^

nage (Tue, 26 Feb 2019 15:24:33 GMT):
It is going on now here https://zoom.us/j/567114224

hartm (Tue, 26 Feb 2019 15:24:39 GMT):
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/567114224

MALodder (Tue, 26 Feb 2019 15:29:13 GMT):
@david.b.crypto yes its on the hyperledger public calendar

david.b.crypto (Tue, 26 Feb 2019 15:38:15 GMT):
thanks

david.b.crypto (Tue, 26 Feb 2019 15:38:28 GMT):
im in another call, cant join

satelander (Tue, 26 Feb 2019 18:42:05 GMT):
Has joined the channel.

callahan (Thu, 28 Feb 2019 16:33:16 GMT):
Has joined the channel.

mike_texnik (Tue, 05 Mar 2019 15:20:12 GMT):
@MALodder sorry for botherting you, but is it possible to access the paper which is being discussed in the meeting? or this paper is not avaibale for everyone until it is publised

cam-parra (Tue, 05 Mar 2019 15:21:39 GMT):

AnonCreds2.pdf

cam-parra (Tue, 05 Mar 2019 15:21:44 GMT):
@mike_texnik

mike_texnik (Tue, 05 Mar 2019 15:22:03 GMT):
thank you very much!

MALodder (Wed, 06 Mar 2019 02:49:57 GMT):
Not much detail about it but it appears similar to Salsa20 at first glance https://cnnic.com.cn/ScientificResearch/LeadingEdge/soea/zuc/201312/t20131204_43352.htm

MALodder (Wed, 06 Mar 2019 02:50:48 GMT):
Ha never mind https://www.gsma.com/aboutus/wp-content/uploads/2014/12/eea3eia3zucv16.pdf

MALodder (Wed, 06 Mar 2019 02:50:55 GMT):
Doesn't look that great

hartm (Wed, 06 Mar 2019 04:29:34 GMT):
@here Just a reminder of tomorrow's meeting. Hope to talk to many of you tomorrow. Thanks!

hartm (Wed, 06 Mar 2019 15:00:21 GMT):
Meeting notes: https://docs.google.com/document/d/1Z_8o8k_PFRM4XfZyv9jH1_-IyN0CsCMI2JlrGsCX378/edit?usp=sharing

hartm (Wed, 06 Mar 2019 15:11:47 GMT):
https://wiki.hyperledger.org/pages/viewpage.action?pageId=6426712

edmundto (Thu, 07 Mar 2019 05:17:55 GMT):
Has joined the channel.

MALodder (Thu, 07 Mar 2019 05:44:20 GMT):

signal-2019-03-07-134159.jpeg

MALodder (Thu, 07 Mar 2019 05:45:01 GMT):
At hyperledger boot camp in Hong Kong

Thunder_xd (Thu, 07 Mar 2019 05:55:42 GMT):
Has joined the channel.

hartm (Thu, 07 Mar 2019 08:44:02 GMT):
Nice!

qylixin (Fri, 08 Mar 2019 01:19:57 GMT):
Has joined the channel.

JonGeater (Fri, 08 Mar 2019 03:32:05 GMT):
Is he talking about libzmix goats? Do we need another animal logo?

rbole (Fri, 08 Mar 2019 05:52:22 GMT):
Has joined the channel.

MALodder (Fri, 08 Mar 2019 15:03:42 GMT):
I prefer sheep dogs

MALodder (Mon, 11 Mar 2019 21:06:25 GMT):
@JonGeater Are you planning to attend the Sovrin Crypto tomorrow? I wanted to discuss the possibility of using Sovrin as a DPKI for hardware and TEE attestations and what would be required for that

JonGeater (Mon, 11 Mar 2019 21:16:28 GMT):
Yes

JonGeater (Mon, 11 Mar 2019 21:16:46 GMT):
Wait...depends. We're on a weird timezone week aren't we?

JonGeater (Mon, 11 Mar 2019 21:17:55 GMT):
Is it still 07:00 Pacific?

JonGeater (Mon, 11 Mar 2019 21:18:09 GMT):
If so I can do the first half hour: that'll be 14:00-14:30 for me this week

JonGeater (Mon, 11 Mar 2019 21:18:37 GMT):
I'm speaking at the Cloud and Cybersecurity Summit at 15:00 UK time

hartm (Mon, 11 Mar 2019 21:18:40 GMT):
@JonGeater It's still 7:00 AM Pacific, but note the daylight savings time change.

JonGeater (Mon, 11 Mar 2019 21:18:53 GMT):
Yes perfect. That oplays in our favour this time

JonGeater (Mon, 11 Mar 2019 21:20:45 GMT):
I can do 14:00-14:30. Question, to let it sit in my mind for a bit: do you mean specifically GlobalPlatform TEE (meaning complying with GP specs for attestation, TSM and so on) or just generally attesting to some abstractly understood Root of Trust for a general secure enclave?

MALodder (Mon, 11 Mar 2019 21:44:14 GMT):
Well the problem as you stated was central authorities for enclave quotes

MALodder (Mon, 11 Mar 2019 21:44:54 GMT):
could Sovrin be the DPKI for attestations, meaning instead of Intel having control over EPID, they could put it on Sovrin and then its decentralized

MALodder (Mon, 11 Mar 2019 21:46:29 GMT):
@JonGeater Okay, I'll schedule the first part of the meeting to cover the TEE and HSM stuff

MALodder (Mon, 11 Mar 2019 21:46:38 GMT):
that way if you need to leave you can

richzhao (Tue, 12 Mar 2019 02:52:49 GMT):
when will be the next group meeting?

JonGeater (Tue, 12 Mar 2019 10:37:20 GMT):
Right. So yes we can define a model for that for people to sign up to. Many won't want to as extracting a toll fee (or 'prime real estate' in the MNO world) is core to their business model. But some will, and I think it's a good thing for us to do

MALodder (Tue, 12 Mar 2019 13:54:57 GMT):
@richzhao next ursa meeting is wednesday march 20th at 7AM PDT

JonGeater (Tue, 12 Mar 2019 14:10:54 GMT):
While I switch out my network connection, you're onto a good thing with the credential profile. Almost all TEE use cases end up just being a way of securing a cryptographic ID for end-to-end protocols

david.b.crypto (Wed, 13 Mar 2019 15:15:27 GMT):
hi hartman

leixianting (Thu, 14 Mar 2019 02:11:54 GMT):
Has joined the channel.

wip-abramson (Thu, 14 Mar 2019 10:54:33 GMT):
Hey, I missed the last couple of Sovrin calls and noticed on the agenda you have been discussing delegatable credentials. I have heard of multiple ways to do with and have recently been reading https://acmccs.github.io/papers/p683-camenischA.pdf. Is this something sovrin are considering implementing? And can anyone point me to any other literature around delegating credentials, especially around and different approaches to it. Thanks :)

wip-abramson (Thu, 14 Mar 2019 10:57:47 GMT):
In this paper it mentions the ability to sign transactions with a delegated credential. So would it also be possible to issue further credentials using a delegated credential to create the signature?

lovesh (Thu, 14 Mar 2019 12:09:17 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=GbvnPrBeHSyKouuz8) @wip-abramson That paper the is best i have seen on delegatable credentials. Our current and the upcoming signature scheme will not be compatible with the scheme mentioned in this paper. We have been considering using a generic proving system like using SNARKs or Bulletproofs (Arithematic circuits), there is no paper about this approach yet.

lovesh (Thu, 14 Mar 2019 12:15:39 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=B6dY5mgiHMnD9xvyu) @wip-abramson Yes.

wip-abramson (Thu, 14 Mar 2019 14:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=hCpyjwJkK7M4MvfrK) @lovesh Thanks @lovesh, I am not sure I understand how this type of signing works. Do you know any good resources on this?

MALodder (Thu, 14 Mar 2019 15:43:40 GMT):
I have written an new RFC for language bindings See https://github.com/hyperledger/ursa-rfcs/pull/8

lovesh (Thu, 14 Mar 2019 17:29:26 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=ZHNCRevpqdHmPcgYK) @wip-abramson The paper explains the schemes in section 2.4 and 2.5. It describes the implementation too using pairings.

wip-abramson (Thu, 14 Mar 2019 18:28:21 GMT):
Ah okay, must be my lack of understanding. Will re read. Thanks @lovesh!

MALodder (Thu, 14 Mar 2019 18:41:43 GMT):
New PR that removes libsodium dependency and makes hashing and signatures more generic

MALodder (Thu, 14 Mar 2019 18:41:45 GMT):
https://github.com/hyperledger/ursa/pull/17

MALodder (Thu, 14 Mar 2019 18:42:52 GMT):
@lovesh @amundson @dhuseby Can you please review both my PRs? the wasm one has sat there for a month with no review

amundson (Thu, 14 Mar 2019 21:23:16 GMT):
@MALodder I'll try to do reviews tomorrow

MALodder (Thu, 14 Mar 2019 21:29:32 GMT):
@amundson thank you

dhuseby (Fri, 15 Mar 2019 19:40:12 GMT):
@MALodder we don't like you ; )

dhuseby (Fri, 15 Mar 2019 19:40:24 GMT):
let me see what I can get done this weekend.

dhuseby (Fri, 15 Mar 2019 19:40:32 GMT):
currently working the internship and Iroha stuff

dhuseby (Fri, 15 Mar 2019 19:40:37 GMT):
(higher priority ATM)

dhuseby (Fri, 15 Mar 2019 21:18:58 GMT):
@here should we be sending somebody from Ursa to the zkproof.org meeting in a few weeks?

MALodder (Fri, 15 Mar 2019 21:19:12 GMT):
I'm going

danintel (Fri, 15 Mar 2019 22:41:57 GMT):
I created a Ursa microbenchmark for SHA-512 and SHA-256 here https://github.com/danintel/ursaspeed For SHA-512 and 16Kbyte buffers, I improved ursa performance 173x running on my laptop by using crate ring (which uses Google's BoringSSL, a OpenSSL fork, written in C and assembly). So I am wondering, is performance an important issue? Or is Ursa just for experimentation with new crypto algorithms? I can easily create a PR with a fix, unless the end goal is Rust-only code with no C/assembly. I can add this to the next meeting agenda to discuss, unless the answer is already known.

hartm (Fri, 15 Mar 2019 23:42:37 GMT):
@danintel Nice! It would be fantastic if you could talk about this in the next meeting (this coming week).

danintel (Fri, 15 Mar 2019 23:43:59 GMT):
ok

danielhardman (Sat, 16 Mar 2019 15:57:06 GMT):
My vote is that performance *does* matter, and that Ursa is NOT just for experimentation. So I'd love to see a PR.

VipinB (Sat, 16 Mar 2019 17:05:51 GMT):
I will also be at zkproof.org meeting @MALodder @dhuseby

VipinB (Sat, 16 Mar 2019 17:07:45 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=6oWweMtWbMwchMhnw) +1

MALodder (Sun, 17 Mar 2019 20:54:45 GMT):
Performance matters but we shouldn’t just say pick items based on speed. Rusts SHA2 crate is quite fast as well and unless there is a specific reason why someone needs the bleeding edge I don’t want to always say yes.

MALodder (Sun, 17 Mar 2019 20:55:46 GMT):
We can work together to create awesome stuff for ursa

MALodder (Sun, 17 Mar 2019 20:57:10 GMT):
@danintel what libraries were you comparing and where you comparing release mode? I’ve tested raw rust to C code and found if you compare debug mode there is quite a gap of 173x

MALodder (Sun, 17 Mar 2019 20:57:32 GMT):
But if I run it in release mode there isn’t much of a difference

MALodder (Sun, 17 Mar 2019 20:57:47 GMT):
Usually I find rust is just as fast or faster

MALodder (Mon, 18 Mar 2019 13:24:03 GMT):
Can I PLEASE get some reviews for my two PRs? one of them has been there for more than a month. These are the two PRs needed so Indy can adopt URSA.

cam-parra (Mon, 18 Mar 2019 14:11:36 GMT):
@MALodder and @dhuseby If I can get write access I'd love to review these PRs

MALodder (Mon, 18 Mar 2019 14:12:33 GMT):
@cam-parra I can't add you as a maintainer, that has to be done by HL

cam-parra (Mon, 18 Mar 2019 14:16:03 GMT):
I believe @dhuseby or @rjones can send in a request ticket

rjones (Mon, 18 Mar 2019 14:16:04 GMT):
Has joined the channel.

nage (Mon, 18 Mar 2019 15:53:51 GMT):
Each project should have a proceedure for adding maintainers. In Indy we let the current code-base maintainers propose a new maintainer, and then I gather feedback from the rest of the maintainers (usually on the indy maintainers call) and if I don't get any "no" votes from the rest of the group we move forward to propose the addition. We haven't yet had a proposed maintainer move forward with opposition (a couple have chosen to wait a few weeks and moved forward later), but the next steps would match other groups where we would have more official vote considering commit history and PR review engagement and ability to play well with others. I'm not sure what Ursa wants to do, but I think it is very healthy to engage everyone who can put in the needed care and time.

cam-parra (Mon, 18 Mar 2019 15:58:14 GMT):
@nage with @dhuseby I believe the project decided that URSA is a do-ocracy. Meaning if you're willing and wanting and have submitted work you're a valid candidate

danintel (Mon, 18 Mar 2019 15:58:39 GMT):
Here's my microbenchmark performance numbers of various Rust crates running on my laptop: ```time: 2019-03-18 15:14:07.488016600 UTC os: Ubuntu 18.04 rustc: 1.33.0 (stable channel) hostname: daniela1-MOBL The 'numbers' are in 1000s of bytes per second processed. type/crate 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256/ring 5403.07k 20306.62k 67330.56k 164506.28k 278489.77k 283820.03k sha512/ring 5403.19k 21662.40k 69323.95k 191211.86k 381479.59k 410107.90k sha256/openssl 4683.83k 17647.34k 61666.30k 162087.94k 289846.61k 320012.29k sha512/openssl 4134.21k 17739.39k 62442.58k 185346.39k 427251.03k 467473.75k sha256/sha2 2283.65k 4439.68k 7156.31k 8349.01k 8852.82k 8844.41k sha512/sha2 1492.82k 5982.36k 9558.19k 13729.45k 15597.57k 15919.79k amcl/sha256 2288.11k 2815.70k 3507.03k 3488.43k 3899.39k 3939.14k amcl/sha512 2261.30k 6433.49k 4713.05k 5132.29k 5294.76k 5324.80k hashlib/sha256 2225.40k 4367.32k 6882.22k 8351.74k 8904.70k 8852.82k hashlib/sha512 1485.79k 5987.56k 9579.52k 13730.47k 15816.02k 15821.48k ursa/sha256 624.40k 1507.56k 2818.30k 3558.06k 3827.12k 3899.39k ursa/sha512 494.18k 1825.28k 3110.91k 4490.24k 5099.19k 5264.73k ```

danintel (Mon, 18 Mar 2019 15:58:39 GMT):
Here's my microbenchmark performance numbers of various Rust crates running on my laptop: ```time: 2019-03-18 15:14:07.488016600 UTC os: Ubuntu 18.04 rustc: 1.33.0 (stable channel) hostname: daniela1-MOBL The 'numbers' are in 1000s of bytes per second processed. type/crate 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256/ring 5403.07k 20306.62k 67330.56k 164506.28k 278489.77k 283820.03k sha512/ring 5403.19k 21662.40k 69323.95k 191211.86k 381479.59k 410107.90k openssl/sha256 4683.83k 17647.34k 61666.30k 162087.94k 289846.61k 320012.29k openssl/sha512 4134.21k 17739.39k 62442.58k 185346.39k 427251.03k 467473.75k sha256/sha2 2283.65k 4439.68k 7156.31k 8349.01k 8852.82k 8844.41k sha512/sha2 1492.82k 5982.36k 9558.19k 13729.45k 15597.57k 15919.79k amcl/sha256 2288.11k 2815.70k 3507.03k 3488.43k 3899.39k 3939.14k amcl/sha512 2261.30k 6433.49k 4713.05k 5132.29k 5294.76k 5324.80k hashlib/sha256 2225.40k 4367.32k 6882.22k 8351.74k 8904.70k 8852.82k hashlib/sha512 1485.79k 5987.56k 9579.52k 13730.47k 15816.02k 15821.48k ursa/sha256 624.40k 1507.56k 2818.30k 3558.06k 3827.12k 3899.39k ursa/sha512 494.18k 1825.28k 3110.91k 4490.24k 5099.19k 5264.73k ```

jsmitchell (Mon, 18 Mar 2019 16:13:05 GMT):
@danintel have you looked into `cargo bench`?

danintel (Mon, 18 Mar 2019 16:15:50 GMT):
No--I'll look at it. I wanted something directly comparable to openssl microbenchmarks.

MALodder (Mon, 18 Mar 2019 16:24:31 GMT):
I don’t understand the numbers here because ursa/sha256 is using amcl/sha256

MALodder (Mon, 18 Mar 2019 16:24:40 GMT):
Something is not adding up

lovesh (Mon, 18 Mar 2019 20:00:37 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=hMEwErBYmcDXz6DKx) @MALodder Approved one of your PRs. There are comments about zeroing out memory for some variables

MALodder (Mon, 18 Mar 2019 20:07:37 GMT):
okay, I need the WASM one approved too

dhuseby (Mon, 18 Mar 2019 23:32:08 GMT):
@danintel are those sha512 numbers the full sha512 or one of the truncated sha512's?

danintel (Mon, 18 Mar 2019 23:33:00 GMT):
It is full sha512.

danintel (Mon, 18 Mar 2019 23:35:00 GMT):
I don't see why a truncated sha512 should be different. The truncated digests have a different IVs and the result is shorter, but the stuff in-between is the same.

deepikav (Tue, 19 Mar 2019 01:30:37 GMT):
zoomzkproof

lovesh (Tue, 19 Mar 2019 08:13:23 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=9CyFiFJHjdRDhxnRk) @MALodder Some comments there but approved.

nage (Tue, 19 Mar 2019 17:06:04 GMT):
@dhuseby and @amundson any update on reviews for @MALodder's PRs? It would be good to get some more reviewers to help avoid week-long delays.

nage (Tue, 19 Mar 2019 17:06:52 GMT):
(and yes, I do volunteer if you need me)

amundson (Tue, 19 Mar 2019 18:51:12 GMT):
I'm not sure what standard we are holding this code to. Should I be putting a red X on it because of things like commented-out code? (I would 100% do that on sawtooth or grid repos.) The commit history in the PR has merge commits - that's also not allowed in sawtooth or grid because it implies the commits are not well-formed for review. And in matter fo fact, reviewing the wasm one per-commit doesn't seem productive for that reason. (In the other projects, we rebase upon master if we are updating the PR and force-push).

amundson (Tue, 19 Mar 2019 18:52:20 GMT):
I guess this is mostly a question to @MALodder about the desired style of review.

amundson (Tue, 19 Mar 2019 18:54:14 GMT):
I approved them as-is because it's would be ridiculous to come in so late with anything else.

MALodder (Tue, 19 Mar 2019 18:56:53 GMT):
normally, I prefer smaller reviews but we can't reject PRs because they have merge commits because those commits have sat for a while and other PRs have been merged.

MALodder (Tue, 19 Mar 2019 18:58:52 GMT):
I'm not seeing the commented out code you are referring to

MALodder (Tue, 19 Mar 2019 18:59:56 GMT):
what would you prefer @amundson ?

amundson (Tue, 19 Mar 2019 19:03:50 GMT):
the alternative to merge commit is rebase+force-push to the PR branch. the duration of the PR being open doesn't matter. (I agree though, that they shouldn't sit as long as these did, its just a different problem.)

amundson (Tue, 19 Mar 2019 19:05:43 GMT):
the commented-out code is on the wasm one

amundson (Tue, 19 Mar 2019 19:12:01 GMT):
so, for example, the wasm PR needs rebase or merge. in Sawtooth or Grid, we would require it to be rebased to resolve the conflict. either solution technically works to make the PR mergable.

rjones (Tue, 19 Mar 2019 19:43:26 GMT):
@cam-parra Ursa team maintainers can add you directly, without a ticket.

rjones (Tue, 19 Mar 2019 19:44:08 GMT):
@cam-parra since you're already part of ursa-maintainers, you should be able to review/merge code

rjones (Tue, 19 Mar 2019 19:44:08 GMT):
@cam-parra since you

rjones (Tue, 19 Mar 2019 19:45:19 GMT):
@amundson I could look to see if your repos have the rebase-and-merge option enabled. Personally, I prefer rebased merges b/c I'm allergic to merge commits

rjones (Tue, 19 Mar 2019 19:46:15 GMT):
@MALodder it does look like there are merge conflicts, though: https://github.com/hyperledger/ursa/pull/14

amundson (Tue, 19 Mar 2019 20:22:02 GMT):
@rjones we do all the rebasing manually (for Sawtooth and Grid) because part of our review is how well formed the commit messages are, and so we keep that option off within github

amundson (Tue, 19 Mar 2019 20:22:31 GMT):
nearly all the merge commits thus end up being caused by github

MALodder (Tue, 19 Mar 2019 21:42:38 GMT):
So you prefer for me to do a git fetch and then re-base onto the current branch? Instead of having GitHub do the merge?

MALodder (Tue, 19 Mar 2019 21:43:15 GMT):
I’m open to any option that works and doesn’t get in the way if that’s what people preferred to do I’m fine with it

rjones (Tue, 19 Mar 2019 22:07:56 GMT):
@MALodder given the merge conflicts, github can't do the merge. If I'm looking at the right PR

rjones (Tue, 19 Mar 2019 22:09:05 GMT):
```This branch has conflicts that must be resolved Use the web editor or the to resolve conflicts. Conflicting files libursa/Cargo.toml libursa/src/hash/mod.rs libursa/src/lib.rs libursa/src/signatures/ed25519.rs libursa/src/signatures/secp256k1.rs ```

MALodder (Tue, 19 Mar 2019 22:41:24 GMT):
It’s not the branch that’s the issue at hand it’s a matter of procedure

flyerwing (Wed, 20 Mar 2019 02:41:06 GMT):
Has joined the channel.

kdenhartog (Wed, 20 Mar 2019 03:19:19 GMT):
Are people aware of the new implementations from MSFT in Homomorphic encryption? https://github.com/Microsoft/SEAL

kdenhartog (Wed, 20 Mar 2019 03:29:43 GMT):
https://git.njit.edu/palisade/PALISADE/tree/master

kdenhartog (Wed, 20 Mar 2019 03:29:46 GMT):
Also relevant

tplooker (Wed, 20 Mar 2019 03:41:46 GMT):
Has joined the channel.

hartm (Wed, 20 Mar 2019 06:24:31 GMT):
@here Just a reminder of tomorrow's Ursa meeting. Please add your agenda items to the agenda (on the wiki) if there's anything in particular you'd like to discuss. Thanks!

hartm (Wed, 20 Mar 2019 14:02:12 GMT):
Meeting notes: https://wiki.hyperledger.org/pages/viewpage.action?pageId=6427832

JonGeater (Wed, 20 Mar 2019 14:18:49 GMT):
Can't make it today unfortunately

cam-parra (Wed, 20 Mar 2019 14:30:50 GMT):
@MALodder it looks like I haven't been given access right yet. But as @rjones stated I believe you or @hartm can add me

hartm (Wed, 20 Mar 2019 14:31:45 GMT):
@cam-parra I don't believe I can add you. I think it has to be someone from the LF.

brockhager (Wed, 20 Mar 2019 15:03:03 GMT):
Has joined the channel.

danintel (Wed, 20 Mar 2019 15:29:00 GMT):
FYI I'm not in the core developers group, but I can still make PRs and I have done reviews and comments. It just results in a gray checkmark instead of a green checkmark, but that is relevant only when automated CI is enabled.

MALodder (Wed, 20 Mar 2019 15:33:18 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=MJXEozR3SXAdtqJQ2) @kdenhartog Looks simple, it just allows addition/subtraction and multiply on integers using BFV and CKKS for floating point

MALodder (Wed, 20 Mar 2019 15:33:31 GMT):
Not sure we would use it for ursa yet

MALodder (Wed, 20 Mar 2019 15:34:06 GMT):
I'm not familiar with how those work but CKKS seems like its newer. I'd like to hear thoughts from the cryptographers on it

rjones (Wed, 20 Mar 2019 18:35:02 GMT):
@cam-parra you around?

rjones (Wed, 20 Mar 2019 18:35:29 GMT):
@hartm around?

rjones (Wed, 20 Mar 2019 18:39:12 GMT):
@MALodder @hartm I have promoted both of you to team maintainers, as well as Shawn, for the Ursa Maintainers team:

rjones (Wed, 20 Mar 2019 18:39:15 GMT):
https://github.com/orgs/hyperledger/teams/ursa-maintainers/members

rjones (Wed, 20 Mar 2019 18:39:31 GMT):
this team has write access to three repos: https://github.com/orgs/hyperledger/teams/ursa-maintainers/repositories

MALodder (Wed, 20 Mar 2019 18:40:03 GMT):
awesome

rjones (Wed, 20 Mar 2019 18:40:08 GMT):
Since @cam-parra is already a member of Hyperledger: https://github.com/orgs/hyperledger/people/cam-parra

rjones (Wed, 20 Mar 2019 18:40:18 GMT):
you can add him without any say-so.

MALodder (Wed, 20 Mar 2019 18:40:19 GMT):
@rjones what's the best way to add webhooks for projects?

MALodder (Wed, 20 Mar 2019 18:40:26 GMT):
@rjones sounds good thanks

rjones (Wed, 20 Mar 2019 18:40:44 GMT):
The bit that you need LFIT to do is if someone is _not_ in the Hyperledger org.

rjones (Wed, 20 Mar 2019 18:41:16 GMT):
@MALodder helpdesk@hyperledger.org is how to add webhooks

cam-parra (Wed, 20 Mar 2019 19:47:34 GMT):
@rjones Sorry about that I was on my lunch break. But it looks like @MALodder has taken care of adding me! Thanks guys!

MALodder (Wed, 20 Mar 2019 19:59:42 GMT):
@cam-parra you are a maintainer on ursa

MALodder (Wed, 20 Mar 2019 19:59:53 GMT):
try doing something that requires write access

kdenhartog (Wed, 20 Mar 2019 20:42:50 GMT):
A fork of PALISADE built by duality.cloud evidently performed an operation on genomic data in .09 minutes using between 1 and 2 GB of ram. So my thinking is FHE is becoming more practical.

rjones (Wed, 20 Mar 2019 23:33:47 GMT):
there. 2/3 of the existing URSA bugs are mine

MALodder (Thu, 21 Mar 2019 00:02:11 GMT):
@rjones what do you mean by bugs?

MALodder (Thu, 21 Mar 2019 04:01:46 GMT):
Here is a link to the CI pipeline and the results that I used to run ursa through https://gitlab.sovrin.org/sovrin-foundation/ursa/pipelines/2

niteshsolanki (Thu, 21 Mar 2019 04:43:36 GMT):
Has joined the channel.

david.b.crypto (Thu, 21 Mar 2019 16:23:07 GMT):
very nice...

MALodder (Thu, 21 Mar 2019 17:45:29 GMT):
@amundson @dhuseby I sent you an invite to be an author for the ursa crate

MALodder (Thu, 21 Mar 2019 17:49:10 GMT):
be sure to accept those invites

rjones (Thu, 21 Mar 2019 18:13:01 GMT):
Has left the channel.

MALodder (Thu, 21 Mar 2019 23:43:32 GMT):
Ursa 0.1.0 has been released as a rust crate

MALodder (Thu, 21 Mar 2019 23:44:16 GMT):
https://crates.io/crates/ursa

danintel (Thu, 21 Mar 2019 23:46:34 GMT):
I looked and I built my copy of ursa using `cargo build --release` as instructed in the github README.md file. The numbers above (March 18 in my TZ) are using that build. If there's any other optimization suggestions for rust let me know.

lovesh (Fri, 22 Mar 2019 11:21:08 GMT):
@danintel FWI. Ursa code has changed so your benchmarks in the repo https://github.com/danintel/ursaspeed don't work with latest Ursa. They work with Ursa commit d7ac9e92d4f76cd2b68c974031e4e894200dc4bf so you need to checkout that commit and then run your benchmark. On the topic of why Ursa is so slow, there is a *problem with your benchmark from what i can see*. You are omitting steps in your benchmark with some other libs from what i can see. Consider your `sha256_sha2` function in main.rs in your repo, it does `h.input(&data[..byte_len]);` which means accept the input but it missing the step to compute the digest so *the hash is never computed*, you need to call `h.result()` for that. Same for `sha256_ring`, it does `h.update(&data[..byte_len])` but not `h.finish()`. The same problem here, your function accepts input but *does not compute the digest*. Similarly for `sha256_amcl`, you call `h.process_array(&data[..byte_len])` but not `h.hash()` which is needed to compute the digest. I did not check other functions. I would suggest to make these changes and then compare

lovesh (Fri, 22 Mar 2019 11:21:08 GMT):
@danintel FWI. Ursa code has changed so your benchmarks in the repo https://github.com/danintel/ursaspeed don't work with latest Ursa. They work with Ursa commit d7ac9e92d4f76cd2b68c974031e4e894200dc4bf so you need to checkout that commit and then run your benchmark. On the topic of why Ursa is so slow, there is a *problem with your benchmark from what i can see*. You are *omitting steps in your benchmark* with some other libs from what i can see. Consider your `sha256_sha2` function in main.rs in your repo, it does `h.input(&data[..byte_len]);` which means accept the input but it missing the step to compute the digest so *the hash is never computed*, you need to call `h.result()` for that. Same for `sha256_ring`, it does `h.update(&data[..byte_len])` but not `h.finish()`. The same problem here, your function accepts input but *does not compute the digest*. Similarly for `sha256_amcl`, you call `h.process_array(&data[..byte_len])` but not `h.hash()` which is needed to compute the digest. I did not check other functions. I would suggest to make these changes and then compare

lovesh (Fri, 22 Mar 2019 11:21:08 GMT):
@danintel FWI. Ursa code has changed so your benchmarks in the repo https://github.com/danintel/ursaspeed don't work with latest Ursa. They work with Ursa commit d7ac9e92d4f76cd2b68c974031e4e894200dc4bf so you need to checkout that commit and then run your benchmark. On the topic of why Ursa is so slow, there is a *problem with your benchmark from what i can see*. You are *omitting steps in your benchmark* with some other libs from what i can see. Consider your `sha256_sha2` function in main.rs in your repo, it does `h.input(&data[..byte_len]);` which means accept the input but its missing the step to compute the digest so *the hash is never computed*, you need to call `h.result()` for that. Same for `sha256_ring`, it does `h.update(&data[..byte_len])` but not `h.finish()`. The same problem here, your function accepts input but *does not compute the digest*. Similarly for `sha256_amcl`, you call `h.process_array(&data[..byte_len])` but not `h.hash()` which is needed to compute the digest. I did not check other functions. I would suggest to make these changes and then compare

lovesh (Fri, 22 Mar 2019 11:21:08 GMT):
@danintel FWI. Ursa code has changed so your benchmarks in the repo https://github.com/danintel/ursaspeed don't work with latest Ursa. They work with Ursa commit d7ac9e92d4f76cd2b68c974031e4e894200dc4bf so you need to checkout that commit and then run your benchmark. On the topic of why Ursa is so slow, there is a *problem with your benchmark from what i can see*. You are *omitting steps in your benchmark* with some other libs from what i can see. Consider your `sha256_sha2` function in main.rs in your repo, it does `h.input(&data[..byte_len]);` which means accept the input but its missing the step to compute the digest so *the hash is never computed*, you need to call `h.result()` for that. Same for `sha256_ring`, it does `h.update(&data[..byte_len])` but not `h.finish()`. The same problem here, your function accepts input but *does not compute the digest*. Similarly for `sha256_amcl`, you call `h.process_array(&data[..byte_len])` but not `h.hash()` which is needed to compute the digest. I would suggest to make these changes and then compare.

lovesh (Fri, 22 Mar 2019 11:41:29 GMT):
After the above mentioned fixes, i get these results ``` ```

lovesh (Fri, 22 Mar 2019 11:41:29 GMT):
After the above mentioned fixes, i get these results ``` type/crate 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256/ring 6480.78k 22624.92k 73405.18k 168008.36k 354885.63k 378066.26k sha512/ring 4161.88k 21209.98k 54757.03k 170201.77k 437086.89k 500012.37k sha256/openssl 8704.32k 32436.10k 103324.42k 210012.50k 361155.24k 417229.48k sha512/openssl 8395.29k 33503.38k 97857.79k 277687.64k 523638.10k 543484.59k sha256/sha2 1203.82k 3367.94k 7134.29k 9655.64k 10985.47k 11026.43k sha512/sha2 866.86k 3362.37k 8032.26k 14897.49k 18429.27k 19557.03k sha256/amcl 833.83k 1743.96k 3022.34k 3599.70k 3672.75k 4277.41k sha512/amcl 536.68k 1790.55k 3043.84k 5088.26k 5884.59k 5612.38k sha256/hashlib 1078.81k 3189.42k 6289.32k 9159.60k 9027.58k 10584.06k sha512/hashlib 871.42k 3047.79k 7736.41k 13400.41k 17795.75k 20032.17k sha256/ursa 786.53k 1876.07k 3289.26k 4079.96k 4658.52k 4331.97k sha512/ursa 602.50k 2218.77k 3805.10k 4895.74k 5593.27k 5703.29k ```

lovesh After the above mentioned ``` Debug mode type/crate 16 bytes sha256/ring 6480.78k sha512/ring 4161.88k sha256/openssl 8704.32k sha512/openssl 8395.29k sha256/sha2 1203.82k sha512/sha2 866.86k sha256/amcl 833.83k sha512/amcl 536.68k sha256/hashlib 1078.81k sha512/hashlib 871.42k sha256/ursa 786.53k sha512/ursa 602.50k Release mode type/crate 16 bytes sha256/ring 16940.28k sha512/ring 10964.95k sha256/openssl 10773.19k sha512/openssl 11045.92k sha256/sha2 9951.30k sha512/sha2 9606.74k sha256/amcl 11248.54k sha512/amcl 9770.41k sha256/hashlib 11982.72k sha512/hashlib 11360.44k sha256/ursa 11356.35k sha512/ursa 9689.17k ``` (Fri, 22 Mar 2019 11:41:29 GMT):
fixes, i get these results 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes 22624.92k 73405.18k 168008.36k 354885.63k 378066.26k 21209.98k 54757.03k 170201.77k 437086.89k 500012.37k 32436.10k 103324.42k 210012.50k 361155.24k 417229.48k 33503.38k 97857.79k 277687.64k 523638.10k 543484.59k 3367.94k 7134.29k 9655.64k 10985.47k 11026.43k 3362.37k 8032.26k 14897.49k 18429.27k 19557.03k 1743.96k 3022.34k 3599.70k 3672.75k 4277.41k 1790.55k 3043.84k 5088.26k 5884.59k 5612.38k 3189.42k 6289.32k 9159.60k 9027.58k 10584.06k 3047.79k 7736.41k 13400.41k 17795.75k 20032.17k 1876.07k 3289.26k 4079.96k 4658.52k 4331.97k 2218.77k 3805.10k 4895.74k 5593.27k 5703.29k 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes 58710.87k 165836.54k 293034.67k 386061.65k 362949.29k 51510.57k 148195.16k 257965.06k 433067.35k 350721.37k 37381.93k 122451.63k 270134.95k 362023.59k 361545.73k 42391.27k 132701.35k 319108.44k 547108.18k 511055.19k 32143.85k 80350.38k 138736.98k 173970.77k 176166.23k 43290.75k 114728.62k 223509.85k 313835.52k 318570.50k 31827.82k 77894.23k 121241.60k 140910.59k 137505.45k 40381.93k 85972.82k 148200.11k 185013.59k 190376.62k 38460.22k 92876.54k 151698.77k 183356.07k 180841.13k 45218.47k 113704.62k 198082.90k 288762.54k 271783.25k 32162.56k 78629.46k 115703.13k 130080.77k 136921.09k 43223.79k 88776.53k 144963.58k 198664.19k 201960.11k

lovesh (Fri, 22 Mar 2019 11:42:30 GMT):
Changes https://github.com/lovesh/ursaspeed/commit/4b75664f81e5b702599d1b695738ee36670413d4

lovesh (Fri, 22 Mar 2019 11:53:24 GMT):
After the above mentioned fixes, i get these results ``` Debug mode type/crate 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256/ring 6480.78k 22624.92k 73405.18k 168008.36k 354885.63k 378066.26k sha512/ring 4161.88k 21209.98k 54757.03k 170201.77k 437086.89k 500012.37k sha256/openssl 8704.32k 32436.10k 103324.42k 210012.50k 361155.24k 417229.48k sha512/openssl 8395.29k 33503.38k 97857.79k 277687.64k 523638.10k 543484.59k sha256/sha2 1203.82k 3367.94k 7134.29k 9655.64k 10985.47k 11026.43k sha512/sha2 866.86k 3362.37k 8032.26k 14897.49k 18429.27k 19557.03k sha256/amcl 833.83k 1743.96k 3022.34k 3599.70k 3672.75k 4277.41k sha512/amcl 536.68k 1790.55k 3043.84k 5088.26k 5884.59k 5612.38k sha256/hashlib 1078.81k 3189.42k 6289.32k 9159.60k 9027.58k 10584.06k sha512/hashlib 871.42k 3047.79k 7736.41k 13400.41k 17795.75k 20032.17k sha256/ursa 786.53k 1876.07k 3289.26k 4079.96k 4658.52k 4331.97k sha512/ursa 602.50k 2218.77k 3805.10k 4895.74k 5593.27k 5703.29k Release mode type/crate 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256/ring 16940.28k 58710.87k 165836.54k 293034.67k 386061.65k 362949.29k sha512/ring 10964.95k 51510.57k 148195.16k 257965.06k 433067.35k 350721.37k sha256/openssl 10773.19k 37381.93k 122451.63k 270134.95k 362023.59k 361545.73k sha512/openssl 11045.92k 42391.27k 132701.35k 319108.44k 547108.18k 511055.19k sha256/sha2 9951.30k 32143.85k 80350.38k 138736.98k 173970.77k 176166.23k sha512/sha2 9606.74k 43290.75k 114728.62k 223509.85k 313835.52k 318570.50k sha256/amcl 11248.54k 31827.82k 77894.23k 121241.60k 140910.59k 137505.45k sha512/amcl 9770.41k 40381.93k 85972.82k 148200.11k 185013.59k 190376.62k sha256/hashlib 11982.72k 38460.22k 92876.54k 151698.77k 183356.07k 180841.13k sha512/hashlib 11360.44k 45218.47k 113704.62k 198082.90k 288762.54k 271783.25k sha256/ursa 11356.35k 32162.56k 78629.46k 115703.13k 130080.77k 136921.09k sha512/ursa 9689.17k 43223.79k 88776.53k 144963.58k 198664.19k 201960.11k ```

MALodder (Fri, 22 Mar 2019 13:49:48 GMT):
What happens if you redo the test with the newly released her sick crate?

MALodder (Fri, 22 Mar 2019 13:49:48 GMT):
What happens if you redo the test with the newly released ursa crate?

lovesh (Fri, 22 Mar 2019 14:14:04 GMT):
Ursa API has changed as `digest` and `DigestAlgorithm` are no longer there so the benchmark code will not work

nage (Fri, 22 Mar 2019 14:58:50 GMT):
looks like her sick crate is the substitute for newly released ursa crate?

hartm (Fri, 22 Mar 2019 14:59:27 GMT):
@nage, haha, I was confused by that too.

MALodder (Fri, 22 Mar 2019 14:59:43 GMT):
autocorrect problems

MALodder (Fri, 22 Mar 2019 15:01:33 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=JaQuwPkxRbcLJ3FXf) @lovesh From what I can see its all of the other benchmarks including openssl. The only one actually hashing is ursa

MALodder (Fri, 22 Mar 2019 15:02:24 GMT):
Here's what I get when I fix it so all the other benchmarks are actually hashing AND using ursa v0.1 ``` sha256/ring 17313.03k 56066.01k 165082.37k 315636.74k 432908.97k 450494.46k sha512/ring 16341.88k 67587.56k 183288.23k 389507.41k 597797.55k 630177.79k sha256/openssl 13391.38k 46803.16k 138924.63k 282797.74k 417240.41k 431833.09k sha512/openssl 11972.57k 46821.33k 131259.82k 316226.22k 485690.03k 539858.26k sha256/sha2 13251.62k 45099.88k 114181.03k 187756.89k 241003.18k 245683.54k sha512/sha2 12560.65k 48158.27k 134296.75k 259143.68k 383117.99k 403390.46k sha256/amcl 12051.93k 39636.99k 88270.85k 141554.01k 171177.30k 174440.45k sha512/amcl 11758.99k 43109.16k 97264.55k 173623.64k 232306.01k 237775.53k sha256/hashlib 12906.95k 41143.25k 118983.51k 182531.41k 247302.83k 245186.56k sha512/hashlib 13465.79k 52570.18k 137019.39k 289247.23k 403879.25k 414313.13k sha256/ursa 13833.07k 45996.10k 106448.64k 191164.42k 244637.70k 251543.55k sha512/ursa 12413.11k 51946.15k 138451.97k 273639.77k 394452.99k 414558.89k ```

MALodder (Fri, 22 Mar 2019 15:02:24 GMT):
Here's what I get when I fix it so all the other benchmarks are actually hashing AND using ursa v0.1 ``` time: 2019-03-22 14:58:03.146650 UTC os: OSX 10.14.3 rustc: 1.35.0 (nightly channel) hostname: Michaels-MBP.localdomain The 'numbers' are in 1000s of bytes per second processed. type/crate 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256/ring 17313.03k 56066.01k 165082.37k 315636.74k 432908.97k 450494.46k sha512/ring 16341.88k 67587.56k 183288.23k 389507.41k 597797.55k 630177.79k sha256/openssl 13391.38k 46803.16k 138924.63k 282797.74k 417240.41k 431833.09k sha512/openssl 11972.57k 46821.33k 131259.82k 316226.22k 485690.03k 539858.26k sha256/sha2 13251.62k 45099.88k 114181.03k 187756.89k 241003.18k 245683.54k sha512/sha2 12560.65k 48158.27k 134296.75k 259143.68k 383117.99k 403390.46k sha256/amcl 12051.93k 39636.99k 88270.85k 141554.01k 171177.30k 174440.45k sha512/amcl 11758.99k 43109.16k 97264.55k 173623.64k 232306.01k 237775.53k sha256/hashlib 12906.95k 41143.25k 118983.51k 182531.41k 247302.83k 245186.56k sha512/hashlib 13465.79k 52570.18k 137019.39k 289247.23k 403879.25k 414313.13k sha256/ursa 13833.07k 45996.10k 106448.64k 191164.42k 244637.70k 251543.55k sha512/ursa 12413.11k 51946.15k 138451.97k 273639.77k 394452.99k 414558.89k ```

MALodder (Fri, 22 Mar 2019 15:06:57 GMT):
I don't know if hashing all `0`'s has anything to do with the benchmark either

lovesh (Fri, 22 Mar 2019 15:11:50 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=oCAQmynwhMNWWG9Dx) @MALodder Yes, none of them except ursa were hashing. The benchmarks i posted had all libs hashing.

danintel (Fri, 22 Mar 2019 16:23:33 GMT):
@lovesh I saw you added a finish (or equivalent step) for each digest. in a PR, which I merged. Thanks! I would like to try it again with the latest Ursa. But I see the API has completely changed, so I need to reverse engineer it again and discover the new API.

MALodder (Fri, 22 Mar 2019 16:27:02 GMT):
@danintel I can merge my changes to yours since I've already done it

MALodder (Fri, 22 Mar 2019 16:27:09 GMT):
I'll submit a PR shortly

JonGeater (Mon, 25 Mar 2019 12:02:30 GMT):
Marta and I just had a call with some folks from the crypto products team at Gemalto...trying to lure them in to the Ursa clan :-)

VipinB (Tue, 26 Mar 2019 12:11:02 GMT):
Thats great news as Gemalto and Finargo are the biggest players in the Enterprise Identity space

dhuseby (Wed, 27 Mar 2019 16:38:14 GMT):
@MALodder where did you send the crate author invite?

MALodder (Wed, 27 Mar 2019 17:22:35 GMT):
to your linux foundation email

wip-abramson (Thu, 28 Mar 2019 12:34:18 GMT):
Hi, I have a question about delegatable credentials. I think Brent asked during the call whether it would be possible to use DIDs instead of public keys, the answer was difficult to prove control of did anonymously. But how about the use of a DID for the issuer of a delegatable credential? They don't need to prove anonymous control of a key if I understand correctly. Would that be possible, if it would it seems ideal as when verifying presentations, you would be able to resolve DID to keys in usual way.

cam-parra (Thu, 28 Mar 2019 13:45:16 GMT):
@MALodder @dhuseby do we have a jira board for URSA? Link?

MALodder (Thu, 28 Mar 2019 13:45:31 GMT):
yes we do

MALodder (Thu, 28 Mar 2019 13:45:33 GMT):
hold on

MALodder (Thu, 28 Mar 2019 13:46:13 GMT):
https://jira.hyperledger.org/projects/URSA/issues/URSA-5?filter=allopenissues

cam-parra (Thu, 28 Mar 2019 14:18:00 GMT):
Thank you!

cam-parra (Thu, 28 Mar 2019 14:20:14 GMT):
@rjones it looks like URSA-5 on the jira board is complete. Could you take URSA-6?

rjones (Thu, 28 Mar 2019 14:20:15 GMT):
Has joined the channel.

lovesh (Thu, 28 Mar 2019 15:26:51 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=Sin5haWCEEADioapC) @wip-abramson The problem with DIDs (delegatable credentials or otherwise) is that they are not cryptographically linked to the credential or public key. But if the DID was somehow generated from public key like first n bytes of public key or the DID was some pre-decided function of secret key, then you can prove the issuance of credential by a DID. The proving mechanism i can think of are generic proving systems like SNARKs or Bulletproofs

lovesh (Thu, 28 Mar 2019 15:26:51 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=Sin5haWCEEADioapC) @wip-abramson The problem with DIDs (delegatable credentials or otherwise) is that they are not cryptographically linked to the credential or public key. But if the DID was somehow generated from public key like first n bytes of public key or the DID was some pre-decided function of public key/secret key, then you can prove the issuance of credential by a DID. The proving mechanism i can think of are generic proving systems like SNARKs or Bulletproofs

dhuseby (Thu, 28 Mar 2019 15:45:03 GMT):
@cam-parra https://jira.hyperledger.org/projects/URSA/issues/URSA-6?filter=allopenissues

cam-parra (Thu, 28 Mar 2019 15:58:50 GMT):
If there is no opposition we should enable 2 maintainer review per PR enforcement on master and stable branches

cam-parra (Thu, 28 Mar 2019 18:41:43 GMT):
@rjones how does one create a new repository in the hyperledger organization?

rjones (Thu, 28 Mar 2019 22:16:03 GMT):
sending a mail to helpdesk@hyperledger.org

rjones (Thu, 28 Mar 2019 22:16:21 GMT):
let them know who the committers are, etc

rjones (Thu, 28 Mar 2019 22:16:47 GMT):
@cam-parra

daijianw (Fri, 29 Mar 2019 08:27:10 GMT):
Has joined the channel.

JulianGordonHK (Fri, 29 Mar 2019 10:06:46 GMT):
Has joined the channel.

Dan (Mon, 01 Apr 2019 17:29:07 GMT):
@cam-parra what would the new repo be for?

cam-parra (Mon, 01 Apr 2019 17:32:05 GMT):
python ursa

cam-parra (Mon, 01 Apr 2019 17:32:05 GMT):
python ursa ... basically the bls wrapper for plenum to consume. Had a bit of miscommunication so I will shared the fixed link tomorrow

rjones (Mon, 01 Apr 2019 18:13:19 GMT):
Has left the channel.

Dan (Mon, 01 Apr 2019 19:24:46 GMT):
did anyone take notes for the March 6th meeting? Particularly for the Anon Creds 2.0 paper discussion? Agenda is listed here: https://wiki.hyperledger.org/display/ursa/2019-03-06+Meeting+Agenda But there aren't any associated minutes published

MALodder (Mon, 01 Apr 2019 19:39:37 GMT):
@Dan I can fill you in on that discussion if you want because we've been covering it a lot since then in the Sovrin Crypto Calls.

MALodder (Mon, 01 Apr 2019 19:39:46 GMT):
@Dan welcome back to the free world

Dan (Mon, 01 Apr 2019 19:39:53 GMT):
Gracias! :D

hartm (Tue, 02 Apr 2019 01:26:03 GMT):
@Dan I would highly recommend attending the Sovrin crypto calls if you're interested in that, since that is where we typically discuss Anon Creds. They are Tuesday mornings at 7:00 AM pacific.

MALodder (Tue, 02 Apr 2019 02:09:04 GMT):
See you both in the morning, we are planning to discuss delegatable credentials, proving to multiple parties, and multi issuer credentials

MALodder (Tue, 02 Apr 2019 02:09:43 GMT):
@hartm thanks for all your input on the anoncreds 2.0 paper, I'm working on the next revisions still, but have more time now that I'm back from traveling

twshelton (Tue, 02 Apr 2019 13:11:27 GMT):
@MALodder where can I find details on the Crypto call for this morning?

cam-parra (Tue, 02 Apr 2019 13:38:43 GMT):
@twshelton Description:Agenda: https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit?usp=sharing Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/567114224

twshelton (Tue, 02 Apr 2019 13:39:29 GMT):
thanks

Dan (Tue, 02 Apr 2019 15:40:50 GMT):
@MALodder thanks for writing the quarterly report.

MALodder (Tue, 02 Apr 2019 15:55:57 GMT):
NP

MALodder (Tue, 02 Apr 2019 16:00:30 GMT):
@Dan it would be good if you and your team state what you would like to see out of zmix

Dan (Tue, 02 Apr 2019 16:01:47 GMT):
in a nutshell, private transactions, but I will try to get to a fuller statement on that with the rest of sawtooth

hartm (Tue, 02 Apr 2019 17:09:12 GMT):
@Dan it would also be awesome if you all could go over the new, modular APIs we are proposing. We don't want to do anything that catastrophically breaks sawtooth.

hartm (Tue, 02 Apr 2019 17:10:01 GMT):
Additionally, explicitly defining what you mean by "private transactions" would also be useful, but it sounds like you're working on that one.

kdenhartog (Tue, 02 Apr 2019 17:38:30 GMT):
I just read the Delegatable credentials 0.1 paper by Dmitry and @lovesh. That was way more digestible then any other crypto paper I ever read!

kdenhartog (Tue, 02 Apr 2019 17:38:30 GMT):
I just read the Delegatable credentials 0.1 paper by Dmitry and @lovesh That was way more digestible then any other crypto paper I ever read!

kdenhartog (Tue, 02 Apr 2019 17:39:13 GMT):
https://drive.google.com/file/d/1ZctrCCQl4v8m6Iz6MTIYSI94nxAd9ElP/view

kdenhartog (Tue, 02 Apr 2019 17:39:43 GMT):
Specifically the numbering for the math and the notation section were super useful.

kdenhartog (Tue, 02 Apr 2019 17:39:43 GMT):
Specifically the numbering for steps with the math and the notation section were super useful.

MALodder (Wed, 03 Apr 2019 02:48:36 GMT):
Interesting paper https://eprint.iacr.org/2019/330.pdf

MALodder (Wed, 03 Apr 2019 02:48:48 GMT):
NIKE!!

MALodder (Wed, 03 Apr 2019 02:49:02 GMT):
but better

hartm (Wed, 03 Apr 2019 03:10:25 GMT):
@MALodder You got me excited there! It's not NIKE (just closer to "round-optimal" KE--there is interaction).

hartm (Wed, 03 Apr 2019 03:10:39 GMT):
@here Just a reminder of tomorrow's meeting. Hope to talk to many of you tomorrow! Thanks!

MALodder (Wed, 03 Apr 2019 03:11:45 GMT):
@hartm sorry about that, they mention NIKE near the intro. I wonder if the shoe company knows they're wanted in the crypto space

hartm (Wed, 03 Apr 2019 03:12:59 GMT):
@MALodder No worries. Definitely the lesser known use of that word...

MALodder (Wed, 03 Apr 2019 03:13:38 GMT):
@hartm I like the idea, I'm fuzzy about the practical part whether it really is or not

hartm (Wed, 03 Apr 2019 03:51:34 GMT):
@MALodder There isn't a really compelling reason to use isogeny-based crypto right now. Its main interest is post-quantum cryptography in the event that lattice-based schemes somehow get broken.

hartm (Wed, 03 Apr 2019 03:51:53 GMT):
In that sense, it's a great research topic, but maybe not so useful for implementations.

MALodder (Wed, 03 Apr 2019 03:55:04 GMT):
Some say SSI based crypto is a drop in replacement for ECC with bigger keys. That's not everything but how true is that

hartm (Wed, 03 Apr 2019 05:34:36 GMT):
Personally, I'd rather use lattice-based key exchanges for post-quantum key exchange. This is probably the opinion of most people in the crypto community. It will be interesting to see what NIST does going forward.

Dan (Wed, 03 Apr 2019 13:06:17 GMT):
I'm on the community zoom link but all alone

Dan (Wed, 03 Apr 2019 13:06:39 GMT):
or is this a timezone thing... hmm..

VipinB (Wed, 03 Apr 2019 13:19:52 GMT):
@hartm as you and @MALOdder know NIST was supposed to show up at RWC, but they could not due to govt shutdown to announce winners or candidates of post-quantum competition...

VipinB (Wed, 03 Apr 2019 13:19:52 GMT):
@hartm as you and @MALodder know NIST was supposed to show up at RWC, but they could not due to govt shutdown to announce winners or candidates of post-quantum competition... I have to look at their latest announcements on that front are!

hartm (Wed, 03 Apr 2019 13:49:17 GMT):
@VipinB They made the announcements soon after RWC.

VipinB (Wed, 03 Apr 2019 13:55:00 GMT):
I guess this "narrows" the field to 26 candidates https://csrc.nist.gov/publications/detail/nistir/8240/final

hartm (Wed, 03 Apr 2019 14:03:50 GMT):
https://wiki.hyperledger.org/pages/resumedraft.action?draftId=6428850&draftShareId=8cdc4ab4-a04e-47ba-9dbe-43e566183fad

VipinB (Wed, 03 Apr 2019 14:07:50 GMT):
Oh no! Incubation vs. Active! again!

VipinB (Wed, 03 Apr 2019 14:36:03 GMT):
Elevator is going to the 66 floor

JonGeater (Thu, 04 Apr 2019 10:03:48 GMT):
I just updated my line on the minutes from yesterday: Jon- has concerns about using OpenSSL (or any stateful crypto back-end): If we wrap through to OpenSSL for the crypto implementation of SM2, but then to intel built-ins for AES, and some HSM or wallet for ECC, then our overall application will be swimming with loaded states, logins, contexts, sessions...which need to be managed carefully, finalised, destroyed and so on at the right time. If people have concerns about tainting then I think it's much more important to ensure we keep these various memory spaces clean and isolated rather than worrying about particular crypto implementations at the far end of one particular API call.

silasdavis (Thu, 04 Apr 2019 14:15:18 GMT):
ed25519

dhuseby (Fri, 05 Apr 2019 00:27:42 GMT):
@JonGeater I agree

dhuseby (Fri, 05 Apr 2019 00:28:01 GMT):
the OpenSSL route is only a temporary measure until we run the regulatory approval gauntlet

dhuseby (Fri, 05 Apr 2019 00:28:07 GMT):
which may be never

dhuseby (Fri, 05 Apr 2019 00:28:27 GMT):
I see the OpenSSL wrapping as "almost never going to be compiled"

Dan (Fri, 05 Apr 2019 13:56:49 GMT):
I think that's a good reason we should turn our attention to zmix. There's a lot of things we could do that would be beneficial, but everything has not only initial cost but long term costs in managing complexity and maintenance.

MALodder (Mon, 08 Apr 2019 15:49:35 GMT):
@dan I agree that we should go to zmix, however, there are needs that Indy has for encryption were WebCrypto/pick your crypto library doesn't meet the needs

MALodder (Mon, 08 Apr 2019 15:49:59 GMT):
it would be nice to have the APIs defined and then exact implementations can be expanded later

MALodder (Mon, 08 Apr 2019 20:14:00 GMT):
quick report on ffi-support: Seems easy to implement and do ffi and solves most of the issues I've had in the past. Lots of pluses in that statement. However, here are some downsides: 1- Documentation is limited 2- Examples are okay but also limited 3- ByteBuffer, rust coder has to use unsafe to extract the pointers and convert to a slice right now. Need to find a better and easier way to use it.

Dan (Mon, 08 Apr 2019 22:43:22 GMT):
we could move forward with the rfc recommending protobufs for complex types. then try out the ffi crate and if that proves worthwhile we could update the RFC to be more prescriptive requiring that crate.

MALodder (Mon, 08 Apr 2019 23:10:22 GMT):
I prefer flatbuffers to protobuffers but it may not be as available

VipinB (Tue, 09 Apr 2019 01:28:48 GMT):
https://google.github.io/flatbuffers/flatbuffers_benchmarks.html some interesting numbers. also some remarks on Cap'n Proto

MALodder (Tue, 09 Apr 2019 02:34:14 GMT):
Anyone have any experience calling C from golang? I’ve done minimal work with it

arsulegai (Tue, 09 Apr 2019 05:21:15 GMT):
We had a project where C functions were called from GoLang

arsulegai (Tue, 09 Apr 2019 05:22:03 GMT):
Is there specific thing you're looking at?

MALodder (Tue, 09 Apr 2019 14:02:38 GMT):
yes

arsulegai (Tue, 09 Apr 2019 15:13:53 GMT):
Please let me know if I can be of help here

MALodder (Tue, 09 Apr 2019 15:20:46 GMT):
the main thing I'm interested in is trying to call rust code that I've exposed over the FFI from golang

MALodder (Tue, 09 Apr 2019 15:20:55 GMT):
but I'm not sure I've done it properly from golang

MALodder (Tue, 09 Apr 2019 15:22:54 GMT):
I've followed it according to this project https://github.com/medimatrix/rust-plus-golang

MALodder (Wed, 10 Apr 2019 05:43:55 GMT):
As promised for your consumption, a comparison of apache milagro vs ZCash's pairing library for the BLS12-381 curve for the BLS signature https://github.com/mikelodder7/bls12-381-comparison

MALodder (Wed, 10 Apr 2019 05:45:33 GMT):
https://pbs.twimg.com/media/D1pN0pJVYAAa_ht.jpg

MALodder (Wed, 10 Apr 2019 05:46:15 GMT):
I welcome suggestions or changes to the code to see if any of the implementations can run any faster

MALodder (Wed, 10 Apr 2019 05:46:41 GMT):

D1pN0pJVYAAa_ht.jpg

Dan (Wed, 10 Apr 2019 18:13:03 GMT):
Regarding https://github.com/hyperledger/ursa-rfcs/pull/8, it sounds like we aren't ready to be more prescriptive on e.g. protobufs or the FFI library. I'm fine with that. So the only open I see is correcting the link for the naming conventions. @amundson and @manu haven't weighed in yet and may have other feedback.

MALodder (Wed, 10 Apr 2019 19:13:45 GMT):
I want to avoid being overly prescriptive because it depends on the language and use case. Some items are better serialized to flatbuffers or protobuffers and others its preferred to have a pointer handle

MALodder (Wed, 10 Apr 2019 19:14:13 GMT):
Like wasm doesn’t support pointers so you have to use serialized structures

MALodder (Thu, 11 Apr 2019 00:06:53 GMT):
@Dan interesting topic here at ZKproof https://eprint.iacr.org/2019/191.pdf. Could Sawtooth takes some of the ideas from this?

MALodder (Thu, 11 Apr 2019 00:07:30 GMT):
Anonymous consumers for smart contracts

lovesh (Thu, 11 Apr 2019 05:53:18 GMT):
Zether does not work for any arbitrary smart contract but only as a cryptocurrency on a ledger with an account model (Ethereum) and even then its not clean. There is a short summary of which also mentions the challenges https://medium.com/coinmonks/notes-on-zether-towards-privacy-in-a-smart-contract-world-6c4333f975d

MALodder (Thu, 11 Apr 2019 13:06:18 GMT):
The presenter was saying it could possibly be applied to any smart contract ledger that supports tokens.

MALodder (Thu, 11 Apr 2019 13:07:10 GMT):
Doesn’t mean it couldn’t work. The idea is interesting

MALodder (Thu, 11 Apr 2019 13:07:41 GMT):
I’m more interested in the idea of encrypted values and verification

kdenhartog (Thu, 11 Apr 2019 14:07:31 GMT):
I just found this https://www.iden3.io/post/websnark-zksnarks-generation-browser-now-fast-and-easy

kdenhartog (Thu, 11 Apr 2019 14:07:47 GMT):
Seemed like a cool repo that may be interesting to people here

Dan (Thu, 11 Apr 2019 16:13:05 GMT):
thanks @MALodder! As it depends on bullet proofs, I looked for a quick synopsis to refresh myself. Google offered many helpful links all like this: https://bit.ly/2v84MSh

Dan (Thu, 11 Apr 2019 16:14:25 GMT):
It's pretty hard to hit numbers that low. Definitely a mathematical feat.

MALodder (Thu, 11 Apr 2019 16:41:29 GMT):
Ha never saw that movie

rjones (Sat, 13 Apr 2019 00:14:41 GMT):
Has joined the channel.

rjones (Sat, 13 Apr 2019 00:14:50 GMT):
Could I ask Ursa maintainers to please join https://lists.hyperledger.org/g/maintainers ? I'd appreciate it.

Dan (Sat, 13 Apr 2019 21:51:43 GMT):
FYI I can't make the sovrin call tomorrow, but I will review the minutes.

MALodder (Mon, 15 Apr 2019 13:47:34 GMT):
@Dan the call is on Tuesday if that helps, but if you can't make it we understand

Dan (Mon, 15 Apr 2019 14:17:37 GMT):
That's weird. I sent that last week. Must have queued up on my phone or something. :shrug:

Dan (Mon, 15 Apr 2019 14:43:28 GMT):
@lovesh nice summary! I think the economic impediments to deploying on ethereum mainnet, aren't necessarily an issue for something like a permissioned sawtooth network. The anonymity limitation, however is awkward. I'm skeptical about meaningful anonymity in a permissioned/private blockchain anyway though. That said I do like the confidentiality model (for hiding the account amounts). One thing I'm not comfortable with, though, is the difficulty for a user in knowing their own balance. Specifcally they only know g^b. On the one hand it's good that nothing is transparent on ledger (like if private keys get compromised), on the other brute forcing g^b seems yucky. Does anyone have thoughts on that?

hartm (Mon, 15 Apr 2019 17:34:39 GMT):
@Dan Anonymity is challenging in general (even ZCash is not without its issues given its sometimes limited anonymity set). One thing I've been intermittently working on (without much success, unfortunately) is trying to adapt something like Riposte (https://www.henrycg.com/pubs/oakland15riposte/) to a permissioned blockchain setting. The general paradigm is almost exactly what we want, but some of the tools used don't scale and the security models with the existing tools aren't good for blockchain (i.e. security only against one malicious server).

hartm (Mon, 15 Apr 2019 17:34:51 GMT):
I have been discussing this with Mike some.

hartm (Mon, 15 Apr 2019 17:35:21 GMT):
If you're interested, we can talk further, but there is a lot of crypto theory that needs to be worked out around this to have some kind of (semi-) efficient solution.

MALodder (Mon, 15 Apr 2019 18:27:37 GMT):
@hartm what conferences/journals were you suggesting we try to publish for AnonCreds 2.0?

cam-p 1 (Mon, 15 Apr 2019 18:47:48 GMT):
Has joined the channel.

hartm (Mon, 15 Apr 2019 18:51:44 GMT):
@MALodder I'm not sure at this point, but probably a security conference. It's a little premature though--you'll want an implementation, security proof, and performance results before you submit.

MALodder (Mon, 15 Apr 2019 18:56:02 GMT):
right, just wanted to know the options and whether you would want it published beforehand but it sounds like that's not the case

hartm (Tue, 16 Apr 2019 02:42:04 GMT):
@MALodder For a conference paper on something like this, you'd probably want an implementation (for performance purposes), but it would not necessarily need to be a production-ready implementation. I'd imagine you could move from "test implementation" to "production implementation" during the time that the paper was in the review process.

MALodder (Tue, 16 Apr 2019 17:17:57 GMT):
Anyone have any objections to releasing ursa 0.1.1?

MALodder (Tue, 16 Apr 2019 17:18:17 GMT):
I submitted a PR mostly minor things related to namespacing the errors for indy

MALodder (Tue, 16 Apr 2019 17:18:42 GMT):
with the release of ursa 0.1.1, Indy can now use it

MALodder (Tue, 16 Apr 2019 17:19:05 GMT):
pipeline for 0.1.1 results are [here](https://gitlab.sovrin.org/sovrin-foundation/ursa/pipelines/7)

MALodder (Tue, 16 Apr 2019 17:19:45 GMT):
CI results for indy are [here](https://github.com/hyperledger/indy-sdk/pull/1578)

hartm (Tue, 16 Apr 2019 18:09:33 GMT):
@MALodder No, but do we need to follow any particular release protocols? Did we have anything in place for minor "hundredth" releases?

MALodder (Tue, 16 Apr 2019 18:10:10 GMT):
I've just been making sure it passes the CI/CD pipeline then asking about it to everyone

MALodder (Tue, 16 Apr 2019 18:25:57 GMT):
@hartm I've been thinking about other names for the signature types and I thought that Schnor sigs is fitting

MALodder (Tue, 16 Apr 2019 18:25:57 GMT):
@hartm I've been thinking about other names for the signature types and I thought that Schnorr sigs is fitting

hartm (Wed, 17 Apr 2019 00:50:15 GMT):
@here Just a reminder for tomorrow's meeting! Hope to talk to many of you tomorrow. Thanks!

Dan (Wed, 17 Apr 2019 14:03:41 GMT):
agenda link: https://wiki.hyperledger.org/pages/viewpage.action?pageId=9109744

Dan (Wed, 17 Apr 2019 14:06:14 GMT):
https://github.com/hyperledger/ursa/pull/23

david.b.crypto (Wed, 17 Apr 2019 15:13:24 GMT):
Hi, I can't edit the agenda. Wondering if someone can add the following to the agenda or minutes as appropriate: "Discussed foreign function interface for lib-ursa, and interface to Fabric through golang. We have agreement at this stage to try different alternatives and learn which is best for our needs. Mike, Maryam, DH and DB to pursue next steps"

MALodder (Wed, 17 Apr 2019 15:17:58 GMT):
I added it to the agenda as I can't find the minutes link

MALodder (Wed, 17 Apr 2019 15:19:04 GMT):
I added it to the minutes

Dan (Wed, 17 Apr 2019 16:01:38 GMT):
@david.b.crypto you should be able to edit in the future if you login to the wiki with your LF ID.

david.b.crypto (Wed, 17 Apr 2019 16:02:21 GMT):
thanks dan!

marimeireles (Wed, 17 Apr 2019 17:21:48 GMT):
Has joined the channel.

marimeireles (Wed, 17 Apr 2019 17:31:13 GMT):
hi @hartm I want to contribute to hyperledger through the SoC program. I chose the project that I have to integrate ursa to iroha. do you think I can join the meeting you're having? I wouldn't really say anything just watch to see if I can catch some things! if it's not allowed it's totally fine too. thanks! :)

rjones (Wed, 17 Apr 2019 17:32:35 GMT):
@marimeireles all of the meetings are public - please join!

rjones (Wed, 17 Apr 2019 17:32:49 GMT):
you don't need to ask permission, promise. We want everyone

marimeireles (Wed, 17 Apr 2019 17:34:48 GMT):
hi @rjones! alright! thanks! :D

rjones (Wed, 17 Apr 2019 17:35:57 GMT):
if you look in the community calendar on the wiki, there should be a list of meetings you can join.

rjones (Wed, 17 Apr 2019 17:36:24 GMT):
@marimeireles https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings

rjones (Wed, 17 Apr 2019 17:37:20 GMT):
the times are GMT, so be sure to add them to your personal calendar in the correct time zone ;)

marimeireles (Wed, 17 Apr 2019 17:49:15 GMT):
nice! thanks again @rjones

MALodder (Wed, 17 Apr 2019 20:19:36 GMT):
@hartm I can help you write the aggregated/multi/threshold signatures API. We can use what I learned from this project [here](https://github.com/mikelodder7/bls12-381-comparison/blob/master/src/main.rs)

hartm (Wed, 17 Apr 2019 20:40:57 GMT):
@MALodder That looks like a pretty nice interface. We'll want to modify it so that we can use different schemes, obviously, but it's a good start.

hartm (Wed, 17 Apr 2019 20:42:00 GMT):
I'll write up a formal interface sometime over the next couple of days and then you can tell me how I got the Rust stuff wrong ;)

cam-parra (Fri, 19 Apr 2019 19:32:41 GMT):
Hey @MALodder @dhuseby I believe the python wrapper is ready to move to hyperledger. I would need your assistance to do so

cam-parra (Fri, 19 Apr 2019 19:32:54 GMT):
https://github.com/lanius-shrike/python-ursa

cam-parra (Fri, 19 Apr 2019 19:37:25 GMT):
I am working out the problems with gitlab but it should at least be tested by next week

dhuseby (Fri, 19 Apr 2019 20:05:11 GMT):
Do we want to have separate repos for the language bindings?

dhuseby (Fri, 19 Apr 2019 20:05:44 GMT):
If we go with generated bindings using protobufs we will want only one set of the protobuf files.

dhuseby (Fri, 19 Apr 2019 20:06:42 GMT):
Maybe we have a repo just for the protobuf files? Then libursa can pull it in as a submodule. The python-Ursa repo can do the same.

dhuseby (Fri, 19 Apr 2019 20:07:24 GMT):
@cam-parra does the python-ursa project pull in and build libursa?

dhuseby (Fri, 19 Apr 2019 20:07:57 GMT):
If it does then we can keep the protobuf files in libursa and not have a separate repo for them.

MALodder (Fri, 19 Apr 2019 20:18:58 GMT):
The RFC I submitted is for the bindings to be in ursa and the language idiomatic libraries are in separate repos

rjones (Fri, 19 Apr 2019 21:39:28 GMT):
@cam-parra please run the DCO check tool first to make my life easier 😀

rjones (Fri, 19 Apr 2019 22:02:01 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=HJqjNeIwOFcchfhL98) ```*$ lftools dco check Checking commits in branch origin/master for commits missing DCO... ERROR: Commit 65eb21646eeb212d7d2cd743a14bed107a730876 is missing Signed-off-by line. ERROR: Commit 677ac9b9c60ce33a67883e57cabb7216ae6e4728 is missing Signed-off-by line. *```

cam-parra (Sat, 20 Apr 2019 18:29:39 GMT):
@rjones Does that DCO check look for merges? Most merges or PRs accepted don't include (or require) a DCO

rjones (Sun, 21 Apr 2019 21:04:35 GMT):
@cam-parra it does not. Feel free to grab it and try it yourself https://gist.github.com/ryjones/07ac650dcc5e83c91e8308ec98bacda4 you can also do a "git log (hash)" to see the exact commit

Dan (Mon, 22 Apr 2019 00:41:04 GMT):
depending on what your workflow is like you can reduce the amount of merges by rebasing as you go. irrespective of DCO checking sometimes that makes for a cleaner history that makes it easier for reviewers too.

rjones (Mon, 22 Apr 2019 02:18:57 GMT):
```(lftools) mbp-2:python-ursa ry$ git log -1 65eb21646eeb212d7d2cd743a14bed107a730876 commit 65eb21646eeb212d7d2cd743a14bed107a730876 Author: Cam Parra Date: Thu Mar 21 16:25:45 2019 -0600 add readme.md (lftools) mbp-2:python-ursa ry$ git log -1 677ac9b9c60ce33a67883e57cabb7216ae6e4728 commit 677ac9b9c60ce33a67883e57cabb7216ae6e4728 Author: Cam Parra Date: Thu Mar 21 15:31:13 2019 -0600 license added ```

MALodder (Mon, 22 Apr 2019 12:28:19 GMT):
Merge commits are not required to have a DCO. DCO will pass if a merge commit doesn’t have the Signed-off-by

Dan (Tue, 23 Apr 2019 15:57:00 GMT):
Hi, I had a conflict with the Sovrin crypto meeting this morning. is there a recording?

MALodder (Tue, 23 Apr 2019 16:51:51 GMT):
unfortunately no

MALodder (Tue, 23 Apr 2019 16:52:09 GMT):
if you want I can send you the meeting notes

Dan (Tue, 23 Apr 2019 18:39:03 GMT):
that would be cool thanks!

VipinB (Tue, 23 Apr 2019 18:49:21 GMT):
My take on zkproof standards workshop. There are some links to some of the talks and other resources. https://medium.com/@vipinsun/zkproof-standards-workshop-ii-1b1b1568eb14

MALodder (Tue, 23 Apr 2019 19:43:25 GMT):
@Dan We discussed the following ``` Authz Overview and Review Authz New architecture Pointcheval Saunders Threshold Signature ```

Dan (Tue, 23 Apr 2019 19:44:56 GMT):
anyone have a high level diff of idemix vs. anoncreds2.0?

MALodder (Tue, 23 Apr 2019 19:45:26 GMT):
@Dan I can give you some of that, I don't know where Idemix is at this point but I can tell you where we started from

MALodder (Tue, 23 Apr 2019 19:46:40 GMT):
This is the Idemix reference implementation we used https://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/eeb54ff3b91c1d648525759b004fbbb1?OpenDocument

MALodder (Tue, 23 Apr 2019 19:49:19 GMT):
Anoncreds 2.0 is vastly different in the following ways: 1- We are using BBS+ and Poincheval Saunders signatures which are ECC pairing based 2- We use Bulletproofs for range proofs, set memberships, and inequality proofs 3- We can use zkSNARKS instead of Bulletproofs 4- We also are planning to allow some credentials to be transferrable and delegatable 5- We have policies which allow Agents to prove authorizations for the credentials they hold allowing owners to halt bad agents when necessary

MALodder (Tue, 23 Apr 2019 19:49:44 GMT):
We plan to not use any RSA crypto for Anoncreds 2.0

Dan (Tue, 23 Apr 2019 19:58:18 GMT):
cool. that helps a lot thanks!

deepikav (Tue, 23 Apr 2019 20:39:41 GMT):
@MALodder, what would BBS+ and Poincheval Saunders Signatures be replacing in idemix?

MALodder (Tue, 23 Apr 2019 20:44:10 GMT):
BBS+ and pointcheval saunders are used for the anonymous credentials portion

MALodder (Tue, 23 Apr 2019 20:44:40 GMT):
Indy doesn't use Idemix directly, it uses only a subset of it and does revocation completely different

Silona (Wed, 24 Apr 2019 02:10:49 GMT):
Hey devs, anything exciting going on? please consider submitting a blog post! http://bit.ly/HLEDSubmission

jadhavajay (Wed, 24 Apr 2019 06:19:19 GMT):
Has joined the channel.

bart.cant@gmail.com (Thu, 25 Apr 2019 15:22:29 GMT):
Has joined the channel.

jshim10 (Fri, 26 Apr 2019 01:47:38 GMT):
Has joined the channel.

wip-abramson (Mon, 29 Apr 2019 18:34:53 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=7F7oPrztuuMXRGbSL) @MALodder How will it decide when to use BBS+ or PS for credential signatures? Or does every credential use both?

MALodder (Mon, 29 Apr 2019 18:39:16 GMT):
I'm coding both right now and want to do benchmarks

MALodder (Mon, 29 Apr 2019 18:39:35 GMT):
for performance, memory, signature size, and proof size

wip-abramson (Mon, 29 Apr 2019 20:00:28 GMT):
Can you share the repo? I would love to follow along and ask questions especially on the Rust way of doing things

MALodder (Mon, 29 Apr 2019 21:30:09 GMT):
sure I haven't finished it yet

MALodder (Mon, 29 Apr 2019 21:37:41 GMT):
> Can you share the repo? I would love to follow along and ask questions especially on the Rust way of doing things https://github.com/mikelodder7/anoncreds-signatures

wip-abramson (Tue, 30 Apr 2019 13:08:13 GMT):
Thanks!

danintel (Wed, 01 May 2019 14:03:25 GMT):
The agenda has no meeting information...neither does the mailing list

danintel (Wed, 01 May 2019 14:04:01 GMT):
Found some old notes.... https://wiki.hyperledger.org/display/ursa/Hyperledger+Ursa

hartm (Wed, 01 May 2019 14:32:31 GMT):
Thanks for pointing this out! We should make this easier to find.

JonGeater (Wed, 01 May 2019 15:01:58 GMT):
So I'm about to start hitting the Overleaf document. A lot of the detail of what I need to write up concerns the nature of sessions and initialisation and key handling and stuff in the library as a whole, not just the simple crypto calls. Unless someone screams otherwise I'll add a whole major section to the Overleaf doc on provider architecture

hartm (Wed, 01 May 2019 15:21:54 GMT):
@JonGeater Go for it. Add a whole new file even if you like.

JonGeater (Wed, 01 May 2019 15:22:56 GMT):
Let's see how it goes: if the section gets too big or messy we can abstract it out later

JonGeater (Wed, 01 May 2019 15:22:58 GMT):
Thanks

JonGeater (Wed, 01 May 2019 15:25:29 GMT):
It's probably good that the Fabric guys aren't here yet: I want to get the principles sorted in the current doc before we're forced to translate the whole thing into golang ;-)

JonGeater (Wed, 01 May 2019 15:26:07 GMT):
(I say that rather tongue-in-cheek, since my golang is considerably better than my rust. But still...)

MALodder (Wed, 01 May 2019 15:28:49 GMT):
> (I say that rather tongue-in-cheek, since my golang is considerably better than my rust. But still...) You're just not Rusty enough

MALodder (Wed, 01 May 2019 15:28:49 GMT):
> (I say that rather tongue-in-cheek, since my golang is considerably better than my rust. But still...) You're just not Rusty enough ;-)

danintel (Wed, 01 May 2019 15:43:23 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=87nZvqX4GW8gjvv7A) @JonGeater Food fight!

Silona (Thu, 02 May 2019 15:29:42 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=2bQL3X8NCf4akM3Wh) @hartm another wiki trick click on the three dots to get page info - and there is a short URL is you want

Silona (Thu, 02 May 2019 15:30:38 GMT):
Also remember you can do GLiffy and Balsamic diagrams in the wiki! so you can collaborate on them easier

Silona (Thu, 02 May 2019 15:31:18 GMT):
and there is a TOC macro - with the confluence - there is often a macro for that...

JonGeater (Fri, 03 May 2019 10:41:40 GMT):
I really like Balsamiq. I'm not immediately sure what use it is for Ursa collaboration but for product ideas it's brilliantly efficient

fimbault (Fri, 03 May 2019 11:55:04 GMT):
Has joined the channel.

VipinB (Fri, 03 May 2019 21:49:35 GMT):
Does anyone know where the recent recordings from Ursa meetings are?

VipinB (Fri, 03 May 2019 22:20:33 GMT):
Hart pointed it out to me https://wiki.hyperledger.org/display/ursa/Meeting+Recordings

Silona (Tue, 07 May 2019 16:24:34 GMT):
I like it when explaining use cases even if i'm not going to create the actual interface... but yes Gliffy is better for the diagrams :-)

troyronda (Wed, 08 May 2019 18:31:18 GMT):
Has joined the channel.

MALodder (Wed, 08 May 2019 20:05:25 GMT):

Starkad_Poseidon.pdf

MALodder (Thu, 09 May 2019 15:56:02 GMT):
Indy is now using Ursa!!! See [PR](https://github.com/hyperledger/indy-sdk/pull/1578/files/062259491effb040c042bf48a4fa196c91c98f0a..d53012f0021bd3b895c2a29c7bcf384ec180e482)

MALodder (Thu, 09 May 2019 15:57:03 GMT):
🎉🎉

JonGeater (Thu, 09 May 2019 16:50:11 GMT):
I do like being on a chat channel where PR means 'Pull Request' and not Press Release :-)

JonGeater (Thu, 09 May 2019 16:50:46 GMT):
Question about Overleaf: Do I have to somehow save my edits and then hit the Publish button, or are you all seeing my edits as I make them?

JonGeater (Thu, 09 May 2019 16:52:01 GMT):
I'm leaving the office soon and wondering how rough I can leave my WIP

MALodder (Thu, 09 May 2019 17:01:04 GMT):
The updates are automatically saved. You don’t have to publish it to save edits

JonGeater (Thu, 09 May 2019 17:22:43 GMT):
Cool thanks. I think it's in a fair state to leave for now: basic stuff in, I'll hard the hard detail later when I have a straight couple of hours to hit it

kdenhartog (Thu, 09 May 2019 19:42:34 GMT):
For those who are looking for some extra side cash, here's a competition to improve SNARKs https://coinlist.co/build/coda

ryanwest6 (Thu, 09 May 2019 21:54:31 GMT):
Has joined the channel.

MALodder (Fri, 10 May 2019 15:08:40 GMT):
here's the eprint for the poseidon hash function

MALodder (Fri, 10 May 2019 15:08:43 GMT):
https://eprint.iacr.org/2019/458.pdf

Dan (Mon, 13 May 2019 14:19:13 GMT):
I think we might be missing the commit history for a lot of ursa. Like from the point of time that things got migrated over from the lab state. For example if I want to figure out the rational for why these files are in bin, I get a dead end https://github.com/hyperledger/ursa/commit/3367813213dd532d24ec9f5e92af71842c377080#diff-9ca2f7ab5fffa18f89b226c4a583fc91 If I want to know anything about the BLS code I get the same dead end.

sklump (Mon, 13 May 2019 14:21:16 GMT):
Has joined the channel.

rjones (Mon, 13 May 2019 17:04:01 GMT):
@Dan the second one doesn't look like a valid git hash (too short)

Dan (Mon, 13 May 2019 17:41:21 GMT):
maybe a problem with the github interface? Just pick probably anything that had been in libhl-crypto as part of the lab (and probably previously as part of indy-crypto). When it came over into ursa and refactored as libursa I think we lost the commit history - or at least that's what I dead end on through github.

rjones (Mon, 13 May 2019 17:44:17 GMT):
@dan yes it is.

rjones (Mon, 13 May 2019 17:44:17 GMT):
@Dan yes it is a problem with the github UI

rjones (Mon, 13 May 2019 17:44:21 GMT):
```$ git log libindy_crypto-win-zip-and-upload.sh commit 97363ebe2fe4e5a17c88023d149ebcef6b76a7a6 Author: Michael Lodder Date: Thu Dec 13 15:57:17 2018 -0700 Namespace to ursa Signed-off-by: Michael Lodder commit 3367813213dd532d24ec9f5e92af71842c377080 Author: Michael Lodder Date: Tue Dec 11 17:07:09 2018 -0700 Move directories,Update README,Add build instructions Signed-off-by: Michael Lodder ```

rjones (Mon, 13 May 2019 17:44:34 GMT):
(I picked a random file from the list that was broken)

Dan (Mon, 13 May 2019 19:08:51 GMT):
So what I'm trying to do is work back to the initial commit for things. Like this BLS code. Here's the initial commit over in indy:

Dan (Mon, 13 May 2019 19:09:58 GMT):
https://github.com/hyperledger/indy-crypto/commit/e661337d91837ffb2ef337d26151389456df8a4a

Dan (Mon, 13 May 2019 19:11:33 GMT):
(for this file: https://github.com/hyperledger/ursa/blob/master/libursa/src/bls/mod.rs)

Dan (Mon, 13 May 2019 19:14:55 GMT):
Ok, maybe I can get there if I navigate to the parent of that last commit you list (33678...)

Dan (Mon, 13 May 2019 19:15:05 GMT):
https://github.com/hyperledger/ursa/blame/89fa1ecf26404f86a516b3deba5bb1bb01948465/libhl-crypto/src/bls/mod.rs

Dan (Mon, 13 May 2019 19:16:37 GMT):
is that normal for history not to follow a rename?

rjones (Mon, 13 May 2019 19:21:41 GMT):
I think gitk makes it easier to see that, but a git rename usually looks like a delete and an add.

rjones (Mon, 13 May 2019 19:22:14 GMT):
Check this out: https://stackoverflow.com/questions/2314652/is-it-possible-to-move-rename-files-in-git-and-maintain-their-history

rjones (Mon, 13 May 2019 19:23:24 GMT):
@Dan : ```mbp-2:bls ry$ git log mod.rs|wc -l 63 mbp-2:bls ry$ git log --follow mod.rs|wc -l 336 ```

rjones (Mon, 13 May 2019 19:23:36 GMT):
so `--follow` is the flag you want

Dan (Mon, 13 May 2019 20:49:54 GMT):
Slick. that works like a charm @rjones !

Dan (Tue, 14 May 2019 14:09:20 GMT):
Sovrin crypto meerting: https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit#heading=h.nbprxa5fdgyg

rekmarks (Tue, 14 May 2019 20:10:30 GMT):

Ursa at Consensus

rekmarks (Tue, 14 May 2019 20:11:06 GMT):
@VipinB onstage at Consensus

rekmarks (Tue, 14 May 2019 20:11:06 GMT):
@VipinB onstage at Consensus presenting Ursa

MALodder (Tue, 14 May 2019 22:20:58 GMT):
CI PR https://github.com/hyperledger/ursa/pull/27

Dan (Tue, 14 May 2019 23:15:16 GMT):
Awesome!

MALodder (Wed, 15 May 2019 00:41:21 GMT):
@dhuseby it would be great to get your feedback on it especially about the Cargo.lock file

hartm (Wed, 15 May 2019 02:27:45 GMT):
@here Just a reminder for tomorrow's meeting. Please add anything you'd like to discuss to the agenda items. Thanks!

danintel (Wed, 15 May 2019 05:03:41 GMT):
Meeting info... https://wiki.hyperledger.org/display/ursa/Hyperledger+Ursa

JonGeater (Wed, 15 May 2019 13:21:15 GMT):
I wonder if channels like this shouldn't have their (bi-)weekly meeting details permanently pinned in the top bar/channel info

JonGeater (Wed, 15 May 2019 13:23:19 GMT):
For today's meeting some people may have noticed I've put a bunch of very drafty information into the Overleaf doc to do with key IDs, session handling, context reference etc. What I *haven't* done yet is the key/TEE attestation details. This is because I want people to be happy with the provider/session type architecture before I go ahead with the hard detail (which would change hugely if we reject what I've done so far)

Dan (Wed, 15 May 2019 13:55:20 GMT):
new to overleaf... it looks like there's supposed to be a rendered view but it's filled with errors. I would guess since this is an online thing that's not a local problem?

Dan (Wed, 15 May 2019 13:56:17 GMT):
undefined control sequence, missing number treated as zero, LaTeX Error etc etc

hartm (Wed, 15 May 2019 13:58:05 GMT):
@Dan Click on "Recompile."

Dan (Wed, 15 May 2019 13:58:43 GMT):
ok, that was easy :)

Dan (Wed, 15 May 2019 14:49:37 GMT):
@amundson Request to check in on RFC PR8 https://github.com/hyperledger/ursa-rfcs/pull/8

hartm (Wed, 15 May 2019 14:56:48 GMT):
http://markus-jakobsson.com/papers/jakobsson-eurocrypt96.pdf

Dan (Wed, 15 May 2019 14:57:20 GMT):
Repudiable proof discussion ^

hartm (Wed, 15 May 2019 15:00:18 GMT):
https://eprint.iacr.org/2017/587.pdf: Subversion resilient SNARKs.

Dan (Wed, 15 May 2019 17:02:40 GMT):
Regarding collaborative LaTeX workflows.. Looks like there's Confluence plugins. That would be a consistent approach with not using google docs and not introducing another un-integrated tool like overleaf. From experience working on a lot of RFCs, the initial weeks (months?) with a doc, a git workflow is not super productive. Git workflow is definitely required once the thing has taken shape. TeX-ish people might like to look at these links and if they look promising we can see about HL supporting one in our Wiki. https://marketplace.atlassian.com/apps/207/latex-plugin?hosting=server&tab=overview https://marketplace.atlassian.com/apps/1216800/latex-math-for-confluence?hosting=server&tab=overview

rjones (Wed, 15 May 2019 17:06:53 GMT):
% \f is defined as f(#1) using the macro \f{x} = \int_{-\infty}^\infty \hat \f\xi\,e^{2 \pi i \xi x} \,d\xi

rjones (Wed, 15 May 2019 17:06:53 GMT):
\[% \f is defined as f(#1) using the macro \f{x} = \int_{-\infty}^\infty \hat \f\xi\,e^{2 \pi i \xi x} \,d\xi\]

rjones (Wed, 15 May 2019 17:06:53 GMT):
\[ \f{x} = \int_{-\infty}^\infty \hat \f\xi\,e^{2 \pi i \xi x} \,d\xi\]

rjones (Wed, 15 May 2019 17:08:57 GMT):
\[$\sum_{i=1}^\infty\frac{1}{n^2} =\frac{\pi^2}{6}$\]

rjones (Wed, 15 May 2019 17:08:57 GMT):
\[\sum_{i=1}^\infty\frac{1}{n^2} =\frac{\pi^2}{6}\]

rjones (Wed, 15 May 2019 17:15:29 GMT):
so you could write it as chat messages here

MALodder (Wed, 15 May 2019 17:34:15 GMT):
I would love it if we could do the latex stuff at hyperledger rather than my personal overleaf account

rjones (Wed, 15 May 2019 17:35:12 GMT):
explain to me what you need

Dan (Wed, 15 May 2019 18:24:29 GMT):
TeX-ish people (looking at you @hartm ) preference on confluence plugin vs. overleaf?

amundson (Wed, 15 May 2019 18:32:48 GMT):
This is for RFCs?

jsmitchell (Wed, 15 May 2019 18:34:38 GMT):
_TeXnicians_, please

rjones (Wed, 15 May 2019 18:40:26 GMT):
\[TeXicians\]

rjones (Wed, 15 May 2019 18:40:26 GMT):
\[TeXnicians\]

rjones (Wed, 15 May 2019 18:40:26 GMT):
\[TEXnicians\]

jsmitchell (Wed, 15 May 2019 18:43:00 GMT):
you need to use the \TeX for the first part of that

Dan (Wed, 15 May 2019 18:50:32 GMT):
The current document in question is kind of straddling definitions. I think it is meant as documentation of APIs but that kind of thing could also be written in markdown as an RFC proposing the interface styles and rationale. In general I don't think we want latex in RFCs. We might want more sophisticated formatting for documentation.

MALodder (Wed, 15 May 2019 20:27:30 GMT):
Mostly we need latex for the crypto math. I don’t think we’ll use it much for RFCs except in that area

hartm (Wed, 15 May 2019 20:37:13 GMT):
$A \in \Z_{q}^{n \times m}$

hartm (Wed, 15 May 2019 20:39:42 GMT):
Tex stuff will be most useful for documentation and examples (i.e. to show how some of the math works with our interfaces).

hartm (Wed, 15 May 2019 20:40:27 GMT):
The confluence plugins look shaky at best, unfortunately, and I doubt they'll work with large documents that contain multiple files. Now I am extremely tempted to try to paste an entire paper in chat....

hartm (Wed, 15 May 2019 20:42:03 GMT):
I think github is probably fine as-is though. The only issue is that if people want to make changes, they'll need to have a Tex compiler installed. However, I think that the set of people we want making changes to math stuff is probably contained in the set people who have Tex compilers installed, so I'm not sure this is a big issue.

rjones (Wed, 15 May 2019 21:25:18 GMT):
ok. the discussion is that the price for Overleaf would be $360 a year or so

Dan (Thu, 16 May 2019 01:26:43 GMT):
@MALodder I guess @dhuseby is tied up. If you are eager to merge, I'm fine either way with the lock file. I mostly wanted to document why. The more "why's" that are searchable the fewer questions down the road / less bike shedding.

MALodder (Thu, 16 May 2019 05:15:16 GMT):
Okay. Do we have two approvals? I can’t merge unless there is.

MALodder (Thu, 16 May 2019 05:16:27 GMT):
Please give your approval

MALodder (Thu, 16 May 2019 05:23:12 GMT):
I know @dhuseby said he would be offline thru the weekend so it doesn’t hurt to wait until next week

MALodder (Thu, 16 May 2019 14:01:44 GMT):
I’ve added reviewers but if I could get more from this channel for https://github.com/hyperledger/ursa/pull/27

Dan (Thu, 16 May 2019 14:31:13 GMT):
Ok, if you are fine waiting until next week, I'll approve it then after Huseby clarifies. I'll update the PR comments with why I'm asking.

MALodder (Thu, 16 May 2019 15:22:17 GMT):
sure

Dan (Thu, 16 May 2019 15:24:00 GMT):
Anyone know if the indy-crypto authors monitor this channel and/or the mail list? I might have some questions to understand the why as I prod around different places in the code we inherited.

brentzundel (Thu, 16 May 2019 15:29:16 GMT):
They probably don't, but I can reach out to them to get any answers Mike and I can't provide.

MALodder (Thu, 16 May 2019 15:30:48 GMT):
Brent and I know that code the best

MALodder (Thu, 16 May 2019 15:30:56 GMT):
Except for a few things

Dan (Thu, 16 May 2019 16:31:25 GMT):
I'm coming up to speed on milagro, and I see that it has a bls module in the bn254 module. Ursa has it's own bls module that relies on amcl::bn254. Curious why the separate ursa implementation vs using amcl's?

MALodder (Thu, 16 May 2019 18:41:59 GMT):
bls is the curve

MALodder (Thu, 16 May 2019 18:42:06 GMT):
bn254 is also the curve

MALodder (Thu, 16 May 2019 18:44:01 GMT):
milagro also does not implement the signature aggregation feature

MALodder (Thu, 16 May 2019 18:45:49 GMT):
so the curve is Boneh-Lynn-Scott and the signature is Boneh-Lynn-Shacham

MALodder (Thu, 16 May 2019 18:46:10 GMT):
you can build the BLS signature using any pairing friendly curve

MALodder (Thu, 16 May 2019 18:46:58 GMT):
I want to make it so in rust you can say BLS::new::() or BLS::new::() and the rest of the functions just work

MALodder (Thu, 16 May 2019 18:46:58 GMT):
I want to make it so in rust you can say BLS::\new::() or BLS::\new::() and the rest of the functions just work

MALodder (Thu, 16 May 2019 18:46:58 GMT):
I want to make it so in rust you can say `BLS::new::()` or `BLS::new::()` and the rest of the functions just work

MALodder (Thu, 16 May 2019 18:50:18 GMT):
some crypto engineers all it BLS²

MALodder (Thu, 16 May 2019 18:50:26 GMT):
BLS on BLS

brentzundel (Thu, 16 May 2019 18:53:17 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=LJFuReaKYKJzPbzBG) https://chat.hyperledger.org/channel/ursa?msg=LJFuReaKYKJzPbzBG

Dan (Thu, 16 May 2019 21:11:29 GMT):
It looks like the decision for implementing the bls signature (not the curve) came like two years ago by @ vimmerru. I see that the ursa implementation has serialization helper functions and the aggregation method which are lacking in milagro. But it also seemed like one could just extend the milagro code to do the same. So I was wondering if there was some other design goal? Particularly one that should be preserved as I start to mess with stuff? Regarding the bls curve, I looked briefly at your bls-signature comparison project and it looks like you imported milagro with the bls curve as a parameter maybe? I'm a little confused on the apache namespace, if that's the same as the amcl namespace. Ursa with me as I'm still pretty new with rust.

MALodder (Fri, 17 May 2019 03:32:54 GMT):
For one thing Milagro uses the base generator for its signatures. This is not a bad thing but Indy generates a random one and uses that for the keys. We also plan to add aggregated signatures in addition to the multisig as well

lovesh (Fri, 17 May 2019 05:20:16 GMT):
Milagro added BLS signature scheme only a few months back so the rust files you see like bls, bls192 are BLS signature scheme imlemenatation and not the curve. Regarding curves, Milagro defines curve parameters in `roms` directory so for BLS12-381 constants you can look at rom_bls381_64.rs and then the logic is kept generic so ecp.rs, ecp2.rs will be groups G1 and G2 for BLS curve, BN curves, etc.

lovesh (Fri, 17 May 2019 05:22:29 GMT):
My understanding is that we already have aggregated signatures, we just call them multisig

lovesh (Fri, 17 May 2019 05:26:30 GMT):
Secondly we should do away with the Generator code we have in indy-crypto/ursa. Milagro gives you generator for both groups and if you need additional generators you can hash strings on the curve using the `mapit` function

MALodder (Fri, 17 May 2019 05:28:22 GMT):
Aggregated is not the same as Multisig

MALodder (Fri, 17 May 2019 05:29:00 GMT):
multisig is an aggregated signature, but aggregated means you have a different message and signature that can be accumulated into a single value

MALodder (Fri, 17 May 2019 05:29:12 GMT):
multisig, is the same message was signed for all signatures

MALodder (Fri, 17 May 2019 05:29:20 GMT):
I'm okay removing the generator

lovesh (Fri, 17 May 2019 05:30:59 GMT):
Didn't know that, thanks for correcting :thumbsup:

lovesh (Fri, 17 May 2019 05:31:57 GMT):
Didn't know that, thanks for correcting 👍

MALodder (Fri, 17 May 2019 05:43:45 GMT):
My project [here](https://github.com/mikelodder7/bls12-381-comparison/blob/master/src/main.rs) show the difference. Its subtle for sure. The message is the same for all signatures or each signature is associated with a different message.

Dan (Fri, 17 May 2019 13:29:53 GMT):
Cool discussion. AMCL seems like a really compact library (I see that's their main design objective). In the future I could see us wanting an optimal library as well. Mostly for validators that will be doing a lot of these options, vs clients that probably are best off using amcl. @danintel I know intel has BN curves implementations that likely use IPP acceleration. Not sure if any of the acceleration is open source though. Something we could put on the backlog.

Dan (Fri, 17 May 2019 13:54:34 GMT):
Also, btw, not shocking that it was hard to see when bls signing was introduced in amcl with this kind of commit history: https://github.com/apache/incubator-milagro-crypto/commits/master/version3/rust

MALodder (Fri, 17 May 2019 13:55:30 GMT):
😂

Dan (Fri, 17 May 2019 14:09:09 GMT):
@amundson you left a comment on https://github.com/hyperledger/ursa-rfcs/pull/8 last month. @MALodder asked for clarification in that thread.

Dan (Fri, 17 May 2019 14:13:36 GMT):
@MALodder I think we are good to go on the CI PR if you want to update the Cargo.lock commit message with the rationale.. something about providing traceability between commits, builds, and the dependencies used in the builds. I gather from the comments that was @dhuseby 's goal. https://github.com/hyperledger/ursa/pull/27/commits/4798c59731134f9a425e9b8bb1d7488ecde0e714

MALodder (Fri, 17 May 2019 14:14:20 GMT):
Sounds good. Can you approve the PR? I'll fill out that info in the PR message then merge

MALodder (Fri, 17 May 2019 14:16:33 GMT):
I updated my comments

MALodder (Fri, 17 May 2019 14:16:58 GMT):
Until you approve it @Dan the merge is blocked

Dan (Fri, 17 May 2019 14:19:38 GMT):
I was thinking to put it in the commit message for the Cargo.lock commit. That way when the next new guy on the project wonders why it's there she just has to look at the history for the file and sees the rationale.

MALodder (Fri, 17 May 2019 14:21:32 GMT):
you need me to do a rebase to amend the message or is there another method you are suggesting?

MALodder (Fri, 17 May 2019 14:21:40 GMT):
@Dan ^^

Dan (Fri, 17 May 2019 14:21:45 GMT):
yes that's what I was thinking

MALodder (Fri, 17 May 2019 14:21:50 GMT):
rebase?

Dan (Fri, 17 May 2019 14:22:00 GMT):
yes rebase and amend the message

MALodder (Fri, 17 May 2019 14:27:57 GMT):
okay here's the new commit message *The idea of checking in the cargo.lock file is for reproducible/deterministic builds. We want to track the contents of that over time so that we know exactly what dependencies were used to support specific builds of Ursa.*

MALodder (Fri, 17 May 2019 14:28:10 GMT):
@Dan ^^

MALodder (Fri, 17 May 2019 14:29:14 GMT):
pushed

MALodder (Fri, 17 May 2019 14:32:49 GMT):
if you approve it then I can merge it once the CI finishes

MALodder (Fri, 17 May 2019 14:41:13 GMT):
thanks, just waiting for CI now

Dan (Fri, 17 May 2019 14:59:54 GMT):
Cool, thanks for getting that whole PR together. That's pretty huge to actually have proper CI now!

rjones (Fri, 17 May 2019 14:59:58 GMT):
https://github.com/hyperledger/ursa/pull/27 looks like CI is done

Dan (Fri, 17 May 2019 15:01:06 GMT):
Wow and it even comes with automated @rjones CI monitoring notifications! I don't know how you did that @MALodder but hats off to you. :D

lovesh (Fri, 17 May 2019 15:06:25 GMT):
The AMCL main author told me to use this repo https://github.com/miracl/amcl. It is more recent and has the better commit history

lovesh (Fri, 17 May 2019 15:06:54 GMT):
They have had to migrate the repo

Dan (Fri, 17 May 2019 15:09:06 GMT):
Oh that looks a lot better. Are they no longer part of Apache or maybe moved out of the incubator?

lovesh (Fri, 17 May 2019 15:11:00 GMT):
Don't know whether they are part of Apache foundation or not but they are still Apache-2 licence so i was content

Dan (Fri, 17 May 2019 16:54:10 GMT):
Rust question ... if a family of structs with one or more common fields have the same method(s) on those fields is there an inheritance-ish feature to avoid reimplementing the method for each struct? I thought a default trait method implementation would be nice but traits can't use struct fields. (I see there's a postponed RFC to give traits access to fields.) Trait bounds and associated types facilitate generics behaviors but don't appear to facilitate anything with default methods operating on fields.

MALodder (Fri, 17 May 2019 17:07:50 GMT):
Traits can define `type`s which can use fields

Dan (Fri, 17 May 2019 17:14:26 GMT):
So if each struct had a name field, then I could define a trait with some sort of Name Type such that I could write a default implementation that did something like `println!(self::name);` ?

MALodder (Fri, 17 May 2019 17:20:48 GMT):
it would be something like `self::Type1::name`

Dan (Fri, 17 May 2019 17:22:28 GMT):
thx

Dan (Fri, 17 May 2019 18:03:03 GMT):
would that field still be accessible from each struct?

dhuseby (Fri, 17 May 2019 18:03:18 GMT):
I'm trying to figure out what you're asking

dhuseby (Fri, 17 May 2019 18:03:54 GMT):
generic traits?

Dan (Fri, 17 May 2019 18:05:01 GMT):
Ok, concrete example... Each struct has a bytes field. We have several as_bytes() methods that just do `self.bytes.as_slice()` Seems like it would be nice to inherit that method rather than re-implement it inside each struct that has a bytes field.

Dan (Fri, 17 May 2019 18:05:01 GMT):
Ok, concrete example... Each struct has a bytes field. Each struct implements an as_bytes() method that just does `self.bytes.as_slice()` Seems like it would be nice to inherit that method rather than re-implement it inside each struct that has a bytes field.

Dan (Fri, 17 May 2019 18:05:01 GMT):
Ok, concrete example... Each struct has a bytes field. Each struct implements an as_bytes() method that just do `self.bytes.as_slice()` Seems like it would be nice to inherit that method rather than re-implement it inside each struct that has a bytes field.

dhuseby (Fri, 17 May 2019 18:05:41 GMT):
One sec

dhuseby (Fri, 17 May 2019 18:09:36 GMT):
@Dan what you should always ask yourself first is: is there a standard way of doing this seemingly common thing?

dhuseby (Fri, 17 May 2019 18:09:45 GMT):
the answer is usually yes

Dan (Fri, 17 May 2019 18:09:53 GMT):
that is literally the question that I asked :D

dhuseby (Fri, 17 May 2019 18:10:30 GMT):
ok

dhuseby (Fri, 17 May 2019 18:10:35 GMT):
so for your as_slice thing

dhuseby (Fri, 17 May 2019 18:10:49 GMT):
What you really want to do is implement the AsRef trait

dhuseby (Fri, 17 May 2019 18:10:55 GMT):
https://doc.rust-lang.org/nightly/core/convert/trait.AsRef.html

dhuseby (Fri, 17 May 2019 18:11:13 GMT):
an example of implementing that is here: https://docs.rs/sodiumoxide/0.2.2/sodiumoxide/crypto/hash/sha256/struct.Digest.html

dhuseby (Fri, 17 May 2019 18:11:43 GMT):
do your structs have members other than the bytes?

dhuseby (Fri, 17 May 2019 18:12:17 GMT):
if they only have bytes, then you should make it a "virtual type" for a slice or Vec depending on if it is dynamically sized or not

dhuseby (Fri, 17 May 2019 18:12:50 GMT):
for instance, a Digest is just a fixed length slice

dhuseby (Fri, 17 May 2019 18:12:56 GMT):
so it is declared like this:

dhuseby (Fri, 17 May 2019 18:12:59 GMT):
pub struct Digest(pub [u8; 32]);

dhuseby (Fri, 17 May 2019 18:13:32 GMT):
which is just making a type "alias" called Digest but is really just a [u8; 32]

dhuseby (Fri, 17 May 2019 18:13:45 GMT):
did I answer your question?

dhuseby (Fri, 17 May 2019 18:14:19 GMT):
Those aren't called "virtual types". they have a name but i can't remember what it is

Dan (Fri, 17 May 2019 18:15:14 GMT):
Thanks I'll study those links.

dhuseby (Fri, 17 May 2019 18:20:37 GMT):
so, as_slice and as_bytes are also found in the standard library.

dhuseby (Fri, 17 May 2019 18:20:45 GMT):
for instance String::as_bytes()

dhuseby (Fri, 17 May 2019 18:20:55 GMT):
and Vec::as_slice)(

dhuseby (Fri, 17 May 2019 18:21:11 GMT):
but those are only implemented on standard types where it makes sense

dhuseby (Fri, 17 May 2019 18:21:41 GMT):
the official "standard" way is to implement AsRef for the converted type T

dhuseby (Fri, 17 May 2019 18:22:33 GMT):
so instead of as_bytes do AsRef<[u8]>

Dan (Fri, 17 May 2019 18:22:45 GMT):
In this case the bytes field seems to be a sort of default serialization of the struct and the as_bytes method just returns those bytes as a slice.

dhuseby (Fri, 17 May 2019 18:23:24 GMT):
oh

dhuseby (Fri, 17 May 2019 18:23:33 GMT):
serialization is a whole other can of worms

dhuseby (Fri, 17 May 2019 18:23:47 GMT):
I hate to throw this at you but https://serde.rs

dhuseby (Fri, 17 May 2019 18:24:13 GMT):
it's the "standard" way to make types SERializable/DEserializable

Dan (Fri, 17 May 2019 18:24:17 GMT):
Yeah serde is also on my read list :)

dhuseby (Fri, 17 May 2019 18:24:30 GMT):
if you follow that standard then you can serde into and out of a whole bunch of different formats

Dan (Fri, 17 May 2019 18:24:32 GMT):
especially since these structs are already deriving Serialize

dhuseby (Fri, 17 May 2019 18:24:38 GMT):
right

dhuseby (Fri, 17 May 2019 18:24:58 GMT):
most of the time you should be able to use the serde macros to autogenerate the serde glue

dhuseby (Fri, 17 May 2019 18:25:19 GMT):
just decorate the struct and members with the correct macro declarations and everything gets generated

Dan (Fri, 17 May 2019 18:29:32 GMT):
If you could suggest one project with really well done rust (to look at for examples of "the right way") what would that be?

dhuseby (Fri, 17 May 2019 18:29:48 GMT):
right way to do what?

Dan (Fri, 17 May 2019 18:29:56 GMT):
as much as possible ;)

dhuseby (Fri, 17 May 2019 18:30:07 GMT):
the sodiumoxide crate is perfect and shows lots of different tricks

Dan (Fri, 17 May 2019 18:30:22 GMT):
cool, thx

dhuseby (Fri, 17 May 2019 18:30:28 GMT):
https://crates.io/crates/sodiumoxide

dhuseby (Fri, 17 May 2019 18:31:26 GMT):
there is one trick not in there that I learned a few months ago that i absolutely love to use when working with the aliased array types (e.g. Digest, Nonce, etc)

dhuseby (Fri, 17 May 2019 18:31:49 GMT):
use destructuring when you need to manipulate the bytes in an instance of those types

dhuseby (Fri, 17 May 2019 18:32:02 GMT):
let me show you a gist

Dan (Fri, 17 May 2019 18:32:18 GMT):
Ok, take it easy, I'm still getting comfortable with basics :flushed:

rjones (Fri, 17 May 2019 18:32:35 GMT):
the most important question: vi or emacs?

Dan (Fri, 17 May 2019 18:32:40 GMT):
lol

rjones (Fri, 17 May 2019 18:33:00 GMT):
I'm creating a custom user tag for you chat wide so answer carefully

dhuseby (Fri, 17 May 2019 18:33:37 GMT):
@Dan, check this out

Dan (Fri, 17 May 2019 18:38:50 GMT):
I created a custom editor inside pine so I can simultaneously spam and code

rjones (Fri, 17 May 2019 18:39:30 GMT):
I too program by banging rocks together and causing piezo electric events

Dan (Fri, 17 May 2019 18:40:31 GMT):
you owe me patent royalties then

Dan (Fri, 17 May 2019 18:40:31 GMT):
I owe you patent royalties then

dhuseby (Fri, 17 May 2019 18:41:36 GMT):
https://gist.github.com/dhuseby/b657070f3f7f99f76a13476ffa3ca0eb

dhuseby (Fri, 17 May 2019 18:41:54 GMT):
@Dan ^^^

dhuseby (Fri, 17 May 2019 18:42:25 GMT):
destructuring trick to get a mutable reference to the "inner" slice for types that are just type aliases over slices

Dan (Fri, 17 May 2019 18:45:38 GMT):
interesting :thinking: . thanks

dhuseby (Fri, 17 May 2019 18:46:22 GMT):
note that the curly braces are required to keep the borrow checker happy

dhuseby (Fri, 17 May 2019 18:47:02 GMT):
they define the lifespan of the 'noncebytes' reference

dhuseby (Fri, 17 May 2019 18:55:42 GMT):
@Dan wait until you get to writing your own macros

dhuseby (Fri, 17 May 2019 18:55:49 GMT):
:rofl:

dhuseby (Fri, 17 May 2019 18:56:05 GMT):
you'll suddenly find yourself holding a razor sharp katana

Dan (Fri, 17 May 2019 18:56:12 GMT):
don't tempt me

dhuseby (Fri, 17 May 2019 18:56:57 GMT):
here's a crate that is a parser generator implemented entirely in rust macros

dhuseby (Fri, 17 May 2019 18:56:58 GMT):
https://docs.rs/nom/4.2.3/nom/

hartm (Fri, 17 May 2019 19:41:25 GMT):
@dhuseby Can you keep a doc or list somewhere of these comments? While posting them in chat is nice, I suspect others will have the same questions. It has been very useful for me to read through this stuff as well, as I am obviously not on the same level of Rust as people like you or Mike.

MALodder (Fri, 17 May 2019 19:45:08 GMT):
Destructuring is nice. Most of the time @Dan if I need to do what you’re asking I use traits with types or macros. Both of those usually get the job done

Dan (Fri, 17 May 2019 20:35:18 GMT):
Say, are we going to always commit cargo.lock or just ahead of release builds?

Dan (Fri, 17 May 2019 20:35:18 GMT):
Say, are we going to always commit cargo.lock or just ahead of release builds.

Dan (Fri, 17 May 2019 21:40:59 GMT):
It was a pain to rebase and locally test without committing Cargo.lock so I went ahead and did that for the PR I'm working on.

MALodder (Fri, 17 May 2019 23:27:44 GMT):
I just update it prior to a release.

MALodder (Fri, 17 May 2019 23:27:57 GMT):
But if you need to update for a feature I’m okay with it

VipinB (Sun, 19 May 2019 16:42:01 GMT):
nom is great; I was playing around with it for a parser I wrote for Michael's forbes article in Rust, converts the forbes article into a spreadsheet (actually csv) using nom

alexmatson (Sun, 19 May 2019 23:42:48 GMT):
Has joined the channel.

toddinpal (Mon, 20 May 2019 18:12:59 GMT):
Has joined the channel.

Dan (Tue, 21 May 2019 04:58:07 GMT):
conflict with sovrin crypto tomorrow

MALodder (Tue, 21 May 2019 13:50:42 GMT):
@Dan you have two approvals

MALodder (Tue, 21 May 2019 13:50:46 GMT):
for your PR now

Dan (Tue, 21 May 2019 14:02:23 GMT):
Thanks for the quick reviews! I will see if there's a more useful way to test serialization otherwise, I will just use the deserialization test as suggested. Probably get some time to look at that this afternoon.

MALodder (Tue, 21 May 2019 18:16:55 GMT):
I added appveyor to the CI process [here](https://github.com/hyperledger/ursa/pull/29)

MALodder (Tue, 21 May 2019 18:17:17 GMT):
anyone know the helpdesk email address to get the appveyor webhook turned on?

MALodder (Tue, 21 May 2019 18:23:06 GMT):
I found it.

cam-parra (Tue, 21 May 2019 20:55:05 GMT):
alright guys I am back :)

rjones (Tue, 21 May 2019 22:22:52 GMT):
@MALodder https://github.com/hyperledger/ursa/settings/installations

MALodder (Tue, 21 May 2019 22:29:13 GMT):
it says I don't have access to that

MALodder (Tue, 21 May 2019 22:29:33 GMT):
@rjones ^^

MALodder (Tue, 21 May 2019 22:29:39 GMT):
but I believe you

rjones (Tue, 21 May 2019 22:29:50 GMT):
oh bummer. Yeah I added it

rjones (Tue, 21 May 2019 22:38:35 GMT):

appveyor.png

rjones (Tue, 21 May 2019 22:40:00 GMT):
is there more I need to do to enable it?

MALodder (Tue, 21 May 2019 22:40:58 GMT):
I had to go to appveyor.com and add the project

MALodder (Tue, 21 May 2019 22:41:08 GMT):
https://ci.appveyor.com/project/mikelodder7/ursa/build/job/06i18bxoajlo81wy

MALodder (Tue, 21 May 2019 22:41:49 GMT):
someone with rights to create projects on behalf of hyperledger will have to do it

rjones (Tue, 21 May 2019 22:42:30 GMT):
ah OK. that would be me, but I need to put on a different hat. Is it crucial this happens today?

MALodder (Tue, 21 May 2019 22:48:26 GMT):
no

rjones (Tue, 21 May 2019 22:57:47 GMT):
https://ci.appveyor.com/project/ryjones/ursa building along

MALodder (Wed, 22 May 2019 02:02:38 GMT):
Odd the x86 one didn’t work

fz (Wed, 22 May 2019 03:55:51 GMT):
Has joined the channel.

MALodder (Wed, 22 May 2019 12:18:19 GMT):
For secp256k1.

Dan (Wed, 22 May 2019 13:57:25 GMT):
i haven't worked with appveyor before, is this like a bakeoff with travis or is it doing a different job?

MALodder (Wed, 22 May 2019 14:00:50 GMT):
appveyor is specialized for CI windows

MALodder (Wed, 22 May 2019 14:01:02 GMT):
travis-ci is *nix based

MALodder (Wed, 22 May 2019 14:01:17 GMT):
on that note. I can't get secp256k1 to work for 32-bit windows

Dan (Wed, 22 May 2019 14:02:39 GMT):
fine by me if we keep a small list of supported OS's. I don't know how many people are running 32 bit anything? (also I don't know a lot of people)

Dan (Wed, 22 May 2019 14:03:06 GMT):
personally I moved to 33 bits years ago.

MALodder (Wed, 22 May 2019 14:03:10 GMT):
I vote to not support it, here's why 1- Anyone using Windows these days is typically using 64-bit 2- Ursa can compile to 32-bit arm both iOS and Android. I just tried it 3- Ursa can compile to 32-bit on linux 4- Unless someone has a compelling reason for 32 bit windows, I'm going to remove it from the settings file

MALodder (Wed, 22 May 2019 14:06:13 GMT):
I just submitted a PR for it, the current appveyor will fail for 32 bit but we should still merge it anyway then we should be good

MALodder (Wed, 22 May 2019 14:06:21 GMT):
It looks like its running properly now

MALodder (Wed, 22 May 2019 14:06:29 GMT):
when a PR comes in

MALodder (Wed, 22 May 2019 14:13:31 GMT):
it looks like its using the new appveyor settings nice

rjones (Wed, 22 May 2019 15:19:52 GMT):
@Dan I started on a 36 bit wide computer

JonGeater (Wed, 22 May 2019 15:58:56 GMT):
I spent a lot of time in 33-bit and 40-bit land when I was at ARM

VipinB (Wed, 22 May 2019 17:23:35 GMT):
Video of my talk about Ursa at Consensus/Construct 2019 now online: at Coindesk . Strangely it is called Hyperledger: Welcome to the Greenhouse . Not Hyperledger Ursa: A new kind of crypto library which was the topic of the talk.

rjones (Wed, 22 May 2019 17:50:28 GMT):
@MALodder https://ci.appveyor.com/project/hyperledger/ursa

MALodder (Wed, 22 May 2019 17:52:27 GMT):
🎉

rjones (Wed, 22 May 2019 17:56:14 GMT):
luckily - no name squatters. I think we should probably have a different version numbering scheme - can that be set in the .yml? I'd rather not have them start at 1.0 for obvious reasons :)

JonGeater (Wed, 22 May 2019 18:11:30 GMT):
Is this the obvious reason? `Compiling ursa v0.1.1 (/Users/jag/Projects/ursa/libursa)`

JonGeater (Wed, 22 May 2019 18:11:35 GMT):
;-)

JonGeater (Wed, 22 May 2019 18:15:23 GMT):
Question: why do we have both 'libursa/tests/{lorem}.rs' and also a collection of 'libursa/bin/test_{ipsum}.rs'?

JonGeater (Wed, 22 May 2019 18:15:52 GMT):
This seems morally wrong

rjones (Wed, 22 May 2019 18:19:12 GMT):
@JonGeater also: https://ci.appveyor.com/project/hyperledger/ursa/history is version 1.0.1 which might annoy the TSC :)

JonGeater (Wed, 22 May 2019 18:25:01 GMT):
Shouldn't that PR be called "Don't build 32-bit Windows"? Otherwise it seems like it's a Win64 exclusive

Dan (Wed, 22 May 2019 23:51:41 GMT):

Clipboard - May 22, 2019 6:51 PM

Dan (Wed, 22 May 2019 23:51:52 GMT):
what do we think about getting rid of this configuration in the repo and instead making good use of the "Rebase and merge" button.

Dan (Wed, 22 May 2019 23:52:11 GMT):
I prefer that to littering the history with merge commits

rjones (Wed, 22 May 2019 23:53:11 GMT):
I can make it so rebase and merge is the available option

Dan (Wed, 22 May 2019 23:55:32 GMT):
that would be kewl

rjones (Wed, 22 May 2019 23:57:05 GMT):
I think you need a HIPE and a vote of the TSC though

Dan (Wed, 22 May 2019 23:59:57 GMT):
well of course, but only after the governing board issues a non-binding resolution in favor of this approach

rjones (Thu, 23 May 2019 00:08:47 GMT):
done. I hope that's totally uncontroversial

Dan (Thu, 23 May 2019 00:11:54 GMT):
I still see the "this branch is out of date" thing - it won't let me click the `rebase and merge` button.

rjones (Thu, 23 May 2019 00:19:50 GMT):
link me a pr

rjones (Thu, 23 May 2019 00:21:57 GMT):
https://github.com/hyperledger/ursa/pull/28 what do you see?

Dan (Thu, 23 May 2019 02:10:53 GMT):
oh, you merged master into that branch? I was trying to figure out if there was a way to avoid that.

rjones (Thu, 23 May 2019 02:12:23 GMT):
oh. I clicked the "rebase" button

rjones (Thu, 23 May 2019 02:12:57 GMT):
I didn't click `merge`

rjones (Thu, 23 May 2019 02:13:38 GMT):
do you have a `revert` button? I do

rjones (Thu, 23 May 2019 02:14:16 GMT):
if you had clicked `rebase and merge` you would have had the same result, I suspect

Dan (Thu, 23 May 2019 02:14:51 GMT):
hmm...

Dan (Thu, 23 May 2019 02:16:33 GMT):
that's weird... the commit history for the PR shows a merge and I had seen this message in the comments view of the PR which is why I thought you had merged.

Dan (Thu, 23 May 2019 02:16:35 GMT):

Clipboard - May 22, 2019 9:16 PM

Dan (Thu, 23 May 2019 02:17:16 GMT):
but the commit history for master with these commits laid on top (via the 'rebase and merge' ) doesn't include the merge commit that's in the PR.

rjones (Thu, 23 May 2019 02:18:41 GMT):
I only clicked the "rebase" button

rjones (Thu, 23 May 2019 02:24:46 GMT):
I think It's a clean rebase.

rjones (Thu, 23 May 2019 02:27:03 GMT):
If you look here: https://github.com/hyperledger/ursa/pull/28/commits/9e52f34cd67a66c9efba235c41d28fbd469689b1

rjones (Thu, 23 May 2019 02:27:43 GMT):
```mbp-2:ursa ry$ git status -v On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean mbp-2:ursa ry$ git log | grep -i 9e52f34cd67a66c9efba235c41d28fbd469689b1 mbp-2:ursa ry$ ```

rjones (Thu, 23 May 2019 02:28:35 GMT):
if you want to see the merge into your change: https://github.com/hyperledger/ursa/commit/9e52f34cd67a66c9efba235c41d28fbd469689b1

Dan (Thu, 23 May 2019 13:19:33 GMT):
yeah it certainly seems to be a clean rebase. must just be something weird about the github interface and/or how it's managing the rebase under the hood.

rjones (Thu, 23 May 2019 13:36:57 GMT):
GitHub has a degenerate UI

Dan (Thu, 23 May 2019 13:41:01 GMT):
I just hope it doesn't get as bad as gerrit.

rjones (Thu, 23 May 2019 13:42:37 GMT):
It would be bad. Thankfully, gerrithub already exists

MALodder (Thu, 23 May 2019 15:13:10 GMT):
Where should the artifacts from a CD pipeline be deployed?

MALodder (Thu, 23 May 2019 15:14:55 GMT):
specifically libursa.so, libursa.dylib, libursa.dll

MALodder (Thu, 23 May 2019 15:15:14 GMT):
deb, rpm, msi files

Dan (Thu, 23 May 2019 15:58:33 GMT):
in sawtooth we only officially produce debs and those go into an ubunto repo (i.e. apt not a git repo) Not sure what to do in this case given there's so many artifacts. Maybe a good question to float in the CI/CD committee? I think they meet tomorrow morning.

cam-parra (Thu, 23 May 2019 16:39:11 GMT):
I thought hyperledger had it's own artifact repo?

rjones (Thu, 23 May 2019 16:44:31 GMT):
we have nexus3

rjones (Thu, 23 May 2019 16:44:31 GMT):
we have nexus3 https://nexus3.hyperledger.org/ also nexus2: https://nexus.hyperledger.org/

MALodder (Thu, 23 May 2019 17:03:24 GMT):
RustCrypto team just release a general purpose API for signatures that we could use https://github.com/RustCrypto/signatures

cam-parra (Thu, 23 May 2019 17:09:42 GMT):
Have you audited the code base?

MALodder (Thu, 23 May 2019 17:10:27 GMT):
its just traits

MALodder (Thu, 23 May 2019 17:10:35 GMT):
API definition

MALodder (Thu, 23 May 2019 17:10:47 GMT):
no actual code

MALodder (Thu, 23 May 2019 17:10:53 GMT):
nothing to audit

MALodder (Thu, 23 May 2019 17:11:03 GMT):
its very small but I like the interface definitions

cam-parra (Thu, 23 May 2019 17:12:58 GMT):
Silly me. I browsed through it and it looks very clean

kdenhartog (Fri, 24 May 2019 07:38:33 GMT):
https://t.co/mobVot8zgB?amp=1

kdenhartog (Fri, 24 May 2019 07:39:17 GMT):
Microsoft Research paper just released of a zkSNARK without a trusted setup

lovesh (Fri, 24 May 2019 10:57:46 GMT):
From Figure 1 in paper, the proving time seems worse than Bulletproofs (n.logn vs n) in some cases or same at best. You can trade-off proof size with verification time. I haven't looked at Dmitry improvement paper in detail but i think it offers a similar tradeoff (originally described in an older paper from Bootle to build ZK proof for arithematic circuits). The above paper generalizes the tradeoff whereas Dmitry's paper uses a square root tradeoff (It probably can be generalized too). So its not exciting in terms of the results. Maybe something can be learned from the techniques.

lovesh (Fri, 24 May 2019 10:58:01 GMT):
From Figure 1 in paper, the proving time seems worse than Bulletproofs (n.logn vs n) in some cases or same at best. You can trade-off proof size with verification time. I haven't looked at Dmitry improvement paper in detail but i think it offers a similar tradeoff (originally described in an older paper from Bootle to build ZK proof for arithematic circuits). The above paper generalizes the tradeoff whereas Dmitry's paper uses a square root tradeoff (It probably can be generalized too). So its not exciting in terms of the results. Maybe something can be learned from the techniques.

Dan (Fri, 24 May 2019 20:27:07 GMT):
Thanks for the link @kdenhartog

Dan (Fri, 24 May 2019 20:27:21 GMT):
Is there a generalization across these for avoiding the CRS?

cam-parra (Fri, 24 May 2019 21:06:17 GMT):
@lovesh Could you explain why you'd want to do a proof-size and verification time trade off?

Dan (Sat, 25 May 2019 14:22:15 GMT):
in a blockchain you generally want to minimize what you have to send and verify, but there's a lot of other applications that have nothing to do with blockchains. Even with a blockchain you might have small clients and want to minimize the prover cost.

lovesh (Sat, 25 May 2019 21:07:18 GMT):
@cam-parra If you want to persist the proof for long periods of time, you want to minimize the proof size

alexmatson (Sun, 26 May 2019 11:49:42 GMT):
Hi everyone, I'm interested in familiarizing myself with the Ursa codebase. At the moment, I have a couple of questions: 1. I noticed that there seem to be two major parts to `libursa` -- `BLS` and `CL`. What do these stand for? 2. Does the `libursa` C API currently provide functions for ed25519 signing? Thanks!

brentzundel (Sun, 26 May 2019 12:17:23 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=AwucufHXFLL8j9Whd) @alexmatson I believe I can answer the first question. `BLS` is the Boneh-Lynn-Shachem signature. `CL` is the Camenisch-Lysyanskaya signature.

MALodder (Mon, 27 May 2019 15:54:28 GMT):
The answer to #2 is yes

alexmatson (Mon, 27 May 2019 19:39:22 GMT):
@MALodder I can't seem to find them. I see FFI bindings for BLS and CL, but not for ed25519. Am I looking in the right place? (`libursa/src/ffi/`).

MALodder (Wed, 29 May 2019 00:05:49 GMT):
@alexmatson Sorry I misunderstood, no we don't have FFI for ed25519. But you can use libsodium for that

MALodder (Wed, 29 May 2019 00:05:56 GMT):
what's your use case

hartm (Wed, 29 May 2019 04:21:09 GMT):
@here Just a reminder of tomorrow morning's meeting! Hope to talk to many of you tomorrow. Thanks!

cam-parra (Wed, 29 May 2019 13:46:37 GMT):
@MALodder is there an updated agenda?

MALodder (Wed, 29 May 2019 13:46:47 GMT):
see the wiki

danintel (Wed, 29 May 2019 14:01:06 GMT):
Zoom meeting link https://zoom.us/my/hyperledger.community

MALodder (Wed, 29 May 2019 15:13:26 GMT):
From the call this morning, I'll reiterate here, if there is any feature or platform artifact that teams or individuals need from ursa, unless we know about we will move forward with the needs we do know about

MALodder (Wed, 29 May 2019 15:20:15 GMT):
As request on the ursa call this morning, here is the initial document on ZKLang https://docs.google.com/document/d/1CLdkd70Mfa-AhnrqwTMVwBdF-HdvVNBiOKcq13lPstY/edit?usp=sharing

alexmatson (Wed, 29 May 2019 15:21:01 GMT):
I was recently accepted into Hyperledger's internship program. My upcoming project is to integrate Ursa's crypto into HL Iroha, and at the moment I'm just trying to get a feel for what the details of that integration are going to look like. Iroha is a C++ codebase and mainly uses ed25519 with SHA-3 (I know the SHA-3 part is also going to be a separate challenge here) as their signature scheme.

MALodder (Wed, 29 May 2019 15:22:53 GMT):
Okay, I see, Well we can work on this. This is a pretty easy feature request

MALodder (Wed, 29 May 2019 15:24:16 GMT):
what's the motive to use SHA3 over SHA2 for the signature

alexmatson (Wed, 29 May 2019 15:35:23 GMT):
My mentor told me they chose SHA-3 because it is the latest standard, and it would be easier to start with SHA-3 than migrate it to later if they started with SHA-2. He also said it is more resistant to birthday attacks.

MALodder (Wed, 29 May 2019 15:35:40 GMT):
it is but its slower

MALodder (Wed, 29 May 2019 15:48:37 GMT):
So ursa currently uses the dalek library to do Ed25519

MALodder (Wed, 29 May 2019 15:49:08 GMT):
you can use SHA3 to hash the message then use SHA2 to compute the signature

MALodder (Wed, 29 May 2019 15:49:27 GMT):
But there isn't a library right now that uses any 512-bit hash to compute ed25519

MALodder (Wed, 29 May 2019 15:49:36 GMT):
you would have to write that by hand

MALodder (Wed, 29 May 2019 15:49:49 GMT):
libsodium uses Sha2 as does Dalek

MALodder (Wed, 29 May 2019 15:51:54 GMT):
So you should ask if that is still okay

cam-parra (Wed, 29 May 2019 15:54:18 GMT):
Does the fabric project have any plans for adopting URSA?

alexmatson (Wed, 29 May 2019 15:58:46 GMT):
Currently, our tentative plan is to modify dalek and make the choice of hash configurable between SHA2/SHA3 (similar to this previous PR submitted to the library https://github.com/dalek-cryptography/ed25519-dalek/pull/73). Then raise an issue/PR and try to convince the maintainers that this is beneficial enough to merge it upstream.

alexmatson (Wed, 29 May 2019 15:59:08 GMT):
Admittedly, I'm somewhat of a beginner to cryptography so I think I need to do some research into your suggestion of computing the signature with SHA-2 but having the message hashed with SHA-3. Do you think this would provide the same results as using SHA-3 directly in the signing functions?

MALodder (Wed, 29 May 2019 15:59:33 GMT):
most of the crypto community that I'm aware of are refusing to adopt sha3 for now because its significantly slower

MALodder (Wed, 29 May 2019 15:59:55 GMT):
No it would not

alexmatson (Wed, 29 May 2019 16:02:45 GMT):
Hm, I see. Thank you for taking the time to help me, I appreciate it. I'll talk to my mentor more about different options. The problem I see at the moment is I think Iroha is already using SHA-3, so modifying the signature scheme might break existing use cases.

MALodder (Wed, 29 May 2019 16:04:20 GMT):
They’re using ed25519 with sha3 can you point me to their source code?

alexmatson (Wed, 29 May 2019 16:06:03 GMT):
https://github.com/hyperledger/iroha/tree/master/shared_model/cryptography/ed25519_sha3_impl

MALodder (Wed, 29 May 2019 19:16:10 GMT):
oh man, it looks to me like the eddsa isn't even implemented correctly

MALodder (Wed, 29 May 2019 19:28:09 GMT):
they are using Sha3_256 to hash the message then computing the signature on that

MALodder (Wed, 29 May 2019 19:28:17 GMT):
its not true ed25519

MALodder (Wed, 29 May 2019 19:28:19 GMT):
with sha3

MALodder (Wed, 29 May 2019 19:29:43 GMT):
if that's what iroha needs the ursa can do that without needing to modify the dalek libraries

Dan (Wed, 29 May 2019 19:33:50 GMT):
what do you mean it's not true ed25519 with sha3?

MALodder (Wed, 29 May 2019 19:36:17 GMT):
EdDSA says to compute a 512-bit hash from the nonce and the message to compute the scalar *r*, compute the point *R* by multiplying the base point by *r*. Then compute the 512-bit hash k that includes R, the public key and the message. Then multiply the private key by *k* and add it to *r* to arrive at *s*. The signature is R, s

MALodder (Wed, 29 May 2019 19:36:42 GMT):
True Ed25519 would use sha3 for all computations of the 512 bit hash.

MALodder (Wed, 29 May 2019 19:37:04 GMT):
Iroha is just computing the Sha3_256 hash of the message then passing that to the signing algorithm

MALodder (Wed, 29 May 2019 19:37:18 GMT):
The signing algorithm is using Sha2_512

Dan (Wed, 29 May 2019 19:37:36 GMT):
oh that's weird

MALodder (Wed, 29 May 2019 19:37:40 GMT):
right

MALodder (Wed, 29 May 2019 19:38:22 GMT):
Most crypto engineers I talk to aren't using sha3 because 1- Sha2 is still has adequate security 2- Sha3 is much slower than Sha2

MALodder (Wed, 29 May 2019 19:38:39 GMT):
So I don't know why they didn't just use the default

MALodder (Wed, 29 May 2019 19:39:16 GMT):
It would be wise for iroha to add a domain separation string since they are hashing the message first

Dan (Wed, 29 May 2019 19:39:20 GMT):
if you still have it handy where's the point that they use sha2_512?

MALodder (Wed, 29 May 2019 19:39:59 GMT):
They are calling an external library ed25519

MALodder (Wed, 29 May 2019 19:40:28 GMT):
I don't which implementation they are pulling because I can't find it in any of there build scripts

MALodder (Wed, 29 May 2019 19:40:54 GMT):
I'm making an assumption that that library is correctly implementing the signature, which uses Sha2_512

Dan (Wed, 29 May 2019 19:41:22 GMT):
ok. this would all be easier if there was a single hyperledger project that consistently implemented crypto functions

MALodder (Wed, 29 May 2019 19:41:38 GMT):
right

MALodder (Wed, 29 May 2019 19:41:39 GMT):
https://github.com/hyperledger/iroha/blob/master/shared_model/cryptography/ed25519_sha3_impl/internal/ed25519_impl.cpp#L6

MALodder (Wed, 29 May 2019 19:41:45 GMT):
if only one existed

MALodder (Wed, 29 May 2019 19:41:48 GMT):
oh wait

MALodder (Wed, 29 May 2019 19:41:52 GMT):
this is why ursa was created

Dan (Wed, 29 May 2019 19:42:59 GMT):
oh! ;)

alexmatson (Thu, 30 May 2019 15:46:35 GMT):
@MALodder I did some digging, and I think that external library they're using is their own implementation, which uses SHA3_512 within the signature as well: https://github.com/hyperledger/iroha-ed25519/

MALodder (Thu, 30 May 2019 15:54:58 GMT):
yep that does look like it

MALodder (Thu, 30 May 2019 16:29:21 GMT):
Still its not advisable to implement custom signatures solely that Sha3 is newer than Sha2

MALodder (Thu, 30 May 2019 16:31:05 GMT):
[Here](https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/?include_text=1) is the latest draft for MLS that @kdenhartog wants feedback on

kdenhartog (Thu, 30 May 2019 19:08:51 GMT):
Thank you @MALodder I still wasn't able to get around to that yet.

lovesh (Tue, 04 Jun 2019 08:01:31 GMT):
A lot of methods in indy-crypto's as well as Ursa's FFI for anoncreds functions *return success even if there is an error*. This should not be the case. Or am i missing something? Have a look at this commit where i have fixed them in Ursa https://github.com/lovesh/ursa/commit/f8e04193e82bbe6737b1b2962ec7d019aeca0aa5.

the_identity_guy (Thu, 06 Jun 2019 02:09:12 GMT):
Has joined the channel.

lebdron (Thu, 06 Jun 2019 15:22:36 GMT):
Has joined the channel.

MALodder (Thu, 06 Jun 2019 19:43:48 GMT):
New PR https://github.com/hyperledger/ursa/pull/33

MALodder (Thu, 06 Jun 2019 19:44:37 GMT):
If it works, then Iroha can use Ursa

MALodder (Thu, 06 Jun 2019 19:44:55 GMT):
I say if because I don't know how Iroha will use the APIs so this was a initial stab

Dan (Thu, 06 Jun 2019 20:43:42 GMT):
Does indy actively use the CL based anon creds?

Dan (Thu, 06 Jun 2019 20:46:16 GMT):
@MALodder looks like travis failed. maybe on cargo fmt.

MALodder (Thu, 06 Jun 2019 20:46:34 GMT):
> Does indy actively use the CL based anon creds? yes

MALodder (Thu, 06 Jun 2019 20:47:08 GMT):
>MALodder looks like travis failed. maybe on cargo fmt. Right I got an email back from the ffi-support crate authors saying what I'm doing for inputs is not considered safe

MALodder (Thu, 06 Jun 2019 20:47:16 GMT):
so I need to rework it

MALodder (Thu, 06 Jun 2019 20:47:21 GMT):
I CC'd you on that email

MALodder (Thu, 06 Jun 2019 20:47:26 GMT):
let me know if you didn't get it

Dan (Thu, 06 Jun 2019 20:47:34 GMT):
it's in the recent pile ;)

Dan (Thu, 06 Jun 2019 20:48:11 GMT):
just wanted you to know that travis barfed in case you were waiting on it.

cam-parra (Thu, 06 Jun 2019 20:48:40 GMT):
@MALodder I have a github account again! Could we remove the user cam-parra from ursa maintainers and add mac-arrap ?

MALodder (Thu, 06 Jun 2019 20:48:49 GMT):
sure

cam-parra (Thu, 06 Jun 2019 20:50:07 GMT):
I can do visual confirmation if needed

MALodder (Thu, 06 Jun 2019 20:53:24 GMT):
anyone remember the link to find the ursa maintainers list

MALodder (Thu, 06 Jun 2019 20:54:22 GMT):
is this it? https://github.com/orgs/hyperledger/teams/ursa-maintainers/members

cam-parra (Thu, 06 Jun 2019 20:54:53 GMT):
I believe that's what @rjones gave us

cam-parra (Thu, 06 Jun 2019 20:56:07 GMT):
Could @mac-arrap also be added to the hyperledger organization?

MALodder (Thu, 06 Jun 2019 20:57:36 GMT):
Cam, it says you aren't a member of hyperledger yet

MALodder (Thu, 06 Jun 2019 20:57:46 GMT):
so when you are then I can add you back in

cam-parra (Thu, 06 Jun 2019 20:59:14 GMT):
No worries I think that @rjones or @dhuseby can add me

dhuseby (Thu, 06 Jun 2019 20:59:43 GMT):
@cam-parra do you have 2FA setup?

dhuseby (Thu, 06 Jun 2019 20:59:46 GMT):
do that first

cam-parra (Thu, 06 Jun 2019 21:00:22 GMT):
Will do.... gonna make sure to save these keys on all my devices now :rolling_on_the_floor_laughing:

dhuseby (Thu, 06 Jun 2019 21:01:15 GMT):

kHZygKMeGRMzCA4yEjsS.jpeg

dhuseby (Thu, 06 Jun 2019 21:01:29 GMT):
@cam-parra I'm seeing you in the HL org already on github

dhuseby (Thu, 06 Jun 2019 21:01:35 GMT):
it says you have 2FA enabled

cam-parra (Thu, 06 Jun 2019 21:02:31 GMT):
I lost access to that account due to losing codes to 2FA (were on on my EV machine) so I had them remove my email from that account and I made a new one

dhuseby (Thu, 06 Jun 2019 21:02:57 GMT):
you can't have them recover your account?

dhuseby (Thu, 06 Jun 2019 21:03:00 GMT):
ok

dhuseby (Thu, 06 Jun 2019 21:03:03 GMT):
whatever

dhuseby (Thu, 06 Jun 2019 21:03:09 GMT):
what's your new github username?

cam-parra (Thu, 06 Jun 2019 21:03:39 GMT):
no they refuse to let me recover it... kinda dumb

cam-parra (Thu, 06 Jun 2019 21:05:07 GMT):
my new account is mac-arrap 2fa is enabled

dhuseby (Thu, 06 Jun 2019 21:11:39 GMT):
lol

dhuseby (Thu, 06 Jun 2019 21:11:42 GMT):
ok one sec

dhuseby (Thu, 06 Jun 2019 21:12:29 GMT):
@cam-parra invite sent

cam-parra (Thu, 06 Jun 2019 21:14:09 GMT):
accepted now @MALodder can work his magic

cam-parra (Thu, 06 Jun 2019 21:30:19 GMT):
Alright we are good to go. I am working on transferring ownership of the python-ursa code right now

dhuseby (Thu, 06 Jun 2019 21:43:51 GMT):
right

dhuseby (Thu, 06 Jun 2019 21:43:54 GMT):
awesome

MALodder (Thu, 06 Jun 2019 22:01:03 GMT):
I updated PR 33. It has a safer method for FFI for now

MALodder (Thu, 06 Jun 2019 22:01:21 GMT):
once ffi-support crate adds FfiSlice or something like it we can switch to that

MALodder (Thu, 06 Jun 2019 22:01:33 GMT):
but that interface should be enough for Iroha to use ursa

alexmatson (Thu, 06 Jun 2019 22:06:00 GMT):
Wow, thanks @MALodder! Those bindings should work well :)

MALodder (Thu, 06 Jun 2019 22:07:20 GMT):
I believe Ursa is now the only project to expose the Dalek libraries over FFI

MALodder (Thu, 06 Jun 2019 22:08:03 GMT):
I might try a little later tonight to see if I can eliminate Pointers and size values

MALodder (Thu, 06 Jun 2019 22:08:53 GMT):
But for now Iroha should be good to go

MALodder (Thu, 06 Jun 2019 22:09:09 GMT):
Once That PR is acceptable of course

circlespainter (Fri, 07 Jun 2019 11:02:14 GMT):
Has joined the channel.

Dan (Mon, 10 Jun 2019 13:25:07 GMT):
@hartm did you initialize a TSC update for ursa?

MALodder (Mon, 10 Jun 2019 14:04:43 GMT):
@Dan I can contribute to the quarterly report, do you have a doc somewhere to edit?

Dan (Mon, 10 Jun 2019 14:12:20 GMT):
that's what i was wondering if hart had initialized. It should be somewhere like here: https://wiki.hyperledger.org/display/HYP/TSC+Project+Updates

hartm (Mon, 10 Jun 2019 18:42:41 GMT):
@Dan Not yet, but I'll do it today.

hartm (Tue, 11 Jun 2019 16:01:38 GMT):
@rjones I'm having a hard time getting the meeting agenda to show up on the menu in the wiki page. Is there a known bug on this? My agenda isn't showing up in the hierarchy, and when I open it and click "view in hierarchy" the website hangs. Thanks!

rjones (Tue, 11 Jun 2019 17:09:53 GMT):
@hartm could you give me a link to the page that isn't showing up?

Dan (Tue, 11 Jun 2019 18:34:59 GMT):
@hartm there should be a template you can use too:

Dan (Tue, 11 Jun 2019 18:35:09 GMT):

agenda template

hartm (Tue, 11 Jun 2019 20:20:02 GMT):

wiki-error.png

hartm (Tue, 11 Jun 2019 20:20:18 GMT):
Note the arrow pointing to the "infinite ring of delay".

rjones (Tue, 11 Jun 2019 20:29:48 GMT):
weird

Dan (Tue, 11 Jun 2019 20:49:36 GMT):
What's the maximum number of gates that would be relevant for use cases people are looking at?

Dan (Tue, 11 Jun 2019 20:51:02 GMT):
80/20 rule is fine. I'm looking for a pragmatic upper bound.

hartm (Wed, 12 Jun 2019 00:22:40 GMT):
Somehow our meeting slot got deleted from the calendar, and an email cancelling our meeting was sent out. This is not what we want, and we would like to have our usual meeting tomorrow morning. Can anyone from the LF advise on this? Thanks! @rjones @Silona @dhuseby

dhuseby (Wed, 12 Jun 2019 00:23:21 GMT):
yup

Silona (Wed, 12 Jun 2019 00:23:29 GMT):
send email to community-architects@hyperledger.org

dhuseby (Wed, 12 Jun 2019 00:23:48 GMT):
@hartm @Silona beat me to it

hartm (Wed, 12 Jun 2019 00:23:53 GMT):
OK, thanks!

dhuseby (Wed, 12 Jun 2019 00:23:54 GMT):
i was about to say that

hartm (Wed, 12 Jun 2019 00:24:03 GMT):
Will they be able to fix it by tomorrow morning?

dhuseby (Wed, 12 Jun 2019 00:24:34 GMT):
@hartm if you set up the calendar event and invite community-architects@hyperledger.org one of us can easily copy it to the hyperledger community calendar

dhuseby (Wed, 12 Jun 2019 00:24:44 GMT):
set it up now

dhuseby (Wed, 12 Jun 2019 00:24:53 GMT):
I'll copy it immediately

hartm (Wed, 12 Jun 2019 00:25:15 GMT):
OK, thanks!

hartm (Wed, 12 Jun 2019 00:25:27 GMT):
Can you add it to the zoom schedule?

hartm (Wed, 12 Jun 2019 00:25:39 GMT):
I guess I set it up on google calendar?

hartm (Wed, 12 Jun 2019 00:29:17 GMT):
Done. I can't add in the zoom conferencing info though.

dhuseby (Wed, 12 Jun 2019 00:33:58 GMT):
Invite: Join Zoom Meeting https://zoom.us/j/4034983298 One tap mobile +16699006833,,4034983298# US (San Jose) +16465588656,,4034983298# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York) 855 880 1246 US Toll-free 877 369 0926 US Toll-free Meeting ID: 403 498 3298 Find your local number: https://zoom.us/u/aeh29lGmA

dhuseby (Wed, 12 Jun 2019 00:34:00 GMT):
use that

dhuseby (Wed, 12 Jun 2019 00:34:20 GMT):
https://zoom.us/my/hyperledger.community https://zoom.us/j/4034983298

dhuseby (Wed, 12 Jun 2019 00:34:24 GMT):
@hartm ^^^

hartm (Wed, 12 Jun 2019 00:38:11 GMT):
I added it. Thanks! But community-architects has not accepted.

rjones (Wed, 12 Jun 2019 01:23:57 GMT):
@hartm it's on the calendar now thanks

hartm (Wed, 12 Jun 2019 01:58:57 GMT):
Thanks Ry!

hartm (Wed, 12 Jun 2019 02:00:15 GMT):
Thanks Silona, Ry, and Dave. Unfortunately now we have duplicate meetings on the calendar...

rjones (Wed, 12 Jun 2019 02:00:28 GMT):
well - go to both?

rjones (Wed, 12 Jun 2019 02:00:55 GMT):
I assume I should delete "Hyperledger crypto-lib Discussion" ?

rjones (Wed, 12 Jun 2019 02:01:41 GMT):
_deletes "Hyperledger crypto-lib Discussion"_

hartm (Wed, 12 Jun 2019 02:01:59 GMT):
Great. Thanks!

hartm (Wed, 12 Jun 2019 02:24:57 GMT):
@here Just a reminder for tomorrow's meeting. Thanks to the LF staff for getting everything sorted out!

Dan (Wed, 12 Jun 2019 12:12:34 GMT):
What's the maximum number of gates that would be relevant for use cases people are looking at? 80/20 rule is fine. I'm looking for a pragmatic upper bound.

lovesh (Wed, 12 Jun 2019 13:00:04 GMT):
Assuming you mean multiplication gates, 10-15 K if using merkle trees

danintel (Wed, 12 Jun 2019 13:44:40 GMT):
https://zoom.us/my/hyperledger.community

Dan (Tue, 18 Jun 2019 14:31:08 GMT):
https://i.stack.imgur.com/QP1F8.jpg

Dan (Tue, 18 Jun 2019 14:53:04 GMT):
@danintel discussion in the sovrin crypto call today about finding an optimized bls12-381. We currently rely on Milagro's AMCL library which is designed to be portable. There's no asm, for example. Is that research something you'd like to do?

Dan (Tue, 18 Jun 2019 15:01:22 GMT):
some subsequent discussion... zcash is the other known place for this code. it's currently slower but it's thought that optimization is in process there. I don't know whether they are interested in upstream commits, but that's another option. More expensive of course, than finding another implementation.

MALodder (Tue, 18 Jun 2019 17:54:53 GMT):
Here's an interesting pairings library written in C https://github.com/herumi/mcl

agunde (Wed, 19 Jun 2019 16:23:53 GMT):
Has joined the channel.

arjanvaneersel (Thu, 20 Jun 2019 19:06:36 GMT):
Has joined the channel.

chlsc (Fri, 21 Jun 2019 05:39:35 GMT):
Has joined the channel.

RajkumarNatarajan (Sat, 22 Jun 2019 04:25:43 GMT):
Has joined the channel.

kdenhartog (Sat, 22 Jun 2019 19:36:23 GMT):
Is this possible in Ursa? https://lm.facebook.com/l.php?u=https%3A%2F%2Fthehackernews.com%2F2019%2F06%2Fopenssh-side-channel-vulnerability.html%3Ffbclid%3DIwAR0Lu8wShyUmSv2wvsE0oMwyEkGtwkKASEDZ94QRWLgpSDJacv54H6beJXI&h=AT060yYI3MxIWBEd-HsvzZE6OrfUt54HoZhm9VPjP0s7EaGZBTGCXMN5a_QUWER0IUTDRQspqAvyZM4IfyXu4rCO6gv2JTEFlPfCIqYSPeOpT2n1YLR25W5m9UItdZz62KrOQl8iPnYFEA6T1x0TOyq188Vibo7JHo0lxQ5sKCULgURg8taebU32IEBYY1S1LWeXWgR2pCVnZAxtJewSzFfkUKXNhgFrdWbjKZAwOXN5hZhfEgoYhhzYvfBqJOjI0HurHqVXu9wuJS2zeYf-SaadHq-K4eBgK6CDY-s9XjhQETYxbbHcV98H5buRbiE8DWwrT2zG5NcaWpqP9LSTpvW-Sbi24CfUGFNu9v4Dmodm6f3QpYDr1rDUh5VzKsXS-73xIoD4N6tJjK2l883hCCJep_7qXJyqL_j6LmQus8_VdMMNH2JqsbXVzTBZGM2zlKcx3EO002kAM4lT64AI2xNTpYjFmyNasSVmpBZfp_i1oKeUXdJuhUZ4AhN2uz8TXrVyfpU4bIF7DlNVKaXWkkMZQi63LXQvvlDi-twbbsf5OprE-XZ57fA4MHkjvlbiQ5vbtqsPSU4PC6nBMruwkeV0aUMkm9bMYlV3VPOLVfr4AQ_guqo2hNS2YBbkRys_8BpAmIux43TF1CcpHuYdF09AIwkW-L4kiqMH1G2BlUJVgHAYzQo_8tSTs6_Gh31YV45ooNTynUGNfeD9INmTuJzTrOEyfB6Xy5zbv7IW--PynG8cGp6XRgYyZfdFoNC-aQfCoMHekYpGLjcpKMZN286rP0o6tB4xlo36JWCfClZQmXGST2qzuz81VVYh8tB__y1Z_4eDxthsA9aZhBjY5n5OzEKXsNHLWGT4Ri5XzVnp-V1M_uE1g0JKjsu4Pm2zbDiJNfJYTEuPHfBB2andUNTYUknHKlp3asHLlzguIMkW1tWHP1OPgYVnENRprigPemRwuVmzciJjZ8Clkt0Z6orvoP8HM6eYTC6z9YPY245R_WjStwHn1wQLCHAAcoZxpJSjajccED1YWiozCK8TKKPcZhCA2fbwx845FaA59VjHZD_NZ5Eej4CD0A

kdenhartog (Sat, 22 Jun 2019 19:36:23 GMT):
Is this possible in Ursa? https://thehackernews.com/2019/06/openssh-side-channel-vulnerability.html

JonGeater (Sun, 23 Jun 2019 18:33:20 GMT):
That's essentially a mid-level paranoia use case for HSMs or Secure Elements - at a certain point shared DRAM is ALWAYS vulnerable and a dedicated compute unit with the keys offloaded from the main application is your only option. The system protections get better all the time, making these attacks quite fanciful for a while, until the attacks get better again (usually around August every year ;-) ) then you're screwed again for a while.

verasnt (Tue, 25 Jun 2019 12:45:25 GMT):
Has joined the channel.

JonGeater (Wed, 26 Jun 2019 13:26:02 GMT):
Hi guys, sorry I’m going to be offline again today but I should be getting back to normal service from next week and will pick up the TEE stuff again

Dan (Wed, 26 Jun 2019 13:42:31 GMT):
I'm also looking less likely to make today's meeting I wonder if we should just cancel. Hart is going as well.

Dan (Wed, 26 Jun 2019 13:42:52 GMT):
Sorry that should read hart is gone as well

MALodder (Wed, 26 Jun 2019 16:57:51 GMT):
Notes from today's meeting Ursa Meeting Notes ================== Discussed PRs: - Lovesh Bulletpoof - Add more tests and code documentation - Anoncreds 1.0 - Belongs in ursa-docs repo Dfinity has interest in ZMix with BBS+ signatures Unbound agreed to help with PKCS11 interface when the RFC is created and keep their tech as an implementation outside of Ursa - Unbound will reach to ursa group and Jon Geater Manu Drijvers said there is no licensing restrictions around https://eprint.iacr.org/2019/514.pdf - Algorand probably making implementation in Rust Manu Drijvers to see if he can get his paper about threshold PS signatures on eprint. ZKLang spec to be done in Latex in ursa-docs.

MALodder (Wed, 26 Jun 2019 17:02:49 GMT):
There seems to be a growing interest in the PKCS11 interface. I would propose we work on this as an RFC and have @Dan and @JonGeater lead it. I'm not the most familiar PKCS11 so I'm not the most qualified to lead it. I believe @Dan with intel's work on SGX and @JonGeater are the most qualified to lead that effort. I want to participate from an implementation and usability side of things. Sorry to nominate @Dan and @JonGeater in there absence

MALodder (Wed, 26 Jun 2019 17:02:49 GMT):
There seems to be a growing interest in the PKCS11 interface. I would propose we work on this as an RFC and have @Dan and @JonGeater lead it. I'm not the most familiar PKCS11 so I'm the most qualified to lead it. I believe @Dan with intel's work on SGX and @JonGeater are the most qualified to lead that effort. I was to participate from an implementation and usability side of things. Sorry to nominate @Dan and @JonGeater in there absence

MALodder (Wed, 26 Jun 2019 17:02:49 GMT):
There seems to be a growing interest in the PKCS11 interface. I would propose we work on this as an RFC and have @Dan and @JonGeater lead it. I'm not the most familiar PKCS11 so I'm not the most qualified to lead it. I believe @Dan with intel's work on SGX and @JonGeater are the most qualified to lead that effort. I was to participate from an implementation and usability side of things. Sorry to nominate @Dan and @JonGeater in there absence

JonGeater (Wed, 26 Jun 2019 17:30:42 GMT):
Haha no worries it was inevitable 😄

Dan (Wed, 26 Jun 2019 18:46:08 GMT):
Due punishment for shirking the meeting ;)

MALodder (Wed, 26 Jun 2019 18:46:22 GMT):
Beatings will continue until morale improves

huxiangdong (Thu, 27 Jun 2019 02:56:41 GMT):
a newbie question about the libzmix...what's typical usage scenario this lib is designed for? would it replace zero knowledge proof implementation in other hyperledger project for example the idemix in hyperledger fabric?

Dhiraj1990 (Thu, 27 Jun 2019 09:58:12 GMT):
Has joined the channel.

Dhiraj1990 (Thu, 27 Jun 2019 09:58:14 GMT):
How do i implement ursa ? I have followed all steps mentioned on this document. https://github.com/hyperledger/ursa

sklump (Thu, 27 Jun 2019 10:20:39 GMT):
Has left the channel.

Dhiraj1990 (Thu, 27 Jun 2019 10:22:40 GMT):
I am not able to understand how do i proceed ahead ?

pschwarz (Thu, 27 Jun 2019 14:14:44 GMT):
Has joined the channel.

george.aristy (Thu, 27 Jun 2019 18:51:38 GMT):
Has joined the channel.

rhall9090 (Fri, 28 Jun 2019 16:25:24 GMT):
Has joined the channel.

MALodder (Mon, 01 Jul 2019 14:29:14 GMT):
yes, however, its up to fabric, indy, sawtooth, etc. to actually use it

MALodder (Mon, 01 Jul 2019 14:29:43 GMT):
what do you mean by implement ursa? Do you mean use it for your project?

lovesh (Tue, 02 Jul 2019 12:58:59 GMT):
@hartm @MALodder Here is the Rust (WIP i think) implementation of const time hash on BLS curves https://github.com/kwantam/bls_sigs_ref/blob/master/rust-impl/src/lib.rs. It is by one of the authors of the paper

Khaled.MH (Tue, 02 Jul 2019 16:06:18 GMT):
Has joined the channel.

huxiangdong (Wed, 03 Jul 2019 03:04:27 GMT):
thanks!

rjones (Mon, 08 Jul 2019 18:09:03 GMT):
Has left the channel.

lovesh (Tue, 09 Jul 2019 10:12:53 GMT):
For anyone interested in writing R1CS circuits, a great presentation by one of Zcash employees https://youtu.be/Uug5p05_wqs

Dan (Wed, 10 Jul 2019 14:16:40 GMT):
one example of multi-license https://github.com/hyperledger/sawtooth-core/blob/master/LICENSE

lovesh (Thu, 11 Jul 2019 10:51:02 GMT):
Thanks

sumodgeorge (Sat, 13 Jul 2019 13:25:29 GMT):
Has joined the channel.

kukgini (Mon, 15 Jul 2019 00:06:19 GMT):
Has joined the channel.

alexx (Mon, 15 Jul 2019 03:22:57 GMT):
Has joined the channel.

MALodder (Mon, 15 Jul 2019 12:33:29 GMT):
@hartm here is another paper that would be helpful to go over with Riad https://eprint.iacr.org/2019/814.pdf

hartm (Mon, 15 Jul 2019 14:10:06 GMT):
@MALodder I saw that one. We can ask him about it on Thursday.

lovesh (Mon, 15 Jul 2019 14:37:57 GMT):
Btw we dont check for incoming points on infinity or whether they have desired order. AMCL does not expose any API but we can do it the generic way of multiplying by curve order and comaring result with infinity

lovesh (Mon, 15 Jul 2019 14:37:57 GMT):
Btw we dont check for incoming points on infinity or whether they have desired order in our BLS sig. AMCL does not expose any API but we can do it the generic way of multiplying by curve order and comaring result with infinity

MALodder (Mon, 15 Jul 2019 14:40:48 GMT):
are you talking about when we verify signatures in Indy?

lovesh (Mon, 15 Jul 2019 14:42:44 GMT):
Yes, BLS sigs.

lovesh (Mon, 15 Jul 2019 14:43:36 GMT):
But apart from a general good practice, don't know if that makes sense in case of sig verification. Thoughts?

MALodder (Mon, 15 Jul 2019 14:44:35 GMT):
I'm not sure. I think because we are just checking if the signature is valid, we might be okay. However, could an attacker use a point at infinity to validate any signature?

lovesh (Mon, 15 Jul 2019 14:47:12 GMT):
probably not point at infinity but if the sig lies in a small subgroup, could the private key be recovered?

lovesh (Mon, 15 Jul 2019 14:47:18 GMT):
@hart ^^^

lovesh (Mon, 15 Jul 2019 14:47:18 GMT):
@hartm ^^^

hartm (Mon, 15 Jul 2019 14:48:35 GMT):
Elliptic curve groups used for cryptography pretty much always have prime order. This means they don't have subgroups.

hartm (Mon, 15 Jul 2019 14:49:30 GMT):
My point with Lovesh was that the point at infinity is often a cause of errors and vulnerabilities in crypto code and should be tested as an input to everything.

lovesh (Mon, 15 Jul 2019 14:52:51 GMT):
Does this statement apply to curves with cofactors?

hartm (Mon, 15 Jul 2019 14:54:48 GMT):
No. Curves with cofactors that aren't equal to one aren't prime order. However, we work over a prime order subgroup of these curves.

hartm (Mon, 15 Jul 2019 14:55:18 GMT):
Sorry for generalizing too much there.

hartm (Mon, 15 Jul 2019 14:55:59 GMT):
But you should always be working in a large prime order (sub-) group when using elliptic curves.

lovesh (Mon, 15 Jul 2019 14:58:55 GMT):
Ok. For curves with cofactor not equal to one like BLS381 or BN254, an attacker can construct a point satisfying curve equation but of small order. The question is if we ignore key exchange protocols, what are the attacks possible?

hartm (Mon, 15 Jul 2019 15:01:17 GMT):
The point is the actual "group" used for crypto is not the whole elliptic curve, but a subgroup of the group defined by the elliptic curve. The subgroup--or actual group where crypto is done--has large prime order, so DLOG/CDH/DDH are still hard. An attacker can solve these problems over the small order part of the group, but they aren't useful for breaking the cryptography, because the small order part of the bigger group is nonexistent in the subgroup.

hartm (Mon, 15 Jul 2019 15:01:20 GMT):
Does that make sense?

MALodder (Mon, 15 Jul 2019 15:02:06 GMT):
To me it does

hartm (Mon, 15 Jul 2019 15:02:26 GMT):
I would recommend keeping a copy of https://www.amazon.com/Algebra-2nd-Michael-Artin/dp/0132413779 around the office for stuff like this.

hartm (Mon, 15 Jul 2019 15:02:33 GMT):
I guess the call has started.

MALodder (Mon, 15 Jul 2019 15:04:11 GMT):
We should add the checks to the BLS code but it doesn't sound urgent

lovesh (Mon, 15 Jul 2019 15:05:32 GMT):
I am gonna try to ponder over this statement "the small order part of the bigger group is nonexistent in the subgroup."

Dan (Mon, 15 Jul 2019 15:10:44 GMT):
going to spend time tomorrow reviewing https://github.com/hyperledger/ursa/pull/40 Can someone remind me the specific motivating use case for inclusion in Ursa?

lovesh (Mon, 15 Jul 2019 15:42:46 GMT):
https://eprint.iacr.org/2012/562.pdf

lovesh (Mon, 15 Jul 2019 15:43:37 GMT):
One more https://www.researchgate.net/publication/261161894_Aggregate_Signature-Based_Efficient_Attributes_Proof_with_Pairing-Based_Anonymous_Credential

Dan (Mon, 15 Jul 2019 16:28:12 GMT):
Per roadmap discussion: https://wiki.hyperledger.org/display/ursa/Release+Planning+Feature+List

Dan (Mon, 15 Jul 2019 17:47:04 GMT):
Incidentally I don't think we should maintain 3 sets of roadmap information ( the wiki, the docs repo, and Jira). I view that wiki page as a brainstorm list to generate items for the other two locations. The docs repo should include a high-level roadmap and jira should include epics based on that high-level roadmap with actionable stories at a finer grain. For that matter, we haven't really been using Jira extensively, so that's something we can discuss at the next meeting too. I think Jira is worthwhile only if we have an actively managed backlog. If our development culture is more about a few people self prioritizing things off the high-level roadmap, then jira is just overhead.

alank9 (Mon, 15 Jul 2019 23:20:37 GMT):
Has joined the channel.

ashutosh_kumar (Tue, 16 Jul 2019 03:26:43 GMT):
Most important point is that the subgroup is Cyclic subgroup , which makes the subgroup of Finite Prime Order. Being Cyclic Subgroup , you can have a generator , that can provide you base point for the curve.

ViaSky (Wed, 17 Jul 2019 17:27:03 GMT):
Has joined the channel.

MALodder (Thu, 18 Jul 2019 15:33:47 GMT):
@Dan Do you recall from the BLS discussion on Monday how Riad mentioned to use HKDF to hash to field elements instead of SHA256?

MALodder (Thu, 18 Jul 2019 15:34:04 GMT):
he didn't specify the salt or key values

MALodder (Thu, 18 Jul 2019 15:34:22 GMT):
so I'm wondering if we can use domain specific parameters for these values @hartm

MALodder (Thu, 18 Jul 2019 15:35:13 GMT):
as long as these values are decent size like 64 bytes each

Dan (Thu, 18 Jul 2019 15:57:36 GMT):
It was just to use HKDF in the obvious way.

Dan (Thu, 18 Jul 2019 16:07:58 GMT):
lol are you going to let me get away with saying that? ;)

Dan (Thu, 18 Jul 2019 16:08:28 GMT):
They made reference to this IETF draft... https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-04

MALodder (Thu, 18 Jul 2019 16:44:27 GMT):
Right but the draft still shows SHA256

MALodder (Thu, 18 Jul 2019 16:44:37 GMT):
what is the obvious way to use HKDF?

MALodder (Thu, 18 Jul 2019 16:44:46 GMT):
HKDF uses a salt and key

MALodder (Thu, 18 Jul 2019 16:44:51 GMT):
then takes an input

Dan (Thu, 18 Jul 2019 17:21:39 GMT):
I was joking :) There's nothing obvious.

MALodder (Thu, 18 Jul 2019 17:44:52 GMT):
@Dan I thought the joke was obvious

MALodder (Thu, 18 Jul 2019 17:44:57 GMT):
:wink:

MALodder (Thu, 18 Jul 2019 17:45:43 GMT):
I'm hoping @hartm will say we can just set domain specific parameters for the HKDF values so each consumer can reproduce the hashing to field elements

Dan (Thu, 18 Jul 2019 17:55:20 GMT):
I haven't studied it enough but I guess I would start with section 8.7 which specifies `sha256` and a `p` value and then use that as alluded to in 5.1 to produce `L` (I think `k` is 128? but that's probably specified in the bls12-381 defn.) and then do the extract/expand (hopefully already implemented by someone else) as described in https://tools.ietf.org/html/rfc5869 which refers to salt as optional. So yeah, just the obvious stuff. ;)

Dan (Thu, 18 Jul 2019 17:55:20 GMT):
I haven't studied it enough but I guess I would start with section 8.7 which specifies `sha256` and a `p` value and then use that as alluded to in 5.1 to produce L (I think `k` is 128? but that's probably specified in the bls12-381 defn.) and then do the extract/expand (hopefully already implemented by someone else) as described in https://tools.ietf.org/html/rfc5869 which refers to salt as optional. So yeah, just the obvious stuff. ;)

Dan (Thu, 18 Jul 2019 17:57:44 GMT):
But really emphasis on using an existing hkdf implementation.

Dan (Thu, 18 Jul 2019 17:58:08 GMT):
(unless you really want to roll your own and then who am I to stop someone from having fun :D )

Dan (Thu, 18 Jul 2019 19:49:43 GMT):
@lovesh first off, nice work on the paillier stuff. There's nothing wrong with the banner you put in, but for future reference this is the official recommendation: https://wiki.hyperledger.org/display/HYP/Copyright+and+License+Policy Mentioning here so everyone is familiar. The copyright line is useful so if someone wants to use this file outside of Ursa, the file caries the attribution with it (which the downstream developer needs to advertise as part of the license requirements). The spdx line is I guess just shorter than putting the whole license in. I would think the whole license is better than spdx but IANAL.

AxelNennker (Fri, 19 Jul 2019 09:54:46 GMT):
Has joined the channel.

lovesh (Fri, 19 Jul 2019 10:16:35 GMT):
Thanks. Using the official recommendation now.

lovesh (Fri, 19 Jul 2019 10:17:49 GMT):
@hartm @MALodder Did you have the call with Riad? If yes, did yoou guys ask why HKDF was preferred over SHAKE? Is it efficiency?

lovesh (Fri, 19 Jul 2019 10:17:49 GMT):
@hartm @MALodder Did you have the call with Riad? If yes, did you guys ask why HKDF was preferred over SHAKE? Is it efficiency?

AxelNennker (Fri, 19 Jul 2019 10:22:37 GMT):
Maybe a stupid question, aren't SignKeys usually secret and so should be zeroized after use? https://github.com/hyperledger/ursa/blob/master/libursa/src/bls/mod.rs#L67 A problem is that some are handed over to C-code. Anyway, I think that at least the Rust examples should be written so that the sign keys are zeroized manually e.g. sign_key1 should be zeroized after being used here: https://github.com/hyperledger/ursa/blob/master/libursa/src/bls/mod.rs#L325 Also as_bytes should have a warning in the documentation and warning that the bytes are secret and should not be copied. Am I paranoid or is this a design decision because of the C-Code thing?

lovesh (Fri, 19 Jul 2019 11:01:52 GMT):
Yes. Signing keys are not the only ones. There are other intermediate values that might need to be zeroed out depending on the protocol. IMO, a better but slightly expensive approach is to ensure that data is zeroed when it goes out of scope so that you don't explicitly forget to clear, eg https://github.com/lovesh/amcl_rust_wrapper/blob/remove-copying/src/field_elem.rs#L54. For smaller protocols explicitly clearing the data once you are done might be fine.

lovesh (Fri, 19 Jul 2019 11:03:39 GMT):
On the examples you gave, the signing key is borrowed by signing algo so it cannot be cleared by the signing algo; the caller should clear it

AxelNennker (Fri, 19 Jul 2019 11:03:55 GMT):
zeroize 0.9 now has a derive so that it is quite easy to zeroize stuff.

lovesh (Fri, 19 Jul 2019 11:04:42 GMT):
On the C-API, i think you are right, Ursa provides a free method but that might be a bad thing

lovesh (Fri, 19 Jul 2019 11:04:42 GMT):
On the C-API, i think you are right, Ursa provides a free method but that might now seems a bad thing

lovesh (Fri, 19 Jul 2019 11:04:42 GMT):
On the C-API, i think you are right, Ursa provides a free method but that now seems like a bad thing

lovesh (Fri, 19 Jul 2019 11:05:45 GMT):
I have heard but not used it. I use clear_on_drop but i see that zeroize is backed by some quite famous guys

AxelNennker (Fri, 19 Jul 2019 11:10:11 GMT):
Probably to late to change the C-API. I don't like the free stuff, better let the caller provide the memory and fail if it is too small. That shouldn't be a problem too often because the size if fixed in ursa MODBYTES

AxelNennker (Fri, 19 Jul 2019 11:10:11 GMT):
Probably too late to change the C-API. I don't like the free stuff, better let the caller provide the memory and fail if it is too small. That shouldn't be a problem too often because the size if fixed in ursa MODBYTES

MALodder (Fri, 19 Jul 2019 14:30:20 GMT):
Yes I did. He said SHAKE would work as well. His main argument for HKDF was groups are either using it already and its easy to hook up SHA2 to it and they are unlikely to switch. He's mostly just concerned about having a stronger hiding method that sha2

lovesh (Fri, 19 Jul 2019 15:22:55 GMT):
Thanks

MALodder (Fri, 19 Jul 2019 15:25:35 GMT):
clear_on_drop requires compiling a C file. I have used zeroize in my PR https://github.com/hyperledger/ursa/pull/42/files#diff-ec778c91007df5961a4736dcc7844cc9R73

MALodder (Fri, 19 Jul 2019 15:25:56 GMT):
I've also added that to indy-sdk before and I quite like zeroize plus I know Toni quite well

MALodder (Fri, 19 Jul 2019 15:26:04 GMT):
he's a very good cryptographer

MALodder (Fri, 19 Jul 2019 15:33:28 GMT):
I can update my PR to use shake256 which should be good enough

MALodder (Fri, 19 Jul 2019 15:33:52 GMT):
Riad also said SHA3 would be fine since the sponge construction is better hiding than sha2

MALodder (Fri, 19 Jul 2019 15:34:28 GMT):
I'm also fine leaving it for HKDF since a high entropy salt and key assists in hiding possible low entropy inputs

AxelNennker (Fri, 19 Jul 2019 15:45:24 GMT):
Will you add zeroize support to SignKey?

AxelNennker (Fri, 19 Jul 2019 15:46:21 GMT):
Best to update zeroize to 0.9.x and use the new features, I guess

AxelNennker (Fri, 19 Jul 2019 15:47:38 GMT):
Can somebody explain why Ursa is using libsodium-ffi which libindy is using sodiumoxide which uses libsodium-sys?

AxelNennker (Fri, 19 Jul 2019 15:47:53 GMT):
Maybe it doesn't matter

Dan (Fri, 19 Jul 2019 16:32:09 GMT):
:shrug: afaik, indy has dropped / is dropping their crypto implementations and relying on ursa. and ursa is mostly indy crypto code at this point.

MALodder (Fri, 19 Jul 2019 17:44:58 GMT):
its only using that for testing

MALodder (Fri, 19 Jul 2019 17:45:25 GMT):
it doesn't use libsodium other than compatibility tests

AxelNennker (Sat, 20 Jul 2019 07:53:56 GMT):
Regarding amcl on crates.io https://crates.io/crates/amcl authored by nikita.khateev@dsr-corporation.com @KitHat : The repository link in that crate is a 404 What is the relationship of that crate to ursa?

KitHat (Sat, 20 Jul 2019 07:53:56 GMT):
Has joined the channel.

AxelNennker (Sat, 20 Jul 2019 08:06:39 GMT):
Rust Cryptography Working Group https://github.com/rust-lang/wg-governance/issues/12

lovesh (Sat, 20 Jul 2019 17:21:31 GMT):
That crate was published by Evernym staff but is based on very old AMCL which has been removed from github now. The new AMCL codebase (https://github.com/miracl/amcl) does not have an official crate, maybe we should help them deploy one.

AxelNennker (Sat, 20 Jul 2019 21:26:08 GMT):
Or publish the amcl.rs code from Ursa as its own crate? Maybe I am mixing stuff up. I am confused about what ursa, indy-crypto and libindy/src/utils/crypto are. BTW, I think that base58 and base64 should not be 'under' crypto. That is dangerous, I think.

lovesh (Sun, 21 Jul 2019 07:16:19 GMT):
But AMCL is evolving and we have to keep a mirror and keep it synced. But set up a deploy pipeline on their github to automate publishing. AMCL is a low level crypto library. Ursa should be able to use several such libraries. You can now consider indy-crypto as deprecated. Indy might decide to use crypto other than Ursa or maybe add some convenience wrapper on Ursa code. Thats was `libindy/src/utils/crypto` is about. Didn't get the danger about putting base58 and base64 under crypto.

lovesh (Sun, 21 Jul 2019 07:16:19 GMT):
But AMCL is evolving and we have to keep a mirror and keep it synced. Better set up a deploy pipeline on their github to automate publishing. AMCL is a low level crypto library. Ursa should be able to use several such libraries. You can now consider indy-crypto as deprecated. Indy might decide to use crypto other than Ursa or maybe add some convenience wrapper on Ursa code. Thats was `libindy/src/utils/crypto` is about. Didn't get the danger about putting base58 and base64 under crypto.

AxelNennker (Sun, 21 Jul 2019 07:19:21 GMT):
'dangerous' because 'real' cryptographers yell a people who might think that baseXX encoding is encryption. 'dangerous' because some developers think that baseXX encoding is encryption. Better avoid both by using baseXX directly and remove them from crypto/something.

AxelNennker (Sun, 21 Jul 2019 07:19:21 GMT):
'dangerous' because 'real' cryptographers yell at people who might think that baseXX encoding is encryption. 'dangerous' because some developers think that baseXX encoding is encryption. Better avoid both by using baseXX directly and remove them from crypto/something.

AxelNennker (Sun, 21 Jul 2019 07:21:46 GMT):
I am wondering why libindy/src/utils/crypto was not put into its own crate that then would be replaced by ursa.

AxelNennker (Sun, 21 Jul 2019 07:22:30 GMT):
It seems that all three places are currently being developed which seems to be a waste of time.

lovesh (Sun, 21 Jul 2019 07:23:17 GMT):
Ok :smile: I would be hesistant to let developers touch code that don't understand difference between encoding and encryption. But i do realize that base58/64 is misplaced and is bad from a code organisation point of view.

lovesh (Sun, 21 Jul 2019 07:24:12 GMT):
On libindy/src/utils/crypto being a separate crate, would people outisde libindy want to use it?

AxelNennker (Sun, 21 Jul 2019 07:24:29 GMT):
Well, I don't see any value in having a wrapper around base58 or base64. Indy should use those directly, I think

lovesh (Sun, 21 Jul 2019 07:26:23 GMT):
I am speculating but maybe they wanted to make an Encoding interface and base58 or 64 will then be specializations. Maybe

AxelNennker (Sun, 21 Jul 2019 07:26:25 GMT):
Regarding 'whould others use libindy/src/utils/crypto'. No need to publish the crate just put is next to libindy

AxelNennker (Sun, 21 Jul 2019 07:28:02 GMT):
Abstraction has _some_ merits but not here, I think. If for example Verkey were redefined to use base64 instead of base58 then that would be another Verkey and I see no value in being this flexible.

lovesh (Sun, 21 Jul 2019 07:28:08 GMT):
I am not a Rust expert so dumb question: whats the value of making it a crate in this case.

AxelNennker (Sun, 21 Jul 2019 07:28:43 GMT):
To have it separate from libindy and then replace it with ursa.

AxelNennker (Sun, 21 Jul 2019 07:28:43 GMT):
To have it separate and then replace it with ursa.

AxelNennker (Sun, 21 Jul 2019 07:33:27 GMT):
I saw that many devs from Evernym, DSR, Sovrin are involved in amcl. You said 'help them to publish amcl as a crate'. Yes, why isn't that a crate already? Really the low-level stuff operating on bytes only. No fancy wrappers. Just what is in the github

lovesh (Sun, 21 Jul 2019 07:37:18 GMT):
We should evaluate that code. Can you join the next Ursa call? But my point in general was that Ursa is meant to be generic and i think most projects will build their own thin convenince wrapper specific to their needs but invaluable to others.

lovesh (Sun, 21 Jul 2019 07:38:42 GMT):
Yes but your keypair creation code will expect an encoding trait.

lovesh (Sun, 21 Jul 2019 07:41:42 GMT):
On "why isn't that a crate already", based on the my interactions with the AMCL author, he is the only guy responsible for managing this codebase so lack of time.

AxelNennker (Sun, 21 Jul 2019 07:42:32 GMT):
I hope that some common traits are evolving in Rust like Digest that is used by all cryptography crates so one implementation can be replaced by another as long as the trait is implemented.

lovesh (Sun, 21 Jul 2019 07:43:11 GMT):
We didn't setup the CI in the first place but just published it. The code changed places since then.

AxelNennker (Sun, 21 Jul 2019 07:45:49 GMT):
Seems to be in our interest to help him then. Maybe he is in his Python script world that allows amcl to be configured to have support for some or other curve or algoritm. That is not needed for Rust, I think, because of Rust's features. The readme.txt https://github.com/miracl/amcl/tree/master/version3 goes in that direction. So why not publich this crate as is on crates.io?

AxelNennker (Sun, 21 Jul 2019 07:47:34 GMT):
Would you agree that @KitHat amcl should be replaced by this low-level amcl crate?

lovesh (Sun, 21 Jul 2019 07:49:43 GMT):
I had actually tried a bit and failed using Travis CI. It was not picking up the security token correctly. I ended up forking it for a mirror and publishing locally in the meantime.

lovesh (Sun, 21 Jul 2019 07:50:03 GMT):
The current AMCL crate should be fixed since its outdated and lot of fixes have been made since then

lovesh (Sun, 21 Jul 2019 07:52:54 GMT):
Yes, some of that code does seem like useful to other folks like the password hashing

AxelNennker (Sun, 21 Jul 2019 07:53:36 GMT):
One way to fix @KitHat 's amcl is to fix the 404 repository link by setting it to https://github.com/miracl/amcl/tree/master/version3 and then change the version to 0.3.0 and then 'just' publish that code. naive?

lovesh (Sun, 21 Jul 2019 07:54:08 GMT):
But we need to polish it a bit. We should have a generic interface in Ursa for these

AxelNennker (Sun, 21 Jul 2019 07:55:08 GMT):
Ursa is a different matter. Ursa can then define or implement some useful trait that wraps amcl

lovesh (Sun, 21 Jul 2019 07:56:44 GMT):
Doing it right (CI pipeline at miracl/amcl) does not seem to take much more effort so i prefer to do that.

AxelNennker (Sun, 21 Jul 2019 07:57:37 GMT):
I do not disagree with that.

lovesh (Sun, 21 Jul 2019 07:58:14 GMT):
My point was not regarding Ursa. But provinding interfaces for high level functions like password hashing with option for various trafeoffs (mem/CPU, etc)

lovesh (Sun, 21 Jul 2019 07:59:14 GMT):
If its not too much to ask, can i ask you to take a brief look at an amcl rust wrapper and see if that makes sense to you

lovesh (Sun, 21 Jul 2019 07:59:55 GMT):
https://github.com/lovesh/amcl_rust_wrapper

AxelNennker (Sun, 21 Jul 2019 08:00:02 GMT):
To be sure which code we are talking about could you please send a link

lovesh (Sun, 21 Jul 2019 08:00:14 GMT):
above one

AxelNennker (Sun, 21 Jul 2019 08:00:14 GMT):
Hm, parallel

lovesh (Sun, 21 Jul 2019 08:00:38 GMT):
Its not just a wrapper but provides some other algos too.

AxelNennker (Sun, 21 Jul 2019 08:01:39 GMT):
I will taka a look.

AxelNennker (Sun, 21 Jul 2019 08:01:39 GMT):
I will take a a look.

lovesh (Sun, 21 Jul 2019 08:01:53 GMT):
Thanks

AxelNennker (Sun, 21 Jul 2019 08:02:23 GMT):
regarding other algos: Why not add them to amcl directly?

lovesh (Sun, 21 Jul 2019 08:03:39 GMT):
The author prefers to have them in all languages and that seems like more work than i am willing to sign up for. I did make such a change in an extreme case though.

AxelNennker (Sun, 21 Jul 2019 08:11:07 GMT):
I would create an issue https://github.com/miracl/amcl/issues like 'implement algo XYZ' and immediately send a PR for a Rust implementation. In the issue ask for help to implement in other languages. Usually people are nice and contribute. Or publish the alg in its own crate and create a git submodule in your wrapper and amcl

lovesh (Sun, 21 Jul 2019 08:13:31 GMT):
Alright. Will post here when i do so

AxelNennker (Mon, 22 Jul 2019 09:00:54 GMT):
Next 'meeting' is on Wednesday, 24th, right? There is no agenda yet. https://wiki.hyperledger.org/display/ursa/

hartm (Mon, 22 Jul 2019 14:12:45 GMT):
@AxelNennker That's correct.

hartm (Mon, 22 Jul 2019 14:13:03 GMT):
I'll create an agenda today. Feel free to add what you like.

hartm (Mon, 22 Jul 2019 14:16:21 GMT):
Just created the file. Feel free to add what you like.

lovesh (Mon, 22 Jul 2019 14:36:19 GMT):
Agenda updated https://wiki.hyperledger.org/display/ursa/2019-07-22+Meeting+Agenda

Dan (Mon, 22 Jul 2019 15:01:14 GMT):
fyi sovrin call conflicts with sawtooth contrib call this morning for me.

Dan (Mon, 22 Jul 2019 15:01:23 GMT):
enjoy your increased productivity in my absence ;)

AxelNennker (Tue, 23 Jul 2019 13:58:54 GMT):
Looks nice. Although I am not an expert in Pairing-Math, fields etc. There is a typo in the code in section 5 'ate_mutli_pairing' on page https://github.com/lovesh/amcl_rust_wrapper

MALodder (Tue, 23 Jul 2019 15:25:08 GMT):
Auditing of zkps

MALodder (Tue, 23 Jul 2019 15:35:54 GMT):
@hartm what do you think this method is doing https://GitHub.com/miracl/amcl/blob/master/version3/rust/src/ecp.rs#L253

hartm (Tue, 23 Jul 2019 16:01:20 GMT):
@MALodder I'm assuming this is some kind of way to sample from a complicated distribution in constant time (although obviously I could be wrong). Some distributions (i.e. Gaussians) are difficult to sample natively in constant time, so you might want to precompute parts of the probability density function to save yourself later. This kind of thing is really tricky to get right, which is why I'm assuming the function is so complicated.

lovesh (Tue, 23 Jul 2019 17:09:03 GMT):
Thanks. Will fix it :smile:

lovesh (Tue, 23 Jul 2019 17:16:32 GMT):
Its picking a point from a "lookup table". W is an array of multiples of a point and b is the multiplicand you want

Dan (Wed, 24 Jul 2019 15:36:38 GMT):
another way to think about granularity for RFCs and how we think about evaluating potential features is in the context of the two layer interface. Specifically how does crypto-primitive-x get exposed at the upper API level. What does that upper level look like? At least for me, lack of that upper definition is what makes me uncomfortable with new primitives.

MALodder (Wed, 24 Jul 2019 15:41:58 GMT):
Sounds good @Dan. Can you write an RFC that explains that?!?😂

Dan (Wed, 24 Jul 2019 15:43:23 GMT):
Not to confuse things from the tail end of our discussion where I think we were talking about actually putting up RFCs for that upper layer interface.

hartm (Wed, 24 Jul 2019 15:54:08 GMT):
I'm going to need an RFC for that RFC for that RFC ;)

hartm (Wed, 24 Jul 2019 15:54:42 GMT):
In all seriousness, we should start working on delineating the "cryptographer layer" from the "user interface" like we have sketched out before. Dan brings up a good point.

JonGeater (Wed, 24 Jul 2019 16:34:10 GMT):
Proof read please: "Hyperledger Ursa is a shared crypto library that provides Hyperledger Frameworks with safe interfaces to access high quality implementations of cryptographic primitives and key management functions. Put simply, Hyperledger Ursa brings high trust and security to users of Hyperledger Frameworks."

hartm (Wed, 24 Jul 2019 18:56:40 GMT):
@JonGeater That looks great. I might use "projects" instead of "frameworks" since it is likely that more than just "frameworks" will use Ursa (Aries, for instance, might not be a full framework). Projects is also simpler. But I like your phrasing a lot!

JonGeater (Wed, 24 Jul 2019 19:15:49 GMT):
Thanks @hartm , will make that mod

huxd (Thu, 25 Jul 2019 06:30:08 GMT):
Has joined the channel.

jimthematrix (Thu, 25 Jul 2019 14:29:19 GMT):
Has joined the channel.

KitHat (Thu, 25 Jul 2019 14:50:59 GMT):
@AxelNennker for you recent question about AMCL and Ursa. As far as I can see in source code of Ursa, @MALodder used the crate you have given link to, so there is no need make any changes in Ursa. What about the CD pipeline for this external crate, it would be really great to implement such a solution. @esplinr I see no obstacles to implement such a pipeline but don't really know what team should do it.

esplinr (Thu, 25 Jul 2019 14:51:00 GMT):
Has joined the channel.

mwklein (Thu, 25 Jul 2019 14:51:54 GMT):
Has joined the channel.

esplinr (Thu, 25 Jul 2019 15:22:19 GMT):
What do you think @MALodder and @SteveGoob ?

SteveGoob (Thu, 25 Jul 2019 15:22:19 GMT):
Has joined the channel.

MALodder (Thu, 25 Jul 2019 15:47:22 GMT):
I love to see CI/CD for all crates. I would actually like to drop amcl and use https://crates.io/crates/miracl_amcl which is run by the projects creator

MALodder (Thu, 25 Jul 2019 15:48:29 GMT):
@KitKat @esplinr ^^^

MALodder (Thu, 25 Jul 2019 15:49:09 GMT):
the code is the same but https://crates.io/crates/miracl_amcl is updated by the project owner and includes newer features that we want

MALodder (Thu, 25 Jul 2019 15:49:39 GMT):
that also should relieve Sovrin from maintaining the CI/CD pipeline

lovesh (Thu, 25 Jul 2019 15:55:29 GMT):
The crate miracl_amcl is not maintained by the projects creator but me. It is based on my mirror which has the same code but has attribution to the author. I don't have a CI pipeline for it

lovesh (Thu, 25 Jul 2019 15:58:39 GMT):
The original miracl repo has a CI but the Rust deployment has a TODO https://github.com/miracl/amcl/blob/master/scripts/travis_rust.sh#L44

lovesh (Thu, 25 Jul 2019 15:59:14 GMT):
Fixing the TODO should be sufficient and we wont need to have our own CI pipeline

AxelNennker (Thu, 25 Jul 2019 16:38:09 GMT):
Harmonize https://crates.io/crates/miracl_amcl and https://crates.io/crates/amcl and have the https://github.com/miracl/amcl maintainer also as a maintainer of the crates.io crates? I think the team needs a go from @esplinr Having the amcl code as a published crate would help ursa a lot, I think

Dan (Thu, 25 Jul 2019 16:40:19 GMT):
is there someone in this channel from amcl?

AxelNennker (Fri, 26 Jul 2019 14:01:18 GMT):
I created an issue in jira regarding the hard-coded generator point libindy and Plenum are using. Would a Ursa member jump in and help clarify this? https://jira.hyperledger.org/browse/IS-1333

MALodder (Fri, 26 Jul 2019 15:15:29 GMT):
thanks for clarifying that. I saw the author was Michael Scott and thought he was doing it

lovesh (Fri, 26 Jul 2019 15:22:31 GMT):
Np

MALodder (Mon, 29 Jul 2019 12:11:25 GMT):
I responded Axel

AxelNennker (Mon, 29 Jul 2019 12:14:09 GMT):
Thank you, cool. Could you give a point to the code you mentioned "The code shows they multiply this base generator" I found the constant in plenum and indy code but not how it comes to be.

AxelNennker (Mon, 29 Jul 2019 12:14:09 GMT):
Thank you, cool. Could you please give a pointer to the code you mentioned "The code shows they multiply this base generator" I found the constant in plenum and indy code but not how it comes to be.

MALodder (Mon, 29 Jul 2019 14:08:09 GMT):
https://github.com/hyperledger/ursa/blob/master/libursa/src/pair/amcl.rs#L238 https://github.com/hyperledger/ursa/blob/master/libursa/src/pair/amcl.rs#L69 https://github.com/hyperledger/ursa/blob/master/libursa/src/bls/mod.rs#L17

AxelNennker (Mon, 29 Jul 2019 20:07:43 GMT):
Hm, that are the code places which _could_ be used to compute the `"3LHpUjiyFC2q2hD7MnwwNmVXiuaFbQx2XkAFJWzswCjgN1utjsCeLzHsKk1nJvFEaS4fcrUmVAkdhtPCYbrVyATZcmzwJReTcJqwqBCPTmTQ9uWPwz6rEncKb2pYYYFcdHa8N17HzVyTqKfgPi4X9pMetfT3A5xCHq54R2pDNYWVLDX"` constant used in Plenum and Indy. I thought there is actually code (in whatever language) that computes this particular value. Or am I misunderstanding this. Thanks for compiling this list

MALodder (Mon, 29 Jul 2019 20:17:47 GMT):
This is the code they ran to generate the value and they saved it off

MALodder (Mon, 29 Jul 2019 20:18:54 GMT):
Next time they should do a nothing up my sleeve value like sha256(“indy_node”) or something like that

hartm (Mon, 29 Jul 2019 22:11:46 GMT):
@MALodder Yeah, it's a good idea to show your randomness for this kind of thing. I would use something with substantially more entropy than "indy_node", but in general you're exactly right.

MALodder (Mon, 29 Jul 2019 22:42:41 GMT):
Right I know longer is better. Just stating the point

lovesh (Tue, 30 Jul 2019 11:19:41 GMT):
Just checking my understanding: you want a longer string to get uniqueness in input. The hash function output would have the same entropy regardless of the input size.

hartm (Wed, 31 Jul 2019 00:11:07 GMT):
The entropy is the amount of randomness in the calculation. Hashing a deterministic string has no entropy since it is deterministic.

hartm (Wed, 31 Jul 2019 00:22:14 GMT):
Entropy is information theoretic, not computational.

lovesh (Wed, 31 Jul 2019 06:27:11 GMT):
Thanks for the correction regarding entropy definition :thumbsup:

lovesh (Wed, 31 Jul 2019 06:27:52 GMT):
But you longer string to get uniqueness in input?

hartm (Wed, 31 Jul 2019 14:46:20 GMT):
What do you mean by uniqueness here? It implies you're sampling from a distribution. Which distribution you are talking about is not clear.

jamesbarry (Wed, 31 Jul 2019 16:53:41 GMT):
Has joined the channel.

luckycharms810 (Wed, 31 Jul 2019 17:22:46 GMT):
Has joined the channel.

cam-parra (Wed, 31 Jul 2019 21:07:30 GMT):
@rjones we need a repo named python-ursa made in the hyperledger org. Can you help us with this?

rjones (Wed, 31 Jul 2019 21:07:32 GMT):
Has joined the channel.

rjones (Wed, 31 Jul 2019 22:34:08 GMT):
@cam-parra would ursa-python work?

cam-parra (Wed, 31 Jul 2019 23:21:34 GMT):
yes that works

cam-parra (Wed, 31 Jul 2019 23:50:49 GMT):
yep that works

Dan (Thu, 01 Aug 2019 02:51:52 GMT):
for what?

rjones (Thu, 01 Aug 2019 03:28:11 GMT):
I didn't realize you're not a maintainer of ursa

rjones (Thu, 01 Aug 2019 03:28:13 GMT):
sorry

cam-parra (Thu, 01 Aug 2019 14:32:32 GMT):
weird... did i get demoted? LOL @MALodder

MALodder (Thu, 01 Aug 2019 14:34:06 GMT):
not that I'm aware of

cam-parra (Thu, 01 Aug 2019 14:35:04 GMT):
oh @rjones my username on github changed

cam-parra (Thu, 01 Aug 2019 14:35:10 GMT):
it's mac-arrap

cam-parra (Thu, 01 Aug 2019 14:35:38 GMT):
https://github.com/mac-arrap

sudheesh001 (Thu, 01 Aug 2019 14:49:54 GMT):
Has joined the channel.

rjones (Fri, 02 Aug 2019 05:00:39 GMT):
ok, it exists, the current ursa-maintainers have maintain access

rjones (Fri, 02 Aug 2019 05:01:15 GMT):
@cam-parra

cam-parra (Fri, 02 Aug 2019 16:40:06 GMT):
for some reason I don't have access to that repo... I have access to URSA but not URSA-python

cam-parra (Fri, 02 Aug 2019 16:47:28 GMT):
@MALodder this PR is ready to be merged

cam-parra (Fri, 02 Aug 2019 16:47:30 GMT):
https://github.com/hyperledger/ursa-python/pull/2

MALodder (Fri, 02 Aug 2019 16:51:03 GMT):
@cam-parra how do I run the tests for this PR?

MALodder (Fri, 02 Aug 2019 16:51:11 GMT):
what command should I use

cam-parra (Fri, 02 Aug 2019 17:45:46 GMT):
Just run pytests inside the repo

cam-parra (Fri, 02 Aug 2019 17:46:11 GMT):
could you try running that and let me know if it works?

rjones (Fri, 02 Aug 2019 17:57:44 GMT):
@cam-parra I think you and @MALodder have the ability to work out the permissions

cam-parra (Fri, 02 Aug 2019 17:59:46 GMT):
thank you

lovesh (Mon, 05 Aug 2019 09:52:24 GMT):
@rjones Can you please send an invite to @khovratovich to become a member of Hyperledger on Gihub? He is Evernym's cryptographer Dmitry Khovratovich

lovesh (Mon, 05 Aug 2019 09:52:24 GMT):
@rjones Can you please send an invite to github user name `khovratovich` to become a member of Hyperledger on Gihub? He is Evernym's cryptographer Dmitry Khovratovich

rjones (Mon, 05 Aug 2019 19:58:30 GMT):
Please send email to community-architects@hyperledger.org @lovesh

lovesh (Tue, 06 Aug 2019 05:44:12 GMT):
Thanks

lovesh (Tue, 06 Aug 2019 05:44:25 GMT):
Done

smithsamuelm (Tue, 06 Aug 2019 14:08:06 GMT):
Has joined the channel.

smithsamuelm (Tue, 06 Aug 2019 14:08:39 GMT):
Has the Sovrin Crypto meeting been replaced by the Ursa meeting on Wed 8 am MDT?

brentzundel (Tue, 06 Aug 2019 14:14:32 GMT):
No, but the Sovrin crypto meeting was canceled yesterday.

cam-parra (Tue, 06 Aug 2019 14:22:16 GMT):
mike is on PTO

AxelNennker (Tue, 06 Aug 2019 15:22:55 GMT):
why does ursa hex encoding exist? There is a standard crate https://docs.rs/hex/0.3.2/hex/ already. I noticed because a PR introduced ursa hex encoding to libindy, which is used four time in trace! I would prefer to use the standard hex crate

AxelNennker (Tue, 06 Aug 2019 15:22:55 GMT):
why does ursa hex encoding exist? There is a standard crate https://docs.rs/hex/0.3.2/hex/ already. I noticed because a PR introduced ursa hex encoding to libindy, which is used four times in trace! I would prefer to use the standard hex crate

cam-parra (Tue, 06 Aug 2019 15:27:07 GMT):
Send the PR and we will review this change @AxelNennker

AxelNennker (Tue, 06 Aug 2019 15:31:36 GMT):
Don't know which PR introduced that to libindy. ``` ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ git log src/commands/payments.rs | fgrep -i ursa ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ git log src/commands/payments.rs | fgrep -i hex ``` Nothing in the logs

AxelNennker (Tue, 06 Aug 2019 15:38:09 GMT):
Learned about git blame -L just now `ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ git blame -L 7 src/commands/payments.rs f50eb287 (Sergey Minaev 2019-07-11 17:23:44 +0300 7) use ursa::encoding::hex; `

cam-parra (Tue, 06 Aug 2019 16:12:30 GMT):
@AxelNennker this looks like both an error in URSA and in libindy. It looks like Rust already implements this native functionality. https://github.com/rust-lang/rust/blob/master/src/libserialize/hex.rs

cam-parra (Tue, 06 Aug 2019 16:13:41 GMT):
unless @lovesh @MALodder have a different need for this hex implementation

AxelNennker (Tue, 06 Aug 2019 16:14:32 GMT):
libindy PR is here https://github.com/hyperledger/indy-sdk/pull/1791

cam-parra (Tue, 06 Aug 2019 16:21:36 GMT):
Great! I have sent the PR to one of the sdk maintainers and hopefully get the eyes of other maintainers on it and have it merged soon

smithsamuelm (Tue, 06 Aug 2019 16:46:12 GMT):
Hyperledger calendar has a stale version of the Sovrin Crypto Meeting on Tuesdays

rjones (Tue, 06 Aug 2019 17:11:05 GMT):
@smithsamuelm should I delete that meeting entirely?

Dan (Tue, 06 Aug 2019 19:41:28 GMT):
Yes, mike moved it to Mondays

Dan (Tue, 06 Aug 2019 19:41:28 GMT):
Yes, Mike moved it to Mondays

hartm (Tue, 06 Aug 2019 20:54:47 GMT):
I just created an agenda for tomorrow's meeting--feel free to add stuff as you all see fit. Thanks!

MALodder (Wed, 07 Aug 2019 03:11:07 GMT):
Regrets for tomorrow. I’m on vacation for the whole week.

hartm (Wed, 07 Aug 2019 13:44:09 GMT):
@MALodder Enjoy your vacation!

cam-parra (Wed, 07 Aug 2019 16:01:43 GMT):
@lovesh Could you please review this PR? It will unblock the CI/CD pipeline work

cam-parra (Wed, 07 Aug 2019 16:01:51 GMT):
https://github.com/hyperledger/ursa-python/pull/2

lovesh (Wed, 07 Aug 2019 20:03:59 GMT):
Is this taken from indy-crypto's python wrapper/

lovesh (Wed, 07 Aug 2019 20:03:59 GMT):
Is this taken from indy-crypto's python wrapper?

cam-parra (Wed, 07 Aug 2019 20:04:08 GMT):
yep

cam-parra (Wed, 07 Aug 2019 20:04:21 GMT):
yep

lovesh (Wed, 07 Aug 2019 20:07:17 GMT):
@hartm @MALodder @Dan Should the PS signatures go in libursa or libzmix?

lovesh (Wed, 07 Aug 2019 20:12:30 GMT):
Approved. But have asked 2 questions

MALodder (Wed, 07 Aug 2019 20:15:16 GMT):
PS sigs should go in libzmix

MALodder (Thu, 08 Aug 2019 14:59:01 GMT):
@lovesh are you planning to implement the threshold PS sig?

MALodder (Thu, 08 Aug 2019 14:59:08 GMT):
otherwise why do we need them?

Dan (Thu, 08 Aug 2019 15:02:49 GMT):
I think a point of discussion during the Ursa meeting yesterday was that PS should be proposed through RFC. Of course, RFC is a lengthy process so totally encourage us to sort out as much of the issues over chat/email/meeting before going into the authoring process.

hartm (Thu, 08 Aug 2019 15:08:34 GMT):
An RFC for something like threshold PS sigs should be pretty simple though. The interface is obvious (so no need to do much work there) and the question of need is pretty obvious to (do we need the threshold signatures). So I don't think an RFC for this should be too onerous.

hartm (Thu, 08 Aug 2019 15:08:58 GMT):
At least, I hope the RFC isn't too onerous. And I also hope that it serves as a template for future interface documentation (so the effort isn't wasted).

Dan (Thu, 08 Aug 2019 15:29:38 GMT):
One should never assume that anything is obvious. :) I don't mind saying I'm pretty ignorant of PS sigs and could not argue for or against another threshold scheme. I also couldn't explain how this would work well or badly with all the other schemes.

hartm (Thu, 08 Aug 2019 16:04:36 GMT):
@Dan All pairings-based threshold signatures are "more or less" the same--use Shamir secret sharing in the exponent, and use the pairing to compute the products needed for the secret sharing evaluation. Now that you mention it, it might actually make sense to have a modular piece of code that does Shamir secret sharing.

satelander (Thu, 08 Aug 2019 21:34:49 GMT):
splinter

Dan (Fri, 09 Aug 2019 15:17:30 GMT):
what i meant by "I also couldn't explain how this would work well or badly with all the other schemes," is the other schemes in ursa. We should think about implications of having a library with a bunch of different groups/schemes. The paillier group, for example, feels very different to me than any of the elliptic groups. When we have all of these in the same library is there a way to compose across them or risks because it seems that you can when you shouldn't. So that kind of thing.

Dan (Fri, 09 Aug 2019 15:17:30 GMT):
what i meant by "I also couldn't explain how this would work well or badly with all the other schemes," is how we should think about having a library with a bunch of different groups/schemes. The paillier group, for example, feels very different to me than any of the elliptic groups. When we have all of these in the same library is there a way to compose across them or risks because it seems that you can when you shouldn't. So that kind of thing.

hartm (Mon, 12 Aug 2019 05:03:21 GMT):
@Dan Composing high-level crypto protocols (i.e., not just "oracles" like hash functions) is a very hard problem in general. If you really want to take the plunge, this is excellent: https://eprint.iacr.org/2000/067.pdf

Dan (Mon, 12 Aug 2019 13:59:55 GMT):
At only 100 pages that looks like a light read ;)

hartm (Mon, 12 Aug 2019 15:57:59 GMT):
Is anyone in this channel attending CRYPTO next week?

MALodder (Mon, 12 Aug 2019 20:14:48 GMT):
@rjones can you make the ursa-python repo have the same maintainers as the ursa repo?

cam-parra (Mon, 12 Aug 2019 20:15:33 GMT):
Yeah none of the maintainers have write access to the repo. Including @lovesh @MALodder

rjones (Mon, 12 Aug 2019 20:19:30 GMT):
Done

MALodder (Tue, 13 Aug 2019 12:13:46 GMT):
https://github.com/streaak/keyhacks?mc_cid=2c7d4caad8&mc_eid=0ff0c85eaf#Google-Maps-API-key

MALodder (Tue, 13 Aug 2019 12:14:02 GMT):
Good place to. Check if our keys have been hacked

MALodder (Tue, 13 Aug 2019 12:14:02 GMT):
Good place to check if our keys have been hacked

brentzundel (Tue, 13 Aug 2019 20:07:42 GMT):
I was just asked whether ursa libraries have been cleared for US export?

MALodder (Tue, 13 Aug 2019 20:13:23 GMT):
probably not

brentzundel (Tue, 13 Aug 2019 20:15:50 GMT):
Perhaps we should draft a statement similar to the following: https://mta.openssl.org/pipermail/openssl-users/2015-October/002186.html

brentzundel (Tue, 13 Aug 2019 20:22:19 GMT):
Can we add this to the next ursa meeting? I think it will be an important answer to have for companies that want to use products which rely on ursa.

brentzundel (Tue, 13 Aug 2019 20:30:21 GMT):
Or is ursa covered under the linux foundation's filing for the hyperledger project?

hartm (Tue, 13 Aug 2019 21:31:01 GMT):
I imagine we are probably covered. @dhuseby do you know anything about this?

cam-parra (Tue, 13 Aug 2019 22:00:17 GMT):
https://github.com/hyperledger/ursa/pull/47

cam-parra (Tue, 13 Aug 2019 22:00:33 GMT):
can we get another set of eyes on this PR?

Dan (Wed, 14 Aug 2019 15:32:12 GMT):
we should talk about containerizing the builds and how that relates to travis and other CI stuff. Like in that PR above, if we just had a build container it could go right into that, and likewise the readme could just give a docker command instead of needing to track changes as we add / update things.

MALodder (Wed, 14 Aug 2019 16:46:46 GMT):
@Dan I believe travis is using containers already

MALodder (Wed, 14 Aug 2019 16:47:07 GMT):
we should probably move to circleci because travis is being phased out

Dan (Wed, 14 Aug 2019 17:26:17 GMT):
I mean using the docker files we maintain in the repo for build and then whatever system we use consumes those as well as anyone who wants to run a local build can just run e.g. `docker-compose up`

GuillaumeCisco (Wed, 14 Aug 2019 18:31:32 GMT):
Has joined the channel.

Kirill_Vusik (Thu, 15 Aug 2019 13:30:12 GMT):
Has joined the channel.

dmitrylavrenov (Thu, 15 Aug 2019 15:13:40 GMT):
Has joined the channel.

Kirill_Vusik (Fri, 16 Aug 2019 11:43:02 GMT):
Hello, @dmitrylavrenov and I are interested in contributing to Ursa. Dmitry is a cryptography expert, I know Rust a bit :) What could you recommend us to starts with? There are only few issues in Jira as I see

hartm (Fri, 16 Aug 2019 16:07:22 GMT):
@Kirill_Vusik What part of Ursa are you all interested in working on? Are there any new features you'd like to see?

Kirill_Vusik (Fri, 16 Aug 2019 16:51:26 GMT):
@hartm We would like to help implementing concreate algorithms, also we can help with Zero-Knowledge proof features implementation

MALodder (Fri, 16 Aug 2019 19:05:03 GMT):
@Kirill_Vusik You should attend the Sovrin Crypto call on Monday at 8am PDT where we talk about many of the ZKP features we want to implement

MALodder (Fri, 16 Aug 2019 19:05:59 GMT):
The zoom id is https://zoom.us/j/567114224

MALodder (Fri, 16 Aug 2019 19:07:17 GMT):
The next ZKP thing we want to develop is a ZKP based on zcash's snark library bellman

MALodder (Fri, 16 Aug 2019 19:08:09 GMT):
take a look at https://github.com/matter-labs/bellman if you're interested

adityasingh177 (Mon, 19 Aug 2019 09:51:13 GMT):
Has joined the channel.

lovesh (Mon, 19 Aug 2019 11:06:29 GMT):
We don't have any signature scheme with PoK implemented for Anoncreds 2.0 so even if we don't use it for threshold sigs, it would be useful. Secondly, we wanted Zmix to support PS signatures anyway.

MALodder (Mon, 19 Aug 2019 11:53:47 GMT):
Isn’t that what BBS signatures are too?

lovesh (Mon, 19 Aug 2019 12:12:02 GMT):
Do you have a link you can share?

MALodder (Mon, 19 Aug 2019 12:20:58 GMT):
For?

lovesh (Mon, 19 Aug 2019 12:21:32 GMT):
BBS signatures

MALodder (Mon, 19 Aug 2019 12:22:41 GMT):
https://link.springer.com/content/pdf/10.1007%2F978-3-642-00468-1_27.pdf

MALodder (Mon, 19 Aug 2019 12:23:43 GMT):
Sorry that’s not it

MALodder (Mon, 19 Aug 2019 12:24:15 GMT):
https://eprint.iacr.org/2016/663.pdf

MALodder (Mon, 19 Aug 2019 12:24:19 GMT):
Section 4

MALodder (Mon, 19 Aug 2019 12:24:36 GMT):
It’s always been my understanding that BBS and PS are interchangeable

MALodder (Mon, 19 Aug 2019 12:24:45 GMT):
Both offer PoK

lovesh (Mon, 19 Aug 2019 12:25:22 GMT):
I was looking for the implementation link

lovesh (Mon, 19 Aug 2019 12:25:49 GMT):
Depends what you mean by interchangable.

MALodder (Mon, 19 Aug 2019 12:25:51 GMT):
I guess it’s okay if we have both

MALodder (Mon, 19 Aug 2019 12:26:04 GMT):
It would be nice to benchmark and compare the teo

MALodder (Mon, 19 Aug 2019 12:26:04 GMT):
It would be nice to benchmark and compare the two

lovesh (Mon, 19 Aug 2019 12:26:13 GMT):
PS was supposed to be one of the supported sig schemes

lovesh (Mon, 19 Aug 2019 12:26:21 GMT):
Ok

lovesh (Mon, 19 Aug 2019 12:26:50 GMT):
Where can i see the latest work on Zmix? Is it in the PR?

MALodder (Mon, 19 Aug 2019 12:28:37 GMT):
Eventually. You just accelerated the time line

MALodder (Mon, 19 Aug 2019 12:28:56 GMT):
We mostly want the threshold capability too

MALodder (Mon, 19 Aug 2019 12:29:15 GMT):
If PS is faster than BBS then I say we just use that one

hartm (Mon, 19 Aug 2019 15:01:58 GMT):
Cohttps://crypto.iacr.org/2019/program.html

lovesh (Mon, 19 Aug 2019 15:03:40 GMT):
typo in link, correct link here https://crypto.iacr.org/2019/program.html

lovesh (Mon, 19 Aug 2019 15:06:26 GMT):
@Dan Are you fine with the verifiable encryption PR https://github.com/hyperledger/ursa-rfcs/pull/9

hartm (Mon, 19 Aug 2019 15:13:54 GMT):
https://eprint.iacr.org/2010/543.pdf

MALodder (Mon, 19 Aug 2019 16:46:57 GMT):
I coded a guide to help those needing a push to use ursa https://github.com/mikelodder7/ursa_demo

Kamil_Salakhiev (Tue, 20 Aug 2019 12:46:20 GMT):
Has joined the channel.

Kamil_Salakhiev (Tue, 20 Aug 2019 12:46:21 GMT):
Hey! Is there a support or any plans for the Russian crypto in Ursa?

MALodder (Tue, 20 Aug 2019 14:02:21 GMT):
the great thing about open source is you can add it to ursa and contribute it

MALodder (Tue, 20 Aug 2019 14:02:55 GMT):
No one in particular is planning to add it, but its been designed such that its easy to add

Kamil_Salakhiev (Tue, 20 Aug 2019 14:34:38 GMT):
Great! What is the best way to start with it? I know that openssl supports Russian cryptography. Do you use openssl anyhow? If you do I think it is really easy to integrate

MALodder (Tue, 20 Aug 2019 16:01:48 GMT):
Yes Ursa is using openssl but just for its Bignumber library. We do have an RFC for encryption https://github.com/hyperledger/ursa-rfcs/pull/6 that you can use as a guide

Dan (Tue, 20 Aug 2019 16:10:44 GMT):
I think the best pattern is to create modular interfaces. That way various national cryptos can be attached without needing to incorporate the code directly into Ursa.

Dan (Tue, 20 Aug 2019 16:11:01 GMT):
I've put draft agenda up for tomorrow: https://wiki.hyperledger.org/display/ursa/2019+08+21

rjones (Tue, 20 Aug 2019 17:29:50 GMT):
I thought Ursa already had a modular interface?

MALodder (Tue, 20 Aug 2019 17:52:45 GMT):
it does, that's what I'm suggesting for @Kamil_Salakhiev to use

kdenhartog (Wed, 21 Aug 2019 01:30:51 GMT):
Can a Double Ratchet algorithm be setup between multiple parties? If so what's the difference between that structure and an Async Ratchet tree?

MALodder (Wed, 21 Aug 2019 01:50:45 GMT):
Not really. Signal hides the complexity behind the scenes

MALodder (Wed, 21 Aug 2019 01:51:12 GMT):
The Async tree is completely different in that it incorporates multiple keys

hartm (Wed, 21 Aug 2019 06:24:03 GMT):
@here Just a reminder of today/tomorrow's Ursa meeting. Hope to talk to many of you tomorrow!

JonGeater (Wed, 21 Aug 2019 09:09:03 GMT):
Oh! The Ursa meeting series has fallen off my calendar and I thought it was next week :( I have a customer meeting today :(

JonGeater (Wed, 21 Aug 2019 09:09:55 GMT):
I really wanted to talk about the sovereign algorithms and modular interfaces with @Dan and @Kamil_Salakhiev

JonGeater (Wed, 21 Aug 2019 09:11:13 GMT):
We did this a lot in Thales to enable sales of high grade cryptos to various mutually distrustful customers

Dan (Wed, 21 Aug 2019 13:20:38 GMT):
no worries .. we can hit that next meeting.

Kirill_Vusik (Wed, 21 Aug 2019 13:40:45 GMT):
Hello everyone, @dmitrylavrenov and I cannot attend the meeting today: we have conflicts with our meetings. Could we ask to record it?

Dan (Wed, 21 Aug 2019 13:51:38 GMT):
конечно :)

Kirill_Vusik (Wed, 21 Aug 2019 13:53:24 GMT):
спасибо :)

Dan (Wed, 21 Aug 2019 13:56:25 GMT):
Usually Hart records and then posts the recording later.

Dan (Wed, 21 Aug 2019 13:56:51 GMT):
I think he is at a conference though so that might make recording more difficult. I'm not sure.

hartm (Wed, 21 Aug 2019 13:56:57 GMT):
I can still record.

hartm (Wed, 21 Aug 2019 13:57:02 GMT):
I'll make sure to post.

hartm (Wed, 21 Aug 2019 13:57:11 GMT):
It might take until this afternoon though.

hartm (Wed, 21 Aug 2019 22:31:22 GMT):
OK, I've added the recording.

lovesh (Thu, 22 Aug 2019 07:03:51 GMT):
@Dan I have skimmed over the EPID scheme and see that proof of non-revocation is linear (in size and time) in the size of revocation list (page 11, Sign.5) whereas in our case of merkle tree its logarithimic. Also in EPID, each non-revocation sub proof (for each item in revocation list) is much bigger and expensive since its a proof of inequality of discrete log

Kirill_Vusik (Thu, 22 Aug 2019 09:57:45 GMT):
thank you

Artemkaaas (Fri, 23 Aug 2019 12:57:02 GMT):
Has joined the channel.

Artemkaaas (Fri, 23 Aug 2019 12:57:03 GMT):
@MALodder Is ursa (master branch) published to crates.io automatically? My PR was merged a couple days ago but the last available version on https://crates.io/crates/ursa was released in April. It's a important issue for Libindy. FYI @esplinr

satelander (Fri, 23 Aug 2019 18:45:50 GMT):
Has left the channel.

MALodder (Fri, 23 Aug 2019 19:31:06 GMT):
we don't have master automatically published to crates.io

MALodder (Fri, 23 Aug 2019 19:31:16 GMT):
I can make a build if you want

JonGeater (Sat, 24 Aug 2019 16:11:08 GMT):
Would we really want to do that before a full 1.0?

binhn (Sat, 24 Aug 2019 22:50:57 GMT):
is anyone working on threshold ECDSA? I just came across this interesting deck https://zengo.com/wp-content/uploads/2019/06/breaking_bitcoin19_updated.pdf

rjones (Sun, 25 Aug 2019 19:28:40 GMT):
Is this list accurate? https://github.com/orgs/hyperledger/teams/ursa-maintainers/members @hartm @MALodder

JonGeater (Sun, 25 Aug 2019 22:09:29 GMT):
I’m getting 404 from that link

JonGeater (Sun, 25 Aug 2019 22:12:17 GMT):
Looks like ‘members’ is not right

rjones (Sun, 25 Aug 2019 22:48:22 GMT):
hmm - if you're logged in to GitHub, it should be a public link

rjones (Sun, 25 Aug 2019 22:50:16 GMT):
@JonGeater I sent a github invite to JAG-UK

JonGeater (Sun, 25 Aug 2019 23:14:14 GMT):
Ah! I fell foul of the recent 2FA change. Hold on...

rjones (Sun, 25 Aug 2019 23:24:17 GMT):
I'm about to remove ~150 of the 200 members we have anyway

Artemkaaas (Mon, 26 Aug 2019 05:39:53 GMT):
yes, please

Artemkaaas (Mon, 26 Aug 2019 05:44:56 GMT):
Since Libindy migrated to Ursa crate. it's pretty important for us to have automatically published artifact as Indy-Crypto used to do.

cam-parra (Mon, 26 Aug 2019 13:12:02 GMT):
The maintainer list is accurate :)

cam-parra (Mon, 26 Aug 2019 13:12:52 GMT):
All members on that list are frequent contributors in one way or another

JonGeater (Mon, 26 Aug 2019 16:58:17 GMT):
I've just applied to join... :-)

cam-parra (Mon, 26 Aug 2019 17:31:49 GMT):
We can get you added. @MALodder I think you can add other maintainers

cam-parra (Mon, 26 Aug 2019 17:31:51 GMT):
https://github.com/orgs/hyperledger/teams/ursa-maintainers/members

MALodder (Mon, 26 Aug 2019 17:32:50 GMT):
@JonGeater whats your github handle

cam-parra (Mon, 26 Aug 2019 17:38:26 GMT):
we should probably do a quick video confirmation that it's the real @JonGeater

cam-parra (Mon, 26 Aug 2019 17:38:35 GMT):
*tin foil hat is on*

rjones (Mon, 26 Aug 2019 17:39:17 GMT):
could I ask you to hold on a second?

rjones (Mon, 26 Aug 2019 17:39:32 GMT):
@cam-parra @MALodder

cam-parra (Mon, 26 Aug 2019 17:39:59 GMT):
sure thing :thumbsup:

rjones (Mon, 26 Aug 2019 17:53:55 GMT):
@cam-parra I just added some codeowners files that reflect the current state of permissions for the four ursa repos

rjones (Mon, 26 Aug 2019 17:54:17 GMT):
if these are merged, I will turn on the codeowners option

rjones (Mon, 26 Aug 2019 17:54:49 GMT):
eventually, we'll have an automagic process for turning updates to that file into group updates. (not today though)

rjones (Mon, 26 Aug 2019 18:03:44 GMT):
hi, I suck. I had to recreate https://github.com/hyperledger/ursa-python

cam-parra (Mon, 26 Aug 2019 18:59:17 GMT):
no worries, we shall rebuild

cam-parra (Mon, 26 Aug 2019 19:00:22 GMT):
also @rjones your pr has been merged you are good to turn on codeowners

cam-parra (Mon, 26 Aug 2019 20:18:39 GMT):
are we good to add @JonGeater ?

rjones (Mon, 26 Aug 2019 20:26:45 GMT):
that is a question for you to answer. If you update the codeowners file, you'll still need to add him to your team manually (for now)

rjones (Mon, 26 Aug 2019 20:27:38 GMT):
I now see that I added the codeowners file in the worst possible way. You can point to a team directly, which would make updates trivial. I would like to use codeowners to populate the groups... later

MALodder (Tue, 27 Aug 2019 14:34:42 GMT):
He has my vote.

JonGeater (Tue, 27 Aug 2019 14:41:18 GMT):
Thanks! (As a technical note for @rjones for later/other projects, I guess I would have been in there already if overleaf had been included, or if we'd done the doc in github)

Dan (Tue, 27 Aug 2019 14:43:35 GMT):
Someone remind me where we are doing the zmix spec?

MALodder (Tue, 27 Aug 2019 15:07:11 GMT):
https://github.com/hyperledger/ursa-rfcs/pull/12

MALodder (Tue, 27 Aug 2019 15:07:18 GMT):
@Dan ^^

MALodder (Tue, 27 Aug 2019 15:09:26 GMT):
@JonGeater what is your github handle?

Dan (Tue, 27 Aug 2019 15:10:40 GMT):
thanks @MALodder. I meant to write zklang ... coffee still kicking in. Where are we spec'ing out zklang?

MALodder (Tue, 27 Aug 2019 15:18:48 GMT):
that's it

MALodder (Tue, 27 Aug 2019 15:19:02 GMT):
zmix with ZKLang

MALodder (Tue, 27 Aug 2019 15:19:08 GMT):
zmix is just the orchestration layer

MALodder (Tue, 27 Aug 2019 15:19:13 GMT):
ZKLang is the data model

MALodder (Tue, 27 Aug 2019 15:19:41 GMT):
@brentzundel and I had a meeting on Monday with Dfinity to flush out more details

Dan (Tue, 27 Aug 2019 15:20:46 GMT):
ok, I'll set aside some time to start digging into #12

JonGeater (Tue, 27 Aug 2019 16:30:28 GMT):
JAG_UK

cam-parra (Tue, 27 Aug 2019 16:32:16 GMT):
Do you have time for a quick visual confirmation?

JonGeater (Tue, 27 Aug 2019 16:32:34 GMT):
Sure

cam-parra (Tue, 27 Aug 2019 16:32:51 GMT):
@MALodder want to join in?

JonGeater (Tue, 27 Aug 2019 16:33:05 GMT):
Sure

cam-parra (Tue, 27 Aug 2019 16:34:50 GMT):
Actually heading to the Sovrin offices so can we do this at around 12:30 MST?

JonGeater (Tue, 27 Aug 2019 16:41:52 GMT):
Thats 1 hour from now?

hartm (Tue, 27 Aug 2019 16:56:10 GMT):
Oh, that's what that random request was from.

JonGeater (Tue, 27 Aug 2019 16:56:46 GMT):
Not entirley random....but unexplained, yes :^)

hartm (Tue, 27 Aug 2019 16:57:22 GMT):
I was wondering who was attempting to join the org, haha.

cam-parra (Tue, 27 Aug 2019 17:00:00 GMT):
Lol just want to be sure he’s not a robot

JonGeater (Tue, 27 Aug 2019 17:00:25 GMT):
There are members of my family who would not want to warrant that

cam-parra (Tue, 27 Aug 2019 18:27:30 GMT):
@MALodder will you do this after your meeting ?

JonGeater (Tue, 27 Aug 2019 18:29:17 GMT):
Let me know if and when: I’m having dinner but I should be able to do a quick call of some kind

MALodder (Tue, 27 Aug 2019 20:10:39 GMT):
added

JonGeater (Tue, 27 Aug 2019 22:10:26 GMT):
Just got the join notice. Thanks @MALodder :)

MALodder (Wed, 28 Aug 2019 13:15:42 GMT):
I would like to propose that the Ursa-RFC PR #6 be put in final comment and merged in two weeks if there are no reasonable arguments. The PR has sat for 6 months without any new comments since april. Silence can be seen as agreeing and nothing further to add or uninvolvement.

lovesh (Wed, 28 Aug 2019 13:21:46 GMT):
I agree

hartm (Wed, 28 Aug 2019 15:40:03 GMT):
@MALodder Sure, that sounds good.

hartm (Wed, 28 Aug 2019 15:40:48 GMT):
We may need to append to it if we want to allow for more modular block cipher support, but that's probably not a huge issue.

domwoe (Thu, 29 Aug 2019 12:21:25 GMT):
Has joined the channel.

cam-parra (Thu, 29 Aug 2019 15:13:59 GMT):
@lovesh @MALodder PS signatures have been merged

MALodder (Thu, 29 Aug 2019 15:14:39 GMT):
nice

Dan (Thu, 29 Aug 2019 15:34:16 GMT):
@MALodder can you make sure all the maintainers are listed as reviewers on #6

MALodder (Thu, 29 Aug 2019 15:34:39 GMT):
I thought they already were

Dan (Thu, 29 Aug 2019 15:37:18 GMT):
I think I might fight this one just because of the latex ;)

Dan (Thu, 29 Aug 2019 16:00:43 GMT):
Actually more seriously I don't see any math notation in the tex file. It would be easier to review if we folded that text into md file. I say that not for busy work but because we can also better see the whole API in one doc. It looks to me for example that the object types alluded to in the md file don't align with those in the tex file. @hartm @MALodder thoughts?

MALodder (Thu, 29 Aug 2019 16:16:25 GMT):
I'm okay changing this one to be markdown

hartm (Thu, 29 Aug 2019 17:19:45 GMT):
I guess the whole point of this is, in fact, to abstract away the math. If you think it will be more convenient in markdown, I'm fine with that.

hartm (Thu, 29 Aug 2019 17:20:01 GMT):
We will probably still need TeX for some cryptographer interfaces though.

cam-parra (Thu, 29 Aug 2019 17:25:12 GMT):
If equations are needed you can always include a .png in the markdown

cam-parra (Thu, 29 Aug 2019 17:25:35 GMT):
I used to do that all the time in college

hartm (Thu, 29 Aug 2019 17:43:08 GMT):
That is so inconvenient though.

hartm (Thu, 29 Aug 2019 17:43:17 GMT):
Once you get used to TeX, there's no going back.

cam-parra (Thu, 29 Aug 2019 17:46:10 GMT):
I just use emacs org mode and then use it's latex generator :)

cam-parra (Thu, 29 Aug 2019 17:46:18 GMT):
way better and easier than plain tex

rjones (Thu, 29 Aug 2019 21:05:37 GMT):
vi is love, vi is life

JonGeater (Thu, 29 Aug 2019 22:15:24 GMT):
vi is implementable in emacs

cam-parra (Thu, 29 Aug 2019 22:59:04 GMT):
colon q ! return

rjones (Thu, 29 Aug 2019 23:03:26 GMT):
My headstone needs to read `:wq!`

MALodder (Fri, 30 Aug 2019 23:22:41 GMT):
Just use `:x!` one key shorter

rjones (Sat, 31 Aug 2019 00:46:36 GMT):
just get cremated, it's one headstone shorter

MALodder (Mon, 02 Sep 2019 13:38:12 GMT):
Reminder: no Sovrin Crypto meeting today due to the US holiday

MALodder (Tue, 03 Sep 2019 14:56:09 GMT):
@JonGeater Do you have the slides you used the last time you presented on Ursa?

MALodder (Tue, 03 Sep 2019 14:56:26 GMT):
@JonGeater have those been made public so some else could use them?

JonGeater (Tue, 03 Sep 2019 15:32:06 GMT):
Yes they're under 'files' on the Hyperledger wiki space for Ursa

JonGeater (Tue, 03 Sep 2019 15:33:18 GMT):
https://wiki.hyperledger.org/display/ursa/Presentations

MALodder (Tue, 03 Sep 2019 15:33:35 GMT):
thanks

JonGeater (Tue, 03 Sep 2019 15:34:39 GMT):
There's also a video of me presenting it somewhere, if you want the voiceover I can PM it to you

JonGeater (Tue, 03 Sep 2019 15:34:49 GMT):
But it's quite self-explanatory

MALodder (Tue, 03 Sep 2019 16:06:55 GMT):
No worries. Your voice sounds better than mine anyway

lovesh (Wed, 04 Sep 2019 14:12:29 GMT):
Please update the agenda with this item: Delegatable credentials based on the paper Practical UC-Secure Delegatable Credentials with Attributes and Their Application to Blockchain (https://acmccs.github.io/papers/p683-camenischA.pdf) Code is here https://github.com/lovesh/signature-schemes/tree/delegatable/delg_cred_cdd

JonGeater (Wed, 04 Sep 2019 15:13:39 GMT):
https://wiki.hyperledger.org/pages/viewpage.action?pageId=16324764

JonGeater (Wed, 04 Sep 2019 15:14:59 GMT):
I actually like the principle of TCF but I still don't know what Besu is actually supposed to be: generalising this architecture is capital-H-Hard. If it's not generalised then I'm not sure why it needs to be a project. Anyway, I think my questions/points are relevant to the concversation we just had in the call

JonGeater (Wed, 04 Sep 2019 15:15:09 GMT):
(Minutes uploaded to the usual place)

Dan (Fri, 06 Sep 2019 17:33:52 GMT):
*Maintainers* I don't see any of you registered: https://wiki.hyperledger.org/display/events/Maintainer+Summit+October+8-10%2C+2019

cam-parra (Fri, 06 Sep 2019 17:40:47 GMT):
Done! Save me a seat

JonGeater (Sat, 07 Sep 2019 14:47:57 GMT):
I can't go

MALodder (Mon, 09 Sep 2019 15:52:53 GMT):
I believe I’m going

hartm (Mon, 09 Sep 2019 21:16:57 GMT):
I RSVP'd too.

hartm (Mon, 09 Sep 2019 21:17:13 GMT):
Ideally we can put together an agenda ahead of time.

Dan (Thu, 12 Sep 2019 10:02:11 GMT):
@hartm cool. Yes there is an agenda page which you are encouraged to add to.

Dan (Thu, 12 Sep 2019 10:02:24 GMT):
According to a text book, the units in F[x] (ring of polynomials over field F) are exactly the nonzero elements of the field, F. That seems to ignore a lot of elements of F[x] which have inverses. For example the product of any monic polynomials whose degrees sum to phi(p) would seem to meet the definition of units. e.g. in Z_5, x * x^3 = x^4 = 1. Am I misunderstanding the definition of the elements of the field of polynomials or is perhaps this definition of units in the text misleading. It is not accompanied by a proof.

Dan (Thu, 12 Sep 2019 10:02:24 GMT):
According to a text book, the units in F[x] (field of polynomials) are exactly the nonzero elements of the field, F. That seems to ignore a lot of elements of F[x] which have inverses. For example the product of any monic polynomials whose degrees sum to phi(p) would seem to meet the definition of units. e.g. in Z_5, x * x^3 = x^4 = 1. Am I misunderstanding the definition of the elements of the field of polynomials or is perhaps this definition of units in the text misleading. It is not accompanied by a proof.

hartm (Thu, 12 Sep 2019 13:52:40 GMT):
@Dan Do you mean the ring of polynomials over a field?

Dan (Thu, 12 Sep 2019 13:57:17 GMT):
Yeah

Dan (Thu, 12 Sep 2019 13:57:17 GMT):
Yeah .. fixed typo. Thanks.

hartm (Thu, 12 Sep 2019 14:00:21 GMT):
Here's an explanation: https://math.stackexchange.com/questions/354505/units-of-polynomial-rings-over-a-field

hartm (Thu, 12 Sep 2019 14:02:21 GMT):
Are you sure you aren't considering R[x] / f(x) rather than just R[x]?

donqui (Thu, 12 Sep 2019 14:16:36 GMT):
Has left the channel.

MALodder (Fri, 13 Sep 2019 18:43:42 GMT):
https://github.com/hyperledger/ursa/pull/55

MALodder (Fri, 13 Sep 2019 18:44:04 GMT):
if you run `cargo bench` it shows that key generation for PS is 2-3X slower than BBS+

MALodder (Fri, 13 Sep 2019 18:44:27 GMT):
it also shows that signing for PS is 2-3X slower than BBS+

MALodder (Fri, 13 Sep 2019 18:44:52 GMT):
however, its all in the order of milliseconds, so it may not be important

MALodder (Fri, 13 Sep 2019 18:45:40 GMT):
for example, bbs keygen for 100 messages is `52.096 ms`

MALodder (Fri, 13 Sep 2019 18:45:57 GMT):
ps keygen for 100 messages is `135.76 ms`

MALodder (Fri, 13 Sep 2019 18:46:30 GMT):
bbs+ for sign without any prior commitments is `12.376 ms`

MALodder (Fri, 13 Sep 2019 18:46:30 GMT):
bbs+ for sign without any prior commitments with 100 messages is `12.376 ms`

MALodder (Fri, 13 Sep 2019 18:48:02 GMT):
ps for sign without any prior commitments is `31.222 ms` signing with prior commitments (blinded signatures) will be faster than those

MALodder (Fri, 13 Sep 2019 18:48:02 GMT):
ps for sign without any prior commitments with 100 messages is `31.222 ms` signing with prior commitments (blinded signatures) will be faster than those

MALodder (Fri, 13 Sep 2019 18:48:10 GMT):
that's on my personal macbook

lovesh (Fri, 13 Sep 2019 20:12:48 GMT):
Depending on the feature selected, PS will have either faster sig or proof of knowledge of sig. The default feature (PS_G1G2) makes proof of knowledge faster since that is much more common occurence than signing

lovesh (Fri, 13 Sep 2019 20:13:17 GMT):
Secondly is there some benchmark/test code you run to measure timing for BBS+

MALodder (Fri, 13 Sep 2019 20:45:04 GMT):
That’s my next benchmark

dhuseby (Fri, 13 Sep 2019 21:06:53 GMT):
@here I just received an email from the Iroha team that their intern just completed the work of moving Iroha over to Ursa.

dhuseby (Fri, 13 Sep 2019 21:07:16 GMT):
Iroha is the first of the HL DLTs to *move* to Ursa (Indy kind of supported it from the start).

dhuseby (Fri, 13 Sep 2019 21:07:25 GMT):
congratulations everybody!!

danielhardman (Fri, 13 Sep 2019 21:07:46 GMT):
+1000

MALodder (Mon, 16 Sep 2019 12:32:04 GMT):
No Sovrin Crypto call today. Some participants are at TPAC and I have a family engagement today. See you all Wednesday morning

Dan (Mon, 16 Sep 2019 12:42:20 GMT):
What do you think about moving the Sovrin Crypto call to wednesdays alternating with the ursa call?

JonGeater (Mon, 16 Sep 2019 12:45:01 GMT):
That would mean I'd be able to attend

hartm (Mon, 16 Sep 2019 14:51:37 GMT):
I'm fine with that as well. Bringing regularity to my schedule is always a good thing.

rjones (Mon, 16 Sep 2019 15:36:04 GMT):
Has left the channel.

JonGeater (Wed, 18 Sep 2019 13:59:13 GMT):
Is there a call today? I missed the usual friendly reminder...joining anyway (although I've done nothing this week :-( )

Dan (Wed, 18 Sep 2019 14:08:31 GMT):
https://tools.ietf.org/html/rfc8235#page-8

MALodder (Wed, 18 Sep 2019 14:11:25 GMT):
There is a conflict with an Indy/Aries call that is on the off week from Ursa, otherwise I would do that. That time was the initial thought to where to move it

Dan (Wed, 18 Sep 2019 14:54:00 GMT):
@dhuseby Regarding the Iroha adoption .. is there a bundle of commits the curious among us could peruse?

JonGeater (Wed, 18 Sep 2019 14:58:11 GMT):
https://github.com/hyperledger/iroha/commit/b3adc310e9c797c9dd5c99e4a7b518f2c5cf50f0

MALodder (Wed, 18 Sep 2019 16:43:23 GMT):
In reviewing PS signatures, I don't see how `SigKey` is being cleared on Drop

MALodder (Wed, 18 Sep 2019 16:43:28 GMT):
@lovesh ^^

MALodder (Wed, 18 Sep 2019 16:43:43 GMT):
Should I raise a Jira ticket for this?

lovesh (Wed, 18 Sep 2019 16:51:20 GMT):
Sigkey wraps a group element which is set to infinity on Drop

MALodder (Wed, 18 Sep 2019 16:59:49 GMT):
I see this `https://github.com/lovesh/amcl_rust_wrapper/blob/master/src/group_elem.rs#L145`

MALodder (Wed, 18 Sep 2019 16:59:54 GMT):
is there another area

lovesh (Wed, 18 Sep 2019 17:37:38 GMT):
Thats it

MALodder (Wed, 18 Sep 2019 17:52:10 GMT):
@hartm what are your thoughts on PQ Sigs especially about https://eprint.iacr.org/2019/893.pdf

hartm (Wed, 18 Sep 2019 18:58:32 GMT):
@MALodder are you on the NIST PQC mailing list?

hartm (Wed, 18 Sep 2019 18:59:43 GMT):
There has been a lot of discussion around Falcon recently.

MALodder (Wed, 18 Sep 2019 19:56:15 GMT):
no I'm not

MALodder (Thu, 19 Sep 2019 15:03:11 GMT):
New PRs https://github.com/hyperledger/ursa/pull/60

MALodder (Thu, 19 Sep 2019 15:03:23 GMT):
and https://github.com/hyperledger/ursa/pull/59

MALodder (Thu, 19 Sep 2019 15:08:42 GMT):
Please review

MALodder (Thu, 19 Sep 2019 15:08:53 GMT):
Also, please add reviews to the other three pending PRs

Dan (Fri, 20 Sep 2019 07:16:57 GMT):
< friday watercooler > Long story on the guy that turned in Chelsea Manning https://www.npr.org/2019/09/19/760317486/the-mysterious-death-of-the-hacker-who-turned-in-chelsea-manning

MALodder (Fri, 20 Sep 2019 22:39:53 GMT):
In implementing a BLS Aggregated signature, short of batching the pairings in the verification step, I can’t think of any other optimizations to do. I mean mathematically, e(x, y),e(x,z) = e(x, y+z). So could some math optimization be done to speed up verification? Essentially, can we limit the number of pairing computations Aside of techniques described here - https://blog.dash.org/bls-is-it-really-that-slow-4ca8c1fcd38e

JonGeater (Sun, 22 Sep 2019 16:17:51 GMT):
I've just laid a comment in https://github.com/hyperledger/ursa/pull/61 - would appreciate people taking a look and seeing if I'm onto something or over-reacting.

MALodder (Mon, 23 Sep 2019 03:45:14 GMT):
I personally think it’s good to have the Cargo.lock included so when we do releases it’s easier to audit exactly what crate versions and dependencies were used. I want to reject this PR

MALodder (Mon, 23 Sep 2019 03:45:33 GMT):
Side note: interesting Rust crate we should use https://github.com/pornin/subtle

MALodder (Mon, 23 Sep 2019 03:50:02 GMT):
Also, I’m traveling this week and won’t be able to run the Sovrin Crypto call tomorrow. Lately Sovrin is interested in Threshold Signatures to be used to signing blind signatures that can be used for anonymous credentials. I’ve been doing lots of reading but haven’t really found anything yet worthy of implementing. If anyone knows of a good paper to look at let me know

MALodder (Mon, 23 Sep 2019 03:53:34 GMT):
Another thought was to apply Shamir Secret Sharing to PS signatures, but I’m unsure of the security proofs surrounding such a model. Would love to hear feedback on that idea. The protocol would have a holder request the credential from N issuers. The issuers each sign with their share and the holder aggregates the shares to complete the signature. As long as M of N respond, the holder will have a complete signature to use for Selective Disclosure and Zero Knowledge Signature proof of knowledge

MALodder (Mon, 23 Sep 2019 03:55:38 GMT):
I believe PS signatures will make this math easier since BBS+ contains a fraction in the exponent of the signature

MALodder (Mon, 23 Sep 2019 03:57:01 GMT):
and PS is aggregations and multiplies

KartikChauhan (Mon, 23 Sep 2019 09:17:45 GMT):
Has joined the channel.

KartikChauhan (Mon, 23 Sep 2019 09:23:18 GMT):
Hello All, I just read the Hyperledger Ursa hyperledger-wiki page and I think the project looks very promising. But I wanted to know if I could use it in a project that I'm working on. It's an enterprise project and I'm concerned about the stability of the Ursa. Another thing, is Ursa a good solution for users' secret generation? We currently generate secret using bcrypt and appending a salt value to the generated value.

MALodder (Mon, 23 Sep 2019 11:44:43 GMT):
Yes you can use Ursa. I wouldn’t be concerned about stability. We have two projects that are using it so we must keep it stable

MALodder (Mon, 23 Sep 2019 11:45:24 GMT):
Ursa doesn’t do password hashing yet. You’d be the first to request it

MALodder (Mon, 23 Sep 2019 17:57:07 GMT):
It’s open source, feel free to contribute

Dan (Tue, 24 Sep 2019 07:15:14 GMT):
@KartikChauhan ursa includes two libraries, libursa and libzmix. Libursa should be pretty stable and is mostly including other vetted libraries. Libzmix is less stable and includes more freshly written novel systems generally related to zero knowledge techniques.

MALodder (Tue, 24 Sep 2019 07:46:19 GMT):
I'm still waiting to see @dhuseby caeser cipher

lovesh (Tue, 24 Sep 2019 12:59:29 GMT):
I have done a implementation of Coconut in Rust which uses Shamir secret sharing but that means presence of a trusted third party. I am in talks with the author and expect a review shortly. I have to still see how easy will be to use a DKG protocol. Here is the implementation https://github.com/lovesh/coconut-rust

lovesh (Tue, 24 Sep 2019 13:00:13 GMT):
If this implementation is fine then we will move it to Ursa?

MALodder (Tue, 24 Sep 2019 13:58:01 GMT):
I remember @manud mentioning a vulnerability in coconut. I’d like to hear his opinion

dhuseby (Tue, 24 Sep 2019 20:58:57 GMT):
@MALodder soooon

Dan (Wed, 25 Sep 2019 07:16:45 GMT):
tppppo

Dan (Wed, 25 Sep 2019 07:17:20 GMT):
alpha test ^

amundson (Thu, 26 Sep 2019 17:17:35 GMT):
Has left the channel.

bbehlendorf (Fri, 27 Sep 2019 21:44:46 GMT):
Potentially of interest: https://twitter.com/CommerceGov/status/1177634002817159168

hartm (Sat, 28 Sep 2019 01:53:37 GMT):
@Dan the key is supposed to be hard-wired to `d' for dave, not `b'. We can't have entropy in our keys here!

KellyCooper (Sun, 29 Sep 2019 18:11:15 GMT):
Has joined the channel.

lovesh (Mon, 30 Sep 2019 04:36:08 GMT):
Hi Hart. I think you forgot to approve the PS signature RFC https://github.com/hyperledger/ursa-rfcs/pull/11

MALodder (Mon, 30 Sep 2019 14:14:22 GMT):
Sovrin Crypto call in 45 minutes

Dan (Mon, 30 Sep 2019 14:36:53 GMT):
I've got a regular conflict now so won't be there. I peaked at the agenda though and my answer to the last question is 65243.

lovesh (Mon, 30 Sep 2019 15:35:15 GMT):
^^^ Find link above

MALodder (Mon, 30 Sep 2019 15:45:45 GMT):
https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html

hartm (Mon, 30 Sep 2019 15:58:06 GMT):
https://rwc.iacr.org/2020/contributed.html

cam-parra (Mon, 30 Sep 2019 16:10:01 GMT):
@Dan and @rjones for some reason my hyperledger account is still connected to my evernym account so i can't join the maintainers mailing list. Or else I'd totally do as you emailed me about Dan

rjones (Mon, 30 Sep 2019 16:10:01 GMT):
Has joined the channel.

rjones (Mon, 30 Sep 2019 18:44:47 GMT):
your groups.io account should be distinct from your LFID

rjones (Mon, 30 Sep 2019 18:47:03 GMT):
anyway - I sent an invite to the email in your chat profile at gmail, which doesn't look like it has a l.h.o account

swcurran (Wed, 02 Oct 2019 11:57:36 GMT):
Has joined the channel.

s.weidenbach (Wed, 02 Oct 2019 11:57:37 GMT):
Has joined the channel.

hartm (Wed, 02 Oct 2019 14:58:12 GMT):
http://theory.stanford.edu/~dfreeman/cs259c-f11/index.html

mxs1491 (Wed, 02 Oct 2019 19:42:43 GMT):
Has joined the channel.

MALodder (Mon, 07 Oct 2019 13:45:51 GMT):
No Sovrin Crypto call today. I’m traveling to the maintainers summiy

MALodder (Mon, 07 Oct 2019 13:45:51 GMT):
No Sovrin Crypto call today. I’m traveling to the maintainers summit

kdenhartog (Tue, 08 Oct 2019 03:11:14 GMT):
Anyone done a review on the dependencies that ursa uses for signatures to check against [Minerva](https://minerva.crocs.fi.muni.cz/)?

kdenhartog (Tue, 08 Oct 2019 03:12:06 GMT):
It's a sidechannel attack that appears to previously been known in academia, but this was an audit on a few different implementations.

MALodder (Tue, 08 Oct 2019 04:28:09 GMT):
No we haven't, but none of the ursa dependencies are on the affected list

MALodder (Tue, 08 Oct 2019 04:30:48 GMT):
Its very similar to https://eprint.iacr.org/2019/023.pdf

MALodder (Tue, 08 Oct 2019 04:32:07 GMT):
In talking to Nadia, one of the authors, she told me that libsodium and libsecp256k1 were not vulnerable to her attack

MALodder (Tue, 08 Oct 2019 04:32:32 GMT):
ursa uses libsecp256k1

MALodder (Tue, 08 Oct 2019 04:33:27 GMT):
I don't know if curve25519-dalek is vulnerable to that or not but again its not on the list

MALodder (Tue, 08 Oct 2019 04:48:34 GMT):
perhaps @hartm could elaborate more on this too

hartm (Tue, 08 Oct 2019 04:49:09 GMT):
I haven't rigorously gone through the attack. And you already talked to Nadia about it--she's the expert.

MALodder (Tue, 08 Oct 2019 04:49:21 GMT):
However, it seems to me that this involves a timing attack and the more the library has constant time implementations, the more resistant it should be

MALodder (Tue, 08 Oct 2019 04:49:54 GMT):
and any language with a garbage collector isn't really constant time

hartm (Tue, 08 Oct 2019 04:50:33 GMT):
The paper you linked isn't a timing attack. It's attacking people who didn't generate keys properly.

MALodder (Tue, 08 Oct 2019 04:51:09 GMT):
Right, specifically the nonces used for ECDSA signing and EdDSA key generation

MALodder (Tue, 08 Oct 2019 04:51:46 GMT):
It does mention that the tool measure timing leakage of bit-length in scalar-multiplication

hartm (Tue, 08 Oct 2019 04:52:30 GMT):
Yeah. I have no idea what particular implementations are vulnerable. I saw that paper awhile back and was just mostly interested in how they applied lattice cryptanalysis tools to groups.

lovesh (Tue, 08 Oct 2019 19:45:46 GMT):
@dhuseby @MALodder @Dan and others, Are you opposed to always running the tests in release mode (`cargo test --release`)? Since tests take a long time in some of my PRs, TravisCI times out; this timeout can be fixed by running in release mode. The downside would be not getting a stacktrace that is as helpful as the debug mode's but one can debug the failing test on his local machine unless the failure is intermittent.

MALodder (Tue, 08 Oct 2019 19:46:12 GMT):
No I’m okay with that

dhuseby (Tue, 08 Oct 2019 20:36:40 GMT):
CI Test passes should be a canary in the coal mine that signals needed investigation. I’m good.

dhuseby (Tue, 08 Oct 2019 20:37:14 GMT):

notes from Fabric+Ursa session

achenette (Wed, 09 Oct 2019 17:50:47 GMT):
Has joined the channel.

achenette (Wed, 09 Oct 2019 17:50:47 GMT):
@MALodder - FYI, Hyperledger's Copyright and License policy is on their wiki: https://wiki.hyperledger.org/display/HYP/Copyright+and+License+Policy

kdenhartog (Wed, 09 Oct 2019 23:32:24 GMT):
That was the understanding I took away from the comments that the person who fixed elliptic suggested in stablelib

lovesh (Thu, 10 Oct 2019 13:32:08 GMT):
New paper by Marry Miller to use inner product argument to verify pairing product relations. Using this to verify several pairing product relations, the verifier computes constant number of pairings but 6(n + log(n)) exponentiations https://eprint.iacr.org/2019/1177.pdf They give an example of verifying BLS sigs under different messages but we can use this in delegatable credentials too when no of attributes is large or large chain If we expose enough details in our code for anoncreds, proofs over lots of credentials can be very cheap to verify

lovesh (Thu, 10 Oct 2019 13:32:44 GMT):
@hartm Thoughts ^^^ ?

hartm (Thu, 10 Oct 2019 13:59:06 GMT):
You're really fast Lovesh. That paper was posted in the last 24 hours, so I haven't had a chance to look at it. You actually spotted it before I did. I'll take a look sometime soon.

lovesh (Thu, 10 Oct 2019 14:02:16 GMT):
Unfortunately thats the only thing i am fast at. I haven't read much yet but will post here once i do.

hartm (Thu, 10 Oct 2019 14:02:32 GMT):
That's absolutely false.

hartm (Thu, 10 Oct 2019 14:03:07 GMT):
But yes, the paper definitely seems worth reading.

hartm (Thu, 10 Oct 2019 14:03:16 GMT):
We can discuss it at the Sovrin crypto meeting next week if you want.

kdenhartog (Fri, 11 Oct 2019 04:09:38 GMT):
Is there any plan in place to add encrypt functionality to libursa?

yerlibilgin (Fri, 11 Oct 2019 12:32:20 GMT):
Has joined the channel.

yerlibilgin (Fri, 11 Oct 2019 12:57:07 GMT):
Hello everyone. I work at TUBITAK BILGEM. We have a DigitalID project, I am interested in learning ursa (both sublibs) (as well as aries-go) and the relationship between the two. We plan to employ the Indy architecture in our project. @MALodder we met at the workshop in Istanbul

MALodder (Fri, 11 Oct 2019 13:11:23 GMT):
@kdenhartog yes I’m finishing the RFC. Which algorithms are you looking for

kdenhartog (Fri, 11 Oct 2019 20:37:03 GMT):
The usual Xsalsa XChacha and AES-GCM. I’d be willing to help write one.

MALodder (Sun, 13 Oct 2019 05:02:53 GMT):
We will most likely wrap the implementations done by the Rust Crypto team

rjones (Sun, 13 Oct 2019 06:01:42 GMT):
https://github.com/hyperledger/sawtooth-sdk-rust/pull/37 interesting

kdenhartog (Mon, 14 Oct 2019 02:26:54 GMT):
Sounds good. Also, I'm evaluating the didcomm crypto layer and what we should be doing for a key agreement protocol to account for MITM and be more explicit about the security properties we're accounting for. Right now the two I've been looking at are TLS 1.3 and SSB's key exchange protocol https://dominictarr.github.io/secret-handshake-paper/shs.pdf

kdenhartog (Mon, 14 Oct 2019 02:27:02 GMT):
Are there other ones that I should be checking out?

kdenhartog (Mon, 14 Oct 2019 02:31:39 GMT):
One of the problems I've found with TLS is that they build around a "middlebox" which is essentially a benevolent MITM. However, when looking into what it's used for further I found a BYU paper that found that in some cases it's used by advertisers and malware to be malicious. I'd like to exclude this capability, so my question is ,"are there any key exchange protocols which are formally verified to not be susceptible to MITM attacks or at least define what is acceptably excluded in the security properties?"

MALodder (Mon, 14 Oct 2019 03:46:17 GMT):
None that I know of @kdenhartog

kdenhartog (Mon, 14 Oct 2019 06:05:22 GMT):
Dang, I've got a sneaking suspicion that there aren't any out there because they would be a solution to the trust on first use problem.

kdenhartog (Mon, 14 Oct 2019 06:48:46 GMT):
Interesting question: I was just looking at the Montgomery curve wikipedia page and I noticed that they can be made equivalent to both twisted Edwards curves and Weierstrass curves. Does that mean that it's possible to map an Ed25519 key to an X25519 key and then map it to a Weierstrass curve (I presume this would be a non-common curve because the base points are different)?

MALodder (Mon, 14 Oct 2019 14:01:33 GMT):
Montgomery curves are used for the Diffie Hellman computation typically because its more secure and efficient (correct me if I'm wrong @hartm) using the Montgomery ladder for that. Twisted Edwards and Weierstrass curves are used for computing signatures. So you could in theory map Ed25519 to the Weierstrass equivalent, why would you? Curve25519 is much faster on which to operate vs Weierstrass

hartm (Mon, 14 Oct 2019 14:04:12 GMT):
@kdenhartog Key exchange protocols are always vulnerable to MITM attacks. That's why the internet runs on certificates. It's impossible without some kind of certificate or certificate-like thing to know who you are actually talking to, so MITM attacks are essentially always possible without this. I'm not sure this answered your question, but I think what you're asking for is impossible.

hartm (Mon, 14 Oct 2019 14:06:08 GMT):
@MALodder I'm going to defer the questions on efficiency to use. Which curves are more secure is not a settled matter, though--people have lots of different opinions.

MALodder (Mon, 14 Oct 2019 15:01:58 GMT):
Sovrin Crypto call https://zoom.us/j/567114224

cam-parra (Mon, 14 Oct 2019 16:39:22 GMT):
@MALodder as @rjones pointed out it looks like sawtooth is switching to rustcrypto instead of ursa. Could you pop in and offer to switch them to ursa?

cam-parra (Mon, 14 Oct 2019 16:39:34 GMT):
I can do that as well

MALodder (Mon, 14 Oct 2019 16:39:41 GMT):
We already are using Rust Crypto vs rust-crypto

MALodder (Mon, 14 Oct 2019 16:39:57 GMT):
No work required

cam-parra (Mon, 14 Oct 2019 16:40:36 GMT):
oh okay works for me

MALodder (Mon, 14 Oct 2019 21:09:34 GMT):

Clipboard - October 14, 2019 3:09 PM

MALodder (Mon, 14 Oct 2019 21:10:24 GMT):
This is interesting. In `https://github.com/mikelodder7/ursa/tree/bls` I have implemented what I call Normal BLS signatures and Small BLS signatures. The difference being the signature group and public key groups are swapped. This means smaller signatures vs larger public keys (Small BLS) or larger signatures vs smaller public keys (Normal BLS). When I benchmark the two, Small BLS wins in every case except for key generation. I'd like to see what others get. To generate the same report 1- git clone https://github.com/hyperledger/ursa 2- cd ursa 3- cargo bench -- bls

MALodder (Mon, 14 Oct 2019 21:11:38 GMT):
make sure to use rust 1.38

MALodder (Mon, 14 Oct 2019 21:12:04 GMT):
I'm not sure why Small wins that often, I expected it to be slower for verification but faster to sign

MALodder (Mon, 14 Oct 2019 21:12:19 GMT):
rk means rogue key

hartm (Wed, 16 Oct 2019 14:11:11 GMT):
https://eprint.iacr.org/2019/202

lovesh (Wed, 16 Oct 2019 14:39:24 GMT):
https://eprint.iacr.org/2019/1058.pdf

lovesh (Wed, 16 Oct 2019 14:39:24 GMT):
Jan Camenisch's paper describing threshold signatures. Page 19 and 22 are relevant. https://eprint.iacr.org/2019/1058.pdf

MALodder (Wed, 16 Oct 2019 20:11:48 GMT):
https://npmccallum.gitlab.io/post/do-not-use-ring-or-rustls/

kdenhartog (Thu, 17 Oct 2019 01:18:56 GMT):
I noticed the `build-environment.md` doc recommends installing libsodium 1.0.16, but the dependencies on the root `readme.md` says it depends on `1.0.18`. Should the build environment doc be updated?

kdenhartog (Thu, 17 Oct 2019 01:19:09 GMT):
I'll submit a PR if so

MALodder (Thu, 17 Oct 2019 03:32:08 GMT):
yes

MALodder (Thu, 17 Oct 2019 03:32:23 GMT):
we use libsodium to test, its not used in builds

silviu (Thu, 17 Oct 2019 21:29:21 GMT):
Has joined the channel.

Dan (Mon, 21 Oct 2019 08:13:49 GMT):
Howdy, I was at the HL bootcamp last week and I'm traveling for a different event this week. Should be back in the groove next week though. Sorry if anything is stalled on me.

hartm (Mon, 21 Oct 2019 15:04:56 GMT):
https://people.cs.nctu.edu.tw/~rjchen/ECC2012S/Elliptic%20Curves%20Number%20Theory%20And%20Cryptography%202n.pdf

cam-parra (Mon, 21 Oct 2019 15:23:52 GMT):
ooooo where can I get a hard copy of that?

hartm (Mon, 21 Oct 2019 17:01:05 GMT):
@cam-parra Probably amazom?

hartm (Mon, 21 Oct 2019 17:01:36 GMT):
https://www.amazon.com/Elliptic-Curves-Cryptography-Mathematics-Applications/dp/1420071467

hartm (Mon, 21 Oct 2019 17:01:52 GMT):
It's a very nice book in that it doesn't presuppose a lot of difficult math notation that many other math textbooks do.

MALodder (Tue, 22 Oct 2019 15:01:26 GMT):
https://github.com/hyperledger/ursa/pull/74

MALodder (Tue, 22 Oct 2019 15:01:35 GMT):
Can I get another reviewer?

dnnn (Tue, 22 Oct 2019 17:58:25 GMT):
Has joined the channel.

dnnn (Tue, 22 Oct 2019 17:58:26 GMT):
Hello to everyone, I am trying out some of the `ursa`'s functionality in an iOS app, and I have a question regarding a c-callable methods. This is my first experience of working with c-callable lib, so please bear with me :) First I generate `master_secret` with `ursa_cl_prover_new_master_secret` and pass the pointer to `ursa_cl_master_secret_to_json` having a pointer to JSON `ptr_to_json`as an outcome. So now, given this pointer I want to get the JSON itself. In `swift` I manage to do so with the help of `UnsafeRawBufferPointer(start: , count: )` The problem is that the length of the JSON string referenced by `ptr_to_json` can vary each time (from 81 to 87 bytes as far as understood, when run secret generation multiple time) My question is what is the right approach to get JSON the values referenced by pointers that I receive as the result of `ursa` method execution? I see that there are other methods that result in pointers to JSON strings, and the length of generated JSONs will vary (I guess) as the structures of those JSONs are more complex that `{"ms": "SOME_BIG_INT"}` Any tips or suggestions will be highly appreciated.

dnnn (Tue, 22 Oct 2019 17:59:20 GMT):
@MALodder thanks again for hints on how to build the library for iOS

MALodder (Tue, 22 Oct 2019 18:10:18 GMT):
this interface needs to be reworked to use ffi-support interface vs what it is now. I might be able to help in this area but am quite busy

dnnn (Tue, 22 Oct 2019 18:19:47 GMT):
thanks for a rapid reply!

MALodder (Tue, 22 Oct 2019 18:20:59 GMT):
the existing interface was written quickly without too much of a concern for usability for rapid prototyping

prieblinger (Wed, 23 Oct 2019 12:23:33 GMT):
Has joined the channel.

dnnn (Wed, 23 Oct 2019 13:11:43 GMT):
Good day to everyone, a short question about `master_secret`. found the following comment ``` // Master secret is now called link secret. pub static LINK_SECRET: &'static str = "master_secret"; ``` In future releases all "master_secret" related entities will be eventually renamed to "link_secret", right?

MALodder (Wed, 23 Oct 2019 14:32:51 GMT):
that is correct

MALodder (Wed, 23 Oct 2019 14:35:55 GMT):
What's happening is we keep trying to invent a better word for it. The latest thinking is "holder seal". The problem is trying to find a word that correctly conveys the right mental model. Master secret was definitely not correct because it implied that this was the grand secret if stolen means identity theft which is not the case

rallam (Wed, 23 Oct 2019 15:56:21 GMT):
Has joined the channel.

dnnn (Wed, 23 Oct 2019 17:47:55 GMT):
thanks for the info. as far as I understand this secret is participating in the process of creation of every credential for the holder of identity (thus "linking" them, and I see why "link secret" is one of the options for a name), so if it is stolen, doesn't it make credentials already issued with this secret compromised? I mean the thief would be able to generate proofs as the holder of identity (which is kinda identity theft)? I don't have a very deep understanding of the subject yet, so pardon me if I ask something silly. Just want to better understand your point about identity theft and stealing this secret

MALodder (Wed, 23 Oct 2019 17:49:32 GMT):
Just stealing the secret doesn't all impersonation. The attacker will have to steal ALL attributes in credentials and the credential signature. Then they can impersonate for a single credential. So to do complete impersonation, the attacker needs ALL attributes and ALL signatures

dnnn (Wed, 23 Oct 2019 18:21:30 GMT):
big thanks for clarifications

josephboyle (Fri, 25 Oct 2019 20:40:36 GMT):
Has joined the channel.

giancarloGiuffra (Mon, 28 Oct 2019 15:02:26 GMT):
Has joined the channel.

giancarloGiuffra (Mon, 28 Oct 2019 15:02:27 GMT):
Hello everyone. Can someone point to me the academic paper describing the security of the cryptographic accumulator implemented in ursa? The explanation here (https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/concepts/revocation/cred-revocation.html) is too high level and I haven't been able to find any other description of cryptographic accumulators in the hyperledger projects. I looked into Idemix (which was the starting point of the evernym implementation) and I believe the specification mentions the following paper "An Accumulator Based on Bilinear Maps andEfficient Revocation for Anonymous Credentials" by Camenisch, Kohlweiss and Soriente. Thanks for any useful info.

giancarloGiuffra (Tue, 29 Oct 2019 10:00:11 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=3aoow39sxohvoY9ci) anyone?

lovesh (Tue, 29 Oct 2019 15:13:41 GMT):
I am almost certain that accumulator in Indy is described in section 3.2 in this paper. This tex file contains more implementation details of revocation https://github.com/hyperledger/ursa-docs/blob/master/specs/anoncreds1/anoncreds.tex. If you can't create the PDF, you can access a slightly older version in a deprecated repo https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/docs/AnonCred.pdf

lovesh (Tue, 29 Oct 2019 15:13:41 GMT):
I am almost certain that accumulator in Indy is described in section 3.2 in this paper. Some nomenclature differece, the paper calls it "state" whereas Indy calls it "tails". This tex file contains more implementation details of revocation https://github.com/hyperledger/ursa-docs/blob/master/specs/anoncreds1/anoncreds.tex. If you can't create the PDF, you can access a slightly older version in a deprecated repo https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/docs/AnonCred.pdf

lovesh (Tue, 29 Oct 2019 15:25:26 GMT):
In case you are doing a comparison, I would like to ask a favor. I came across this paper from Jan Camenisch last week that claims to improve upon our revocation scheme. If you don't mind can you please check this one out as well https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/main-51.pdf

giancarloGiuffra (Tue, 29 Oct 2019 15:35:59 GMT):
@lovesh thank you, I compiled the tex and reading the article.

giancarloGiuffra (Tue, 29 Oct 2019 15:35:59 GMT):
@lovesh thank you very much, I compiled the tex and reading the article.

giancarloGiuffra (Tue, 29 Oct 2019 16:05:11 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=eygBk9FdnRxRnmhS2) @lovesh the Camenisch article is from 2010

lovesh (Tue, 29 Oct 2019 16:26:15 GMT):
You mean this one "An Accumulator Based ....", its from 2008, https://eprint.iacr.org/2008/539

lovesh (Tue, 29 Oct 2019 19:50:32 GMT):
My bad, the link i shared is from 2010. I looked a bit more and that setting is not useful for us. Also it increases the cost of Issuer linearly for non revoked users. So overall, not useful

MALodder (Mon, 04 Nov 2019 14:33:39 GMT):
Reminder that the Sovrin Crypto Meeting is at 9am MDT. For those in areas that don’t observe daylight savings it will be an hour later than you are used to

MALodder (Tue, 05 Nov 2019 05:55:45 GMT):
https://aws.amazon.com/blogs/security/post-quantum-tls-now-supported-in-aws-kms/

prieblinger (Tue, 05 Nov 2019 13:15:08 GMT):
Has left the channel.

AnnaJ (Tue, 05 Nov 2019 15:59:13 GMT):
Has joined the channel.

MALodder (Sat, 09 Nov 2019 06:31:08 GMT):
@rjones This job https://travis-ci.com/hyperledger/ursa/jobs/254273651 succeeded but times out because travis is trying to update its cache after the test runs. This has happened three times now. Can you mark it as succeeded or extend the time limit some how?

rjones (Sat, 09 Nov 2019 10:05:46 GMT):
@MALodder I don't see a way I can turn a knob and fix that. I think, once you have one more approved review, I could force-merge it even with the failed but;d

MALodder (Sat, 09 Nov 2019 13:58:55 GMT):
Bummer. I can merge it too so no worries

rjones (Sun, 10 Nov 2019 01:30:05 GMT):
We're paying for circle-ci if you want to try moving there. I think we can get longer timeouts.

rjones (Sun, 10 Nov 2019 01:30:28 GMT):
I just don't see a knob I can turn to increase the timeout.

MALodder (Mon, 11 Nov 2019 15:08:54 GMT):
makes sense

sanjaysb (Wed, 13 Nov 2019 04:53:50 GMT):
Has joined the channel.

mlucc (Thu, 14 Nov 2019 14:49:39 GMT):
Has joined the channel.

mlucc (Thu, 14 Nov 2019 14:49:40 GMT):
Hello, can anyone share with me a project that uses Hyperledger Ursa as a use case?

mlucc (Thu, 14 Nov 2019 14:49:46 GMT):
specifically that uses ZKPs

mlucc (Thu, 14 Nov 2019 14:49:51 GMT):
please

MALodder (Thu, 14 Nov 2019 15:06:46 GMT):
Hyperledger Indy does and Aries will soon too

MALodder (Thu, 14 Nov 2019 15:07:29 GMT):
vonx.io uses Indy, Evernyms connect.me, and Streetcred are the first that come to mind

mlucc (Thu, 14 Nov 2019 16:58:18 GMT):
ok thank you

swcurran (Thu, 14 Nov 2019 17:28:33 GMT):
@MALodder - a question about anoncreds 2.0. I've heard that there will be a feature (or could be - that's part of the question) that allows proving a claim from a credential and proving a self-asserted claim such that the verifier can be certain that the link secret used for the claim from the credential was also used for the self-asserted claim. Is that true? Scenario: An voter has a piece of gov't id. They use that to prove they are older than the voting age, but no other information from the credential. They also sign a piece of data from the verifier (a unique ID for the election - same data handed to all prospective voters). The verifier knows: 1. They are old enough to vote, as attested by their gov't ID. 2. Their proof is associated with the unique ID for the election in a self-asserted claim. 3. The verifier knows that the same link secret was used for both claims, and hence can make sure the vote is only counted once. For the latter, if the same user submits another vote, only one is counted - likely the last one. Questions: 1. Is that feature (self-attested claims, signed/processed somehow the shows the same link secret was used for both claims) in anoncreds 2.0? 2. Are there any other crypto holes in the scenario I described?

MALodder (Thu, 14 Nov 2019 17:41:28 GMT):
So the user wouldn't create a self attested credential, but would just add self attested claims to the proof

MALodder (Thu, 14 Nov 2019 17:42:57 GMT):
one of the values could be a vote ID, notice its not voterID, and if they see the same vote ID twice then they don't count it, the vote ID could be a one time use credential as well that is added to a spent set when its used

MALodder (Thu, 14 Nov 2019 17:43:59 GMT):
self-asserted claims are capable in anoncreds 2.0

swcurran (Thu, 14 Nov 2019 17:51:25 GMT):
And they have the attribute that the verifier knows that they used the same link secret as the credential? That's the detail that I'm looking for.

swcurran (Thu, 14 Nov 2019 17:51:25 GMT):
And they have the attribute that the verifier knows that they used the same link secret for the self-asserted claim as the claim from the credential? That's the detail that I'm looking for.

MALodder (Thu, 14 Nov 2019 17:56:23 GMT):
the self asserted claims don't need a link secret because they are tied to the proof

swcurran (Thu, 14 Nov 2019 18:34:12 GMT):
OK - so there's no positive link between the link secret and the claim other than they are in the same proof.

swcurran (Thu, 14 Nov 2019 18:34:12 GMT):
OK - so there's no positive link between the link secret and the self-asserted claim other than they are in the same proof.

swcurran (Thu, 14 Nov 2019 18:34:27 GMT):
Thanks

MALodder (Thu, 14 Nov 2019 19:44:56 GMT):
correct

MALodder (Fri, 15 Nov 2019 13:26:15 GMT):
@swcurran I’m doing a presentation on this stuff next Wednesday. Talk to Anna at Sovrin for more info

vardan10 (Thu, 21 Nov 2019 11:23:50 GMT):
Has joined the channel.

fabienpe (Thu, 21 Nov 2019 14:09:15 GMT):
Has joined the channel.

fabienpe (Thu, 21 Nov 2019 14:32:10 GMT):
While doing some experiments I came across the following issue and cannot figure out whether it's a bug in the library or an error on my side and was wondering if anyone might have tips to help further investigate. When I'm trying to verify a proof built with two different credentials from the same institution and with the same schema and same definition (so the only difference between the two credentials is the time and serial number), then verification fails. I recognise that this situation is rather unusual, but in principle I don't understand why this should fail.

lovesh (Thu, 21 Nov 2019 15:25:55 GMT):
Exception message? Link to code?

fabienpe (Thu, 21 Nov 2019 15:58:50 GMT):
No exception message. I think the issue is that prover_create_proof takes as last input revocation states and there is one state per credential definition, while the rev state is different for each credential (from the same definition).

fabienpe (Thu, 21 Nov 2019 15:58:50 GMT):
No exception message (just proof verification fails). I think the issue is that prover_create_proof takes as last input revocation states and there is one state per credential definition, while the rev state is different for each credential (from the same definition).

lovesh (Fri, 22 Nov 2019 05:35:25 GMT):
Which lib/which file has the function `prover_create_proof`? Can't find in the current Ursa codebase

fabienpe (Fri, 22 Nov 2019 12:41:03 GMT):
Check `https://github.com/fabienpe/indy-sdk/blob/master/samples/python/src/getting_started_2.py` At line 312 you can choose issuing 1 or more Transcripts from Faber. If one is issued, then all goes well. If two are issued, then proof with Acme fails. The trace says `TRACE:indy.libindy.native.ursa.cl.verifier: xxxx\.cargo\registry\src\github.com-1ecc6299db9ec823\ursa-0.2.0\src\cl\verifier.rs:317 | ProofVerifier::verify: <<< valid: false`

rjones (Fri, 22 Nov 2019 12:41:28 GMT):
Has left the channel.

lovesh (Fri, 22 Nov 2019 15:13:58 GMT):
If you try without revocation, i.e., line 463 `'non_revoked': {'to': time_stamp}`, it works?

rjones (Sat, 23 Nov 2019 19:06:06 GMT):
Has joined the channel.

rjones (Sat, 23 Nov 2019 19:06:06 GMT):
@MALodder I created https://dev.azure.com/Hyperledger/ursa-dev/_build which points to https://github.com/hyperledger-cicd/ursa/tree/azure_pipelines . I also invited you as an owner to Hyperledger-cicd GitHub org so you may iterate on debugging https://github.com/hyperledger/ursa/pull/82 as quickly as you like

fabienpe (Mon, 25 Nov 2019 08:57:00 GMT):
If I do without revocation (so line 463 and other related revocation instructions), then no issue.

lovesh (Mon, 25 Nov 2019 13:03:34 GMT):
On line 372 (https://github.com/fabienpe/indy-sdk/blob/master/samples/python/src/getting_started_2.py#L372), you have `faber['job_certificate_cred_rev_id']` and not `faber['job_certificate_cred_rev_id_%s' % i]`. Is that ok since revocation idx will be same for both creds? And can you check if revocation index is same for both creds?

lovesh (Mon, 25 Nov 2019 13:03:34 GMT):
On line 372 (https://github.com/fabienpe/indy-sdk/blob/master/samples/python/src/getting_started_2.py#L372), you have `faber['job_certificate_cred_rev_id']` and not `faber['job_certificate_cred_rev_id_%s' % i]`. Is that ok since revocation idx will be overwritten? And can you check if revocation index is same for both creds?

lovesh (Mon, 25 Nov 2019 13:03:34 GMT):
On line 372 (https://github.com/fabienpe/indy-sdk/blob/master/samples/python/src/getting_started_2.py#L372), you have `faber['job_certificate_cred_rev_id']` and not `faber['job_certificate_cred_rev_id_%s' % i]`. Is that ok since revocation idx will be overwritten? And can you check if revocation index is different for both creds?

lovesh (Mon, 25 Nov 2019 13:04:32 GMT):
On a different note, it would be clearer if you created variables (in loop's scope) for `_%s % i`

lovesh (Mon, 25 Nov 2019 13:04:32 GMT):
On a different note, it would be clearer if you created variables (in loop's scope) for all `_%s % i`

fabienpe (Mon, 25 Nov 2019 15:31:02 GMT):
Well that was quick hack from the getting_started code that you are familiar with, because I'm unable to provide the actual code in which I came across the issue. The cred_rev_id is in fact not used in that example since I don't revoke any credential. This index does get updated: 1 then 2.

fabienpe (Mon, 25 Nov 2019 15:32:10 GMT):
I've changed the %s' % s to in-loop local variables and pushed that new code.

lovesh (Tue, 26 Nov 2019 10:18:06 GMT):
Thanks. Will try to reproduce in Ursa without going through sdk

brentzundel (Wed, 27 Nov 2019 15:00:30 GMT):
Is the ursa call happening today?

MALodder (Thu, 28 Nov 2019 04:09:44 GMT):
No it was canceled

hartm (Thu, 28 Nov 2019 17:54:19 GMT):
I sent out an email. Did you not get it?

andrew.whitehead (Fri, 29 Nov 2019 15:08:40 GMT):
Has joined the channel.

Jack1477 (Fri, 29 Nov 2019 18:09:30 GMT):
Has joined the channel.

Jack1477 (Fri, 29 Nov 2019 18:18:57 GMT):
Does any Node.js wrapper for Ursa exist in any of Hyperledger repositories or does it not exist at all?

Jack1477 (Fri, 29 Nov 2019 18:19:16 GMT):
If it does exist - can I have a link please?

Jack1477 (Fri, 29 Nov 2019 18:20:33 GMT):
If it does not exist - is there a particular reason for that? Or just nobody had time to do it yet?

MALodder (Sun, 01 Dec 2019 17:30:18 GMT):
None exists yet. No one has had time to do it, and the demand hasn't been there yet

lovesh (Sun, 01 Dec 2019 20:28:40 GMT):
I looked more and it does not make sense to try it with Ursa APIs as its very clear in Ursa which cred sig, which rev reg state is used. The problem might be when the wallet or ledger is being queried

ItsOmerShafiq (Sun, 01 Dec 2019 22:28:31 GMT):
Has joined the channel.

MALodder (Mon, 02 Dec 2019 16:07:15 GMT):

Cryptographically Enforced Orthogonal Access Control.pdf

brentzundel (Mon, 02 Dec 2019 16:33:21 GMT):
I didn't get one, not sure why.

lovesh (Mon, 02 Dec 2019 16:49:39 GMT):
https://github.com/Fraunhofer-AISEC/rabe

lovesh (Mon, 02 Dec 2019 16:49:39 GMT):
Various ABE schemes in Rust with MIT license https://github.com/Fraunhofer-AISEC/rabe

kumar89 (Tue, 03 Dec 2019 14:07:59 GMT):
Has joined the channel.

MALodder (Wed, 04 Dec 2019 15:58:15 GMT):
Ursa quarterly report: https://wiki.hyperledger.org/display/TSC/2019+Q4+Hyperledger+Ursa

MALodder (Wed, 04 Dec 2019 15:58:21 GMT):
feel free to add to it as needed

hartm (Wed, 04 Dec 2019 16:20:00 GMT):
@MALodder Thanks a lot! That looks fantastic.

MALodder (Wed, 04 Dec 2019 16:45:42 GMT):
Interesting note: https://www.unboundtech.com/unbound-receives-fips-140-2-certification/

MALodder (Wed, 04 Dec 2019 16:47:30 GMT):
would hyperledger sponser doing FIPS compliance for Ursa

MALodder (Wed, 04 Dec 2019 16:47:31 GMT):
https://www.corsec.com/fips-140-2/#theplayers

hartm (Wed, 04 Dec 2019 21:34:02 GMT):
I just attended a talk on this: https://crypto.stanford.edu/timings/

hartm (Wed, 04 Dec 2019 21:34:12 GMT):
Pretty interesting stuff, and worth a look by most people here.

ajayjadhav (Wed, 04 Dec 2019 22:06:02 GMT):
Has joined the channel.

Jack1477 (Fri, 06 Dec 2019 18:51:57 GMT):
Are there any performance metrics on Ursa CL API? I have tested few methods with a great success until I get to ursa_cl_issuer_new_credential_def(), which takes forever to complete. I am testing in a range of 1-100 attributes and getting response in average 10s on my machine. Is it supposed to be that slow or am I doing something wrong? I assume all Ursa API is synchronous so the code is computing that long, not sleeping somewhere?

MALodder (Fri, 06 Dec 2019 19:38:26 GMT):
I have a few metrics that I've done against the newer signature

MALodder (Fri, 06 Dec 2019 19:38:26 GMT):
I have a few metrics that I've done against the newer signatures

MALodder (Fri, 06 Dec 2019 19:38:27 GMT):
s

MALodder (Fri, 06 Dec 2019 19:39:09 GMT):
the reason it takes a long time is because it has to search for safe primes

MALodder (Fri, 06 Dec 2019 19:39:39 GMT):
anoncreds 2 will be very fast for keygen

Jack1477 (Fri, 06 Dec 2019 19:51:10 GMT):
@MALodder is the algorithm not-symmetric in terms of performance then? I mean, long generation of the credentials pub/prv keys and coreectness proff, but fast signing/proving with them later? Or should I expect other calls to be long as well? What is the ETA for anoncreds 2.0?

MALodder (Fri, 06 Dec 2019 19:51:50 GMT):
the algorithm is like RSA

MALodder (Fri, 06 Dec 2019 19:52:02 GMT):
the crypto for anoncreds 2.0 is already in ursa

MALodder (Fri, 06 Dec 2019 19:54:55 GMT):
`cd libzmix`

MALodder (Fri, 06 Dec 2019 19:54:58 GMT):
`cargo bench`

Jack1477 (Fri, 06 Dec 2019 19:56:46 GMT):
Ok, I see now. However it seems Libzmix does not provide C-API of any sort?

MALodder (Fri, 06 Dec 2019 20:01:49 GMT):
We'd like to, no one has asked for it yet

MALodder (Fri, 06 Dec 2019 20:01:55 GMT):
we also accept PRs

MALodder (Fri, 06 Dec 2019 20:02:35 GMT):
What features are you hoping to use specifically

Jack1477 (Fri, 06 Dec 2019 20:12:11 GMT):
I would like to have C-API that exposes all underneath public Rust methods , similar way to how FFI for CL in Libursa is done.

Jack1477 (Fri, 06 Dec 2019 20:18:35 GMT):
I haven't looked into Libzmix yet and I am not sure how it differs from CL so cannot point out exactly what I need.

Jack1477 (Fri, 06 Dec 2019 20:22:36 GMT):
Thanks for info though. I hope to commit something soon.

MALodder (Sat, 07 Dec 2019 16:44:13 GMT):
Libzmix is just like CL but much faster and smaller

MALodder (Sat, 07 Dec 2019 16:45:10 GMT):
The signatures from zmix are

MALodder (Mon, 09 Dec 2019 01:47:10 GMT):
https://www.space.com/quantum-supremacy-debate.html

huxd (Mon, 09 Dec 2019 04:09:47 GMT):
Is ursa used by any other hyperledger project now?

Jack1477 (Mon, 09 Dec 2019 11:56:18 GMT):
it is used in Hyperledger Indy at least. Haven't looked into other projects so cannot say.

Jack1477 (Mon, 09 Dec 2019 11:56:18 GMT):
it is used in Hyperledger Indy at least. Haven't looked into other projects so cannot provide more info than that.

fabienpe (Mon, 09 Dec 2019 13:06:30 GMT):
Should I report a bug on jira.hyperledger.org or GitHub?

MALodder (Mon, 09 Dec 2019 14:39:27 GMT):
Iroha is using it too

MALodder (Mon, 09 Dec 2019 14:39:57 GMT):
I believe burrow is trying to adopt it also but haven’t heard anything since. Transact is using it too

MALodder (Mon, 09 Dec 2019 14:58:10 GMT):
No Sovrin Crypto call today. I'm taking some PTO

MALodder (Mon, 09 Dec 2019 14:58:23 GMT):
@hartm @lovesh @brentzundel ^^^

hartm (Mon, 09 Dec 2019 15:04:52 GMT):
Have a nice day off!

lovesh (Mon, 09 Dec 2019 15:46:38 GMT):
Yes

huxd (Tue, 10 Dec 2019 05:46:24 GMT):
thanks very much for your sharing! I will check them as examples.

lmtriet (Tue, 10 Dec 2019 13:21:55 GMT):
Has joined the channel.

hartm (Wed, 11 Dec 2019 01:46:19 GMT):
@here Just a reminder of tomorrow's meeting. Please feel free to add things to the agenda that you'd like to discuss. Thanks!

hartm (Wed, 11 Dec 2019 15:00:49 GMT):
Our calendar entry seems to have gotten lost.

MALodder (Wed, 11 Dec 2019 15:03:26 GMT):
odd

MALodder (Wed, 11 Dec 2019 15:03:33 GMT):
where are you @hartm

hartm (Wed, 11 Dec 2019 15:03:46 GMT):
Are you in the regular community meeting?

hartm (Wed, 11 Dec 2019 15:03:54 GMT):
Which meeting are you in?

MALodder (Wed, 11 Dec 2019 15:04:06 GMT):
https://zoom.us/my/hyperledger.community

MALodder (Wed, 11 Dec 2019 15:07:13 GMT):
what's the new zoom room?

lovesh (Wed, 11 Dec 2019 15:07:47 GMT):
I tried https://zoom.us/my/hyperledger.backup but does not work

MALodder (Wed, 11 Dec 2019 15:08:02 GMT):
me too

hartm (Wed, 11 Dec 2019 15:08:31 GMT):
hyperledger.community.backup

lovesh (Wed, 11 Dec 2019 15:08:32 GMT):
https://zoom.us/my/hyperledger.community.backup

brentzundel (Wed, 11 Dec 2019 15:10:23 GMT):
That one works for me, thanks Lovesh

hartm (Wed, 11 Dec 2019 15:10:43 GMT):
Still not showing in the calendar, argh.

hartm (Wed, 11 Dec 2019 15:32:11 GMT):
https://plundervolt.com/

rjones (Wed, 11 Dec 2019 15:42:12 GMT):
an interesting read

cam-parra (Wed, 11 Dec 2019 17:30:49 GMT):
Now I am sad i missed the call

MALodder (Wed, 11 Dec 2019 20:45:05 GMT):
https://crates.io/crates/ursa 0.3.0 is released!!

Silona (Wed, 11 Dec 2019 21:45:14 GMT):
Hello everyone - Do you know of a developer event that we would like to get some Hyperledger representation at? Please submit it here. The marketing committee will review them all as we go thru our budget for 2020 Thank you! - Silona

Silona (Wed, 11 Dec 2019 22:02:59 GMT):
https://wiki.hyperledger.org/display/Marketing/Developer+Events

cam-parra (Thu, 12 Dec 2019 16:51:53 GMT):
@hartm I think this is what the besu team didn't point us to yesterday

cam-parra (Thu, 12 Dec 2019 16:51:54 GMT):
https://github.com/hyperledger/besu/tree/master/crypto/src/main/java/org/hyperledger/besu/crypto

hartm (Thu, 12 Dec 2019 18:00:43 GMT):
I wasn't even looking this deep. They don't seem to be using anything beyond the basics when it comes to crypto.

cam-parra (Thu, 12 Dec 2019 19:16:27 GMT):
maybe we could help a bit here

Jack1477 (Fri, 13 Dec 2019 13:48:37 GMT):
There is no release in GitHub for 0.3.0

MALodder (Fri, 13 Dec 2019 14:02:35 GMT):
Yeah I need to tag it

MALodder (Fri, 13 Dec 2019 14:06:49 GMT):
https://crates.io/crates/ursa

MALodder (Fri, 13 Dec 2019 14:54:11 GMT):
tagged

ltseeley (Fri, 13 Dec 2019 18:56:40 GMT):
Has joined the channel.

ltseeley (Fri, 13 Dec 2019 18:56:40 GMT):
Hey everyone, splinter (https://github.com/Cargill/splinter/) has an optional feature for ursa-compatible signing that currently uses ursa 0.1, but it's currently broken so we're trying to fix it. We only need secp256k1 signing, so we tried updating the dependency to `ursa = { version = "0.3", optional = true, default-features = false, features = ["native_secp256k1"] }`, but it fails with this error: ```error[E0463]: can't find crate for `blake2` --> /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/lib.rs:29:1 | 29 | pub extern crate blake2; | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate```

ltseeley (Fri, 13 Dec 2019 18:57:19 GMT):
It seems the feature's dependencies aren't configured properly

ltseeley (Fri, 13 Dec 2019 19:03:13 GMT):
Or perhaps it's just not clear how to specify the features

amundson (Fri, 13 Dec 2019 19:24:32 GMT):
Has joined the channel.

ltseeley (Fri, 13 Dec 2019 19:49:17 GMT):
Otherwise, if anyone is familiar with this error and knows how to resolve it, help would be appreciated: ```error[E0277]: the trait bound `rand_chacha::ChaChaRng: rand_core::CryptoRng` is not satisfied --> /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:34:39 | 34 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `rand_chacha::ChaChaRng` | ::: /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:12 | 130 | R: CryptoRng + RngCore, | --------- required by this bound in `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand_chacha::ChaChaRng: rand_core::RngCore` is not satisfied --> /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:34:39 | 34 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `rand_chacha::ChaChaRng` | ::: /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:24 | 130 | R: CryptoRng + RngCore, | ------- required by this bound in `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand::rngs::OsRng: rand_core::CryptoRng` is not satisfied --> /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:42:35 | 42 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `rand::rngs::OsRng` | ::: /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:12 | 130 | R: CryptoRng + RngCore, | --------- required by this bound in `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand::rngs::OsRng: rand_core::RngCore` is not satisfied --> /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:42:35 | 42 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `rand::rngs::OsRng` | ::: /Users/seeley/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:24 | 130 | R: CryptoRng + RngCore, | ------- required by this bound in `ed25519_dalek::Keypair::generate` error: aborting due to 4 previous errors```

MALodder (Fri, 13 Dec 2019 21:40:48 GMT):
I'll take a look at it

MALodder (Fri, 13 Dec 2019 22:02:41 GMT):
Right now we haven't configured to pull a single signature method like that. I will see what I can do with a PR to address this

MALodder (Sat, 14 Dec 2019 13:47:14 GMT):
However, the rust compiler should remove any code you don’t actually use. It should be fine just using the default features

Jack1477 (Sun, 15 Dec 2019 20:35:33 GMT):
I am writing the wrapper for Ursa CL and I am stuck on testing the C-API for CL. I have successfully implemented "demo" test scenario with a wrapper (found in src/cl/mod.res line 1635) and almost done with "demo_revocation" (found in src/cl/mod.rs line 1754), but got stuck on processing signature in the second one. Without revocation processing works fine (ursa_cl_prover_process_credential_signature()) , however when I try it with revocation I get following error: "Message: Invalid structure Caused by: Invalid Signature correctness proof c != c" . I am trying to debug step by step why this error occurs but without any success yet. Is anyone here able to give me some kind of tip what the issue might be? What I mean by that - is there some kind of "most frequent reason" to why this error pops up? Or is it rather not common problem? I suspect something might be wrong on my side with generation of new tails, but already spent few hours on it, serializing and deserializing contents of each tail and tails generator and I am unable to spot the problem. Another potentential reason I suspect might be happening is that one of the objects not marked as mutable is mutating somewhere and it happens desync between my wrapper and C-API. If anyone had this problem with C-API before and was able to solve it or can share some word of advice where to look to solve the issue I would love to hear it.

Jack1477 (Sun, 15 Dec 2019 20:56:23 GMT):
One of the things I am confused about are the states of revocation registry and revocation tail generator that need to be passed between different API calls. For example - when calling ursa_cl_issuer_sign_credential_with_revoc() it is required to pass revocation registry , revocation tails generator , FFITake and FFIPut functions pointers. During this function call both revocation registry and revocation tails generator are mutated. Then, after calling that I need to create witness with ursa_cl_witness_new() that requires revocation registry delta and revocation tails generator. In what state does the revocation tails generator need to be with this call? The original one before being mutated by ursa_cl_issuer_sign_credential_with_revoc() or mid-state or final state ? The same problem applies to next call ursa_cl_prover_process_credential_signature(). This function requires revocation registry to be passed. Once again - revocation registry in which state? initial, mid-state or final?

Jack1477 (Sun, 15 Dec 2019 21:13:17 GMT):
In my previous posts I used the terms of initial , mid and final state. Its the confusion that I have due to existance of two implementations of TailAccessor in the code. FFITailsAccessor for C-API and SimpleTailsAccessor being used inside the code. FFITailsAccessor allows userland code to define how the tails are generated/accessed. SimpleTailsAccessor on creation creates ALL tails possible and stores them in memory. In demo_revocation test scenario which I am trying to implement, the tail being requested is identified with revIdx = 5. The size of tails accessors is calculated to 11. Here's what I do not understand. The mutated result for revocation registry depends on which tail has been accessed and the state of tails generator. Since the FFITailsAccessor allows custom definiton of take function that would also mean that it allows arbitrary state changes at this point. For example, my current implementation generates tails up to highest revIndx that has been asked (5 in this example). If instead I used SimpleTailsAccessor it would generate 11 from the start. By logic the state of revocation registry / revocations tails generator should be same after generating X tails. But if one generates X and other generates Y it would mean the states are no longer equal. Henceforth I see thre potentential states here. 1. Initial state which is state before any tail has been generated. 2. Mid-state after X tails have been generated but there is room for more (allowed by FFITailsAccessor) 3. Final-state after ALL tails have been generated (enfored by SimpleTailsAccessor) I am not sure if the difference between 2 and 3 is relevant to the outcome of C-API calls?

Jack1477 (Sun, 15 Dec 2019 21:24:46 GMT):
Ant tips to what might be the issue behind ""Message: Invalid structure Caused by: Invalid Signature correctness proof c != c"" are welcome

vardan10 (Mon, 16 Dec 2019 07:22:21 GMT):
Hi, I was looking at the ursa tests and the issuer seems to be adding the holder's (Prover's) master secret value to credential. Shouldn't the master secret be kept safe by the holder(prover)? Issuer assigns master secret to credential hers: https://github.com/hyperledger/ursa/blob/master/libursa/tests/cl.rs#L79 Master secret variable is defined by prover here: https://github.com/hyperledger/ursa/blob/master/libursa/tests/cl.rs#L33

vardan10 (Mon, 16 Dec 2019 10:39:59 GMT):
Hi, I was looking at the ursa tests and the issuer seems to be adding the holder's (Prover's) master secret value to credential. Shouldn't the master secret be kept safe by the holder(prover)? Issuer assigns master secret to credential hers: https://github.com/hyperledger/ursa/blob/master/libursa/tests/cl.rs#L79 Master secret variable is defined by prover here: https://github.com/hyperledger/ursa/blob/master/libursa/tests/cl.rs#L33

ltseeley (Mon, 16 Dec 2019 14:21:20 GMT):
@MALodder the long error snippet I posted is what we are seeing when we use just the default features.

MALodder (Mon, 16 Dec 2019 14:34:25 GMT):
That can’t be because you have —no-default-features

pschwarz (Mon, 16 Dec 2019 14:44:04 GMT):
True, but it looks like `"native_secp256k1"` depends on that `blake2` dependency (or it isn't properly guarded by a `cfg` annotation).

pschwarz (Mon, 16 Dec 2019 14:44:04 GMT):
True, but it looks like `"native_secp256k1"` either depends on that `blake2` dependency or it isn't properly guarded by a `cfg` annotation.

amundson (Mon, 16 Dec 2019 15:24:38 GMT):
@MALodder being more specific should help avoid unnecessary dependencies (like libsodium)

MALodder (Mon, 16 Dec 2019 15:25:02 GMT):
it should and PRs are welcome to help with this

MALodder (Mon, 16 Dec 2019 15:43:58 GMT):
not really, the cfg's need to be updated so that each feature is more independent. secp256k1 just depends on having a valid hash algorithm that outputs 256 bits

MALodder (Mon, 16 Dec 2019 15:44:11 GMT):
If I had more time I would've done it by now

pschwarz (Mon, 16 Dec 2019 15:44:50 GMT):
Fair - we're in the same boat over on Sawtooth ;)

MALodder (Mon, 16 Dec 2019 15:45:56 GMT):
Keep in mind that the tests are not clear as to who is doing what, just that the steps work properly. The Prover generates the master secret and blinds it prior to sending it to the issuer

hartm (Mon, 16 Dec 2019 16:18:44 GMT):
I'm betting there will be a blockchain event in these: https://crypto.iacr.org/2020/callforaffiliated.html

hartm (Mon, 16 Dec 2019 16:18:50 GMT):
Might be a good place to submit papers.

kdenhartog (Tue, 17 Dec 2019 00:41:15 GMT):
Hey all. I've been tracking the Xchacha20 draft rfc on the IETF CFRG mailing list and there's been little discussion which can move this forward. There is an implementation already in libsodium and I think it would be a good addition for ursa to support. However, there's been some hesitation about the nonce generation on the mailing list in the past and it may be useful to have some cryptoanalysts take a look at it to get the work moving forward. @hartm do you know of anyone who could take a look at it and provide feedback on the mailing list? @MALodder or @lovesh could you ask Dmitry K. to take a look at it as well and provide some feedback? I'd like to be able to use this with the Aries work, but haven't had much luck getting things moving on the mailing list, so any help or feedback would be appreciated.

hartm (Tue, 17 Dec 2019 00:50:11 GMT):
Dmitry is the hash function expert and probably the person to ask about this.

andrew.whitehead (Tue, 17 Dec 2019 06:35:52 GMT):
That long compilation error goes away when ed25519_dalek is locked to 1.0.0-pre.1 instead of pre.3 (the latest)

andrew.whitehead (Tue, 17 Dec 2019 06:35:52 GMT):
That long compilation error goes away when ed25519_dalek is locked to 1.0.0-pre.2 instead of pre.3 (the latest)

MALodder (Tue, 17 Dec 2019 21:26:08 GMT):
@pschwarz https://github.com/hyperledger/ursa/pull/88

MALodder (Tue, 17 Dec 2019 21:26:39 GMT):
with this PR, you should be able to just use `ecdsa_secp256k1_native`

MALodder (Tue, 17 Dec 2019 21:26:49 GMT):
as the only enabled feature

pschwarz (Tue, 17 Dec 2019 21:48:44 GMT):
Cool

pschwarz (Tue, 17 Dec 2019 21:48:44 GMT):
Cool, thank!

pschwarz (Tue, 17 Dec 2019 21:48:44 GMT):
Cool, thanks!

IWontDiscloseMyIdentity (Wed, 18 Dec 2019 11:26:26 GMT):
Has joined the channel.

redongjun (Wed, 18 Dec 2019 13:28:41 GMT):
Has joined the channel.

harrywright (Wed, 18 Dec 2019 18:04:22 GMT):
Has joined the channel.

knagware9 (Tue, 24 Dec 2019 05:06:55 GMT):
Has joined the channel.

pranavkirtani88 (Wed, 01 Jan 2020 08:31:18 GMT):
Has joined the channel.

sanjaysb (Wed, 01 Jan 2020 08:31:37 GMT):
Are the values of the attributes in the credentials always supposed to be numbers? (https://github.com/hyperledger/ursa/blob/0d6c176f2f72417cd0111ded4d63e434bf0f4d03/libursa/src/cl/mod.rs#L90). How can I handle string values in the credential?

MALodder (Fri, 03 Jan 2020 02:42:27 GMT):
Yes they must be for the crypto to work. The most common method is to use sha256 to convert the string

sanjaysb (Fri, 03 Jan 2020 04:46:34 GMT):
but sha256 is one way right?

MALodder (Sat, 04 Jan 2020 19:47:23 GMT):
yes

MALodder (Sat, 04 Jan 2020 19:47:38 GMT):
you still need to store the original value

sanjaysb (Mon, 06 Jan 2020 04:19:27 GMT):
ok. So in the credential given by an issuer you only have the hash values for string attributes. The actual attributes are shared to holder unsigned. The holder when submitting a claim to the verifier, will share the actual values as well which the verifier can verify using the signed hash value in the credential. Am I thinking right?

kdenhartog (Mon, 06 Jan 2020 04:45:51 GMT):
Hey I've been playing around with the libzmix stuff to trying and compile it with wasm-pack but it's been failing. I also tried compiling it with cargo and the `==features=wasm` but was unable to find the `.wasm` files. @MALodder @lovesh or @dhuseby do either of you know what to do? If I can figure it out I'll add some docs in to help.

kdenhartog (Mon, 06 Jan 2020 04:45:51 GMT):
Hey I've been playing around with the libursa stuff to trying and compile it with wasm-pack but it's been failing. I also tried compiling it with cargo and the `==features=wasm` but was unable to find the `.wasm` files. @MALodder @lovesh or @dhuseby do either of you know what to do? If I can figure it out I'll add some docs in to help.

kdenhartog (Mon, 06 Jan 2020 04:45:51 GMT):
Hey I've been playing around with the libursa stuff to trying and compile it with wasm-pack but it's been failing. I also tried compiling it with cargo and the `--features=wasm` but was unable to find the `.wasm` files. @MALodder @lovesh or @dhuseby do either of you know what to do? If I can figure it out I'll add some docs in to help.

AxelNennker (Mon, 06 Jan 2020 13:12:21 GMT):
Is there a plan to prevent this error when building libindy? ``` axelnennker@Axels-MBP libindy (master) $ RUST_TEST_THREADS=1 cargo test Updating crates.io index Downloaded zeroize_derive v1.0.0 Downloaded secp256k1 v0.12.0 Downloaded ursa v0.3.0 Downloaded filetime v0.2.8 Downloaded vcpkg v0.2.8 Downloaded hex v0.4.0 Downloaded aead v0.1.1 error: multiple packages link to native library `sodium`, but a native library can be linked only once package `libsodium-ffi v0.1.17` ... which is depended on by `ursa v0.3.0` ... which is depended on by `libindy v1.12.0 (/Users/axelnennker/development/indy-sdk/libindy)` links to native library `sodium` package `libsodium-sys v0.0.16` ... which is depended on by `sodiumoxide v0.0.16` ... which is depended on by `indy-utils v0.1.0 (/Users/axelnennker/development/indy-sdk/libindy/indy-utils)` ... which is depended on by `indy-wallet v0.1.0 (/Users/axelnennker/development/indy-sdk/libindy/indy-wallet)` ... which is depended on by `libindy v1.12.0 (/Users/axelnennker/development/indy-sdk/libindy)` also links to native library `sodium` axelnennker@Axels-MBP libindy (master) $ ```

AxelNennker (Mon, 06 Jan 2020 13:13:21 GMT):
Are you planning to move sodiumoxide to ursa?

AxelNennker (Mon, 06 Jan 2020 13:14:37 GMT):
I experimentally told libindy to use ursa-0.3 and got the above result

MALodder (Mon, 06 Jan 2020 15:35:00 GMT):
yes. The actual value is what the verifier cares about anyway. The verifier needs to know how to map the values to the signed ones so they can check that it has not changed

MALodder (Mon, 06 Jan 2020 15:35:27 GMT):
to get the wasm file you need to use wasm-pack

MALodder (Mon, 06 Jan 2020 15:35:53 GMT):
https://rustwasm.github.io/wasm-pack/installer/

swcurran (Mon, 06 Jan 2020 15:59:25 GMT):
You'll see references in schema discussions to the encoding of the value. That's a key issue. In the first cut of Indy, the encoding was left to the issuer to do as they wished. With the upcoming Rich Schema work, the encoding will be published on the ledger and so can be checked.

sanjaysb (Tue, 07 Jan 2020 11:34:20 GMT):
Can you give me a link where I can read on this?

sanjaysb (Tue, 07 Jan 2020 11:36:30 GMT):
I am basically interested if there is a standard that I can follow when designing the issue flow and verification flow.

swcurran (Tue, 07 Jan 2020 16:49:28 GMT):
@kenebert @brentzundel - can y'all provide a link to the encoding mechanism?

hartm (Wed, 08 Jan 2020 02:31:38 GMT):
@here We are cancelling tomorrow's meeting due to the real world crypto conference, as many of our usual participants are attending. Hope everyone had a great holiday season!

rbuysse (Wed, 08 Jan 2020 14:00:30 GMT):
Has left the channel.

MALodder (Wed, 08 Jan 2020 14:34:31 GMT):
No but even if we did it wouldn’t fix that particular problem. Indy should change their code to use ursa for their keys and encryption instead of using sodium oxide for it

AxelNennker (Thu, 09 Jan 2020 14:07:11 GMT):
@MALodder I gave your suggestion a shot - that is, I updated all references to ursa to 0.3 and remove sodiumoxide everywhere in libindy/*

AxelNennker (Thu, 09 Jan 2020 14:08:08 GMT):
Interestingly this setup fails to compile ursa ``` axelnennker@Axels-MBP libindy (ursa_0.3) $ cargo build Compiling ursa v0.3.0 error[E0277]: the trait bound `rand_chacha::ChaChaRng: rand_core::CryptoRng` is not satisfied --> /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:34:39 | 34 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `rand_chacha::ChaChaRng` | ::: /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:12 | 130 | R: CryptoRng + RngCore, | --------- required by this bound in `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand_chacha::ChaChaRng: rand_core::RngCore` is not satisfied --> /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:34:39 | 34 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `rand_chacha::ChaChaRng` | ::: /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:24 | 130 | R: CryptoRng + RngCore, | ------- required by this bound in `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand::rngs::OsRng: rand_core::CryptoRng` is not satisfied --> /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:42:35 | 42 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `rand::rngs::OsRng` | ::: /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:12 | 130 | R: CryptoRng + RngCore, | --------- required by this bound in `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand::rngs::OsRng: rand_core::RngCore` is not satisfied --> /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.0/src/signatures/ed25519/ed25519.rs:42:35 | 42 | Keypair::generate(&mut rng) | ^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `rand::rngs::OsRng` | ::: /Users/axelnennker/.cargo/registry/src/github.com-1ecc6299db9ec823/ed25519-dalek-1.0.0-pre.3/src/ed25519.rs:130:24 | 130 | R: CryptoRng + RngCore, | ------- required by this bound in `ed25519_dalek::Keypair::generate` error: aborting due to 4 previous errors ```

AxelNennker (Thu, 09 Jan 2020 14:09:15 GMT):
That should not happen, I think. Building the local clone of ursa from githup works but using the version from crates.io does not compile

AxelNennker (Thu, 09 Jan 2020 14:16:09 GMT):
The code causing this is here: https://github.com/AxelNennker/indy-sdk/tree/ursa_0.3

andrew.whitehead (Thu, 09 Jan 2020 16:35:01 GMT):
@AxelNennker I worked around this issue before by locking ed25519_dalek to version 1.0.0-pre.2

andrew.whitehead (Thu, 09 Jan 2020 16:35:56 GMT):
`ed25519-dalek = "=1.0.0-pre.2"` in the dependencies section

andrew.whitehead (Thu, 09 Jan 2020 16:35:56 GMT):
`ed25519-dalek = "=1.0.0-pre.2"` in the dependencies section of Cargo.toml

kdenhartog (Fri, 10 Jan 2020 03:00:43 GMT):
pretty interesting article covering the different classes of ZKP tech or as the author refers to them as "cryptographic proofs of computational integrity"

AxelNennker (Fri, 10 Jan 2020 16:17:29 GMT):
This already in ursa, right? https://github.com/hyperledger/ursa/blob/master/libursa/Cargo.toml#L101 Or which Cargo.toml are you referring to?

andrew.whitehead (Fri, 10 Jan 2020 16:18:32 GMT):
Indy's

AxelNennker (Fri, 10 Jan 2020 16:19:07 GMT):
Thanks, will try that.

AxelNennker (Fri, 10 Jan 2020 16:21:45 GMT):
Ok, gets me further. Thanks again.

AxelNennker (Fri, 10 Jan 2020 16:23:28 GMT):
did you succeed to use ursa-0.3 in libindy? I didn't (yet). Maybe I changed too much. I remove sodiumoxide from libindy everywhere because I thought ursa might provide what is needed.

AxelNennker (Fri, 10 Jan 2020 16:23:28 GMT):
did you succeed to use ursa-0.3 in libindy? I didn't (yet). Maybe I changed too much. I removed sodiumoxide from libindy everywhere because I thought ursa might provide what is needed.

MALodder (Fri, 10 Jan 2020 16:23:53 GMT):
It should

andrew.whitehead (Fri, 10 Jan 2020 16:24:03 GMT):
I haven't tried on indy as a whole, I'm working on separating out the ledger client

MALodder (Fri, 10 Jan 2020 16:24:40 GMT):
I will try to migrate Indy to ursa 0.3 soon if you can’t get it to work

AxelNennker (Fri, 10 Jan 2020 16:25:48 GMT):
Regarding ed25519-dalek: should somebody create a PR to them to remove the restriction to a specific version, or what needs to be done to fix this for all?

MALodder (Fri, 10 Jan 2020 16:26:37 GMT):
The reason it’s tied to pre2 at the moment is the specific version of rand being used

MALodder (Fri, 10 Jan 2020 16:26:59 GMT):
I want to move to pre3 which includes my fixes to that and should clean that up

MALodder (Fri, 10 Jan 2020 16:27:14 GMT):
Perhaps in 0.3.1

jethrojones (Fri, 10 Jan 2020 18:27:13 GMT):
Has joined the channel.

AxelNennker (Sun, 12 Jan 2020 11:57:15 GMT):
@MALodder I guess it is better you do the PR to ursa 0.3 in libindy. I guess that most of libindy/crypto/utils should be replaced by ursa call. I don't know ursa good enough what it provides to do this.

AxelNennker (Sun, 12 Jan 2020 11:57:15 GMT):
@MALodder I guess it is better you do the PR to ursa 0.3 in libindy. I guess that most of libindy/crypto/utils should be replaced by ursa methods. I don't know ursa good enough what it provides to do this.

AxelNennker (Sun, 12 Jan 2020 11:57:15 GMT):
@MALodder I guess it is better you do the PR to ursa 0.3 in libindy. I guess that most of libindy/crypto/utils should be replaced by ursa methods. I don't know ursa good enough and what it provides to do this.

Silona (Tue, 14 Jan 2020 16:51:13 GMT):
Help Us Help you! Attend the Developer Relationship Meeting with Myself and our Marketing Dept. tomorrow at 9:00am Pacific Time. For the agenda and Dial in info https://wiki.hyperledger.org/display/Marketing/2020-01-15+Meeting+notes

Silona (Tue, 14 Jan 2020 17:02:00 GMT):
Calling all Projects! We will have a special Kiosk setup at Hyperledger Global Forum for Projects. We are asking that all projects sign up to do 10 minute presentations. https://wiki.hyperledger.org/display/HGF/Projects+Kiosk We will close this page on Feb 28 for printing reasons.

Silona (Tue, 14 Jan 2020 17:06:42 GMT):
Calling all Projects, SIG, and WG!!! We will have a Video recording Studio setup at HGF (Hyperledger Global Forum). We are asking that all projects and groups help us create a 5 minute video about your group so that we can promote it afterward. Sign up Here! https://wiki.hyperledger.org/display/HGF/Video+Recording+Schedule

cam-parra (Tue, 14 Jan 2020 17:56:48 GMT):
@rjones Are you able to set secrets on github for specific repos? Also does hyperledger have a pypi account?

rjones (Tue, 14 Jan 2020 18:54:44 GMT):
@cam-parra https://pypi.org/user/hyperledger/

rjones (Tue, 14 Jan 2020 18:55:21 GMT):
Could you explain what you need to accomplish with the GitHub secrets?

vdods (Tue, 14 Jan 2020 19:10:40 GMT):
Has joined the channel.

vdods (Tue, 14 Jan 2020 19:16:45 GMT):
Hi all, I work for LedgerDomain, a Hyperledger member, and I'm looking to talk to a crypto expert or two to vet a scheme for storing hash records for private documents. If anyone has any recommendations for who to talk to, I would much appreciate it -- please email me at victor.dods@ledgerdomain.com -- if a formal consulting arrangement for such vetting is warranted, then that's certainly an option. Thanks all! :)

cam-parra (Tue, 14 Jan 2020 19:37:04 GMT):
I am wanting to package and publish ursa-python to pypi under the hyperledger account. This would be done through github actions and they require username and password to be set in the repos secrets.

rjones (Tue, 14 Jan 2020 19:43:03 GMT):
@andrew.whitehead how are you publishing `aries-cloudagent-python`? I don't see anything in the circle-ci file

rjones (Tue, 14 Jan 2020 19:44:27 GMT):
I see this: https://github.com/hyperledger/aries-cloudagent-python/blob/master/PUBLISHING.md but are you using your own credentials?

rjones (Tue, 14 Jan 2020 19:45:54 GMT):
@cam-parra I see that I can generate an API token for a specific project in the PyPi UI. Would this work?

rjones (Tue, 14 Jan 2020 19:46:18 GMT):
https://pypi.org/help/#apitoken

cam-parra (Tue, 14 Jan 2020 19:48:02 GMT):
Yes that is what I would need ```After getting API Token from PyPI, you can set secrets on GitHub by clicking “Settings” -> “Secrets” on the project page. Using my example workflow, you should set __token__ for PYPI_USERS , and a token starting with pypi- got on PyPI configuration for PYPI_PASSWORD .```

rjones (Tue, 14 Jan 2020 19:48:37 GMT):
OK.

andrew.whitehead (Tue, 14 Jan 2020 19:55:19 GMT):
@rjones I'm using my own credentials

rjones (Tue, 14 Jan 2020 19:55:57 GMT):
thank you

rjones (Wed, 15 Jan 2020 17:13:52 GMT):
@andrew.whitehead would you want to set something up with GitHub actions or AZP to publish to PyPI when you do a release, using an API key for the repo? I know @BrettLogan has set up rigging like that for other projects

andrew.whitehead (Wed, 15 Jan 2020 17:41:21 GMT):
@rjones Sure, would be good to get set up

rjones (Wed, 15 Jan 2020 17:54:37 GMT):
OK, let's chat in #cicd

KyleHuang (Thu, 16 Jan 2020 02:55:23 GMT):
Has joined the channel.

KyleHuang (Thu, 16 Jan 2020 02:55:24 GMT):
Hi, guys, I have some questions about the Hyperledger Indy focusing on the credential revocation. Thank you for your help. The credential revocation of Indy refers to https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0109-anoncreds-protocol/README.html The CKS accumulator refers to this paper https://eprint.iacr.org/2008/539.pdf Questions 1. In the Non-revocation Credential Cryptographic Setup phase, a type-III pairing is chosen. Is there any suggestion while choosing all three groups G1, G2 and GT? For example, how many bits is the order r suggested to be? By the way, is there some special purpose to use a type-III pairing? The referred CKS accumulator uses a type-I pairing which G1 = G2. The CKS accumulator could be referred here. 2. The architecture includes an accumulator system that the issuer side stores the states (V and {g'_i} for all i in [1, 2L]) and the blockchain stores the indices V and accumulator acc. By the definition of accumulator on wiki: A cryptographic accumulator is a one way membership function. It answers a query as to whether a potential candidate is a member of a set without revealing the individual members of the set. We have the following questions: It seems not a one-way function if everyone can observe V and acc together from the blockchain. The mapping of indices i and parameters g'_i could be gradually found after several accumulator updates. Following the above question, after the mapping relationship is totally observed, I believe the membership of the current accumulator is entirely revealed. If V is stored on the ledger, the size of V keeps growing alone with more holders get involved in. In my opinion, the size of a cryptographic accumulator should be independent from the number of members. In short, we estimate that the indices V may not be suitable to be published and stored on the ledger. Please feel free to indicate if we misunderstood something. Thank you very much.

SigmaS 1 (Thu, 16 Jan 2020 08:06:27 GMT):
Has joined the channel.

aravindavk (Thu, 16 Jan 2020 09:32:18 GMT):
Has joined the channel.

lovesh (Thu, 16 Jan 2020 12:47:43 GMT):
Hi. 1. Type 3 pairings are more efficient to compute. 2. You can consider g_i as static state (it never changes so it should not be called state) while indices of V form dynamic state. On the "one-way ness", the indices of V are needed for updating an old witness and to ensure that the same entries are not added twice in the accumulator or an entry that is attempted to being removed is indeed present (the technique to remove is not mentioned in the paper but you can remove by multiplying with the inverse of the entry). Publishing the indices is not a problem in our case since credential holder never reveals his index but proves that an entry for his index (which is present in his credential) is present in the accumulator as well. But if you did not need the ability for old witnesses to be updated, you can avoid publishing indices of V and only the issuer should keep them. The credential holders can then request the issuer to very efficiently compute the witness as it knows the trapdoor (the paper does not describe this but the implementation i link does so). This however does require the issuer to stay online. This is my implementation that does removal and updates using trapdoor, https://github.com/lovesh/cks_accumulator. But note that the choice of groups is different than indy, i keep witness and accumulator in G1 for efficiency

rjones (Fri, 17 Jan 2020 17:00:04 GMT):
@cam-parra @MALodder May I publish https://github.com/hyperledger/ursa-python/pull/3 once, manually?

MALodder (Fri, 17 Jan 2020 17:00:24 GMT):
Find by me

MALodder (Fri, 17 Jan 2020 17:00:24 GMT):
Fine by me

rjones (Fri, 17 Jan 2020 17:00:26 GMT):
This will let me generate the API key for PyPI and add it to the secrets in GitHub

rjones (Fri, 17 Jan 2020 17:00:31 GMT):
OK, thanks.

cam-parra (Fri, 17 Jan 2020 17:00:39 GMT):
sure thing

cam-parra (Fri, 17 Jan 2020 17:01:10 GMT):
sorry I haven't been able to help more on this front. I've been firefighting non community tasks

rjones (Fri, 17 Jan 2020 17:01:44 GMT):
No worries - I'm just trying to knock stuff out. I'm trying to be a little less BOFHish, or I would have just Done The Thing

cam-parra (Fri, 17 Jan 2020 17:05:23 GMT):
thank you!

rjones (Fri, 17 Jan 2020 20:39:06 GMT):
https://pypi.org/project/python-ursa/ I added the token to GitHub, so I think this works going forward.

rjones (Fri, 17 Jan 2020 20:41:13 GMT):
You could do a 0.1.1 release and see, maybe?

kdenhartog (Fri, 17 Jan 2020 22:50:39 GMT):
Can I get a review of this others? It looks promising in the use of DIDcomm’s encryption envelope. https://rot256.io/post/box/

kdenhartog (Fri, 17 Jan 2020 22:50:39 GMT):
Can I get a review of this? It looks promising from my perspective in the use of DIDcomm’s encryption envelope. https://rot256.io/post/box/

AxelNennker (Sat, 18 Jan 2020 14:25:10 GMT):
Interesting build failure while building libindy when sodiumoxide is updated from 0.0.16 to 0.2.5 ``` ============================================================================ Testsuite summary for libsodium 1.0.18 ============================================================================ # TOTAL: 77 # PASS: 75 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 ============================================================================ See test/default/test-suite.log Please report to https://github.com/jedisct1/libsodium/issues ============================================================================ ``` Two tests fail: ``` FAIL: pwhash_argon2i FAIL: pwhash_argon2id ``` The code is here, if you want to reproduce this: https://github.com/AxelNennker/indy-sdk/tree/sodiumoxide_0.2.5 Seems to be a sodiumoxide issue. If one of you would reproduce this then I would report the issue as requested.

AxelNennker (Sat, 18 Jan 2020 17:32:05 GMT):
Seems to be an macos issue. Building libsodium on macos fails with the same test failures.

AxelNennker (Sat, 18 Jan 2020 17:32:05 GMT):
Seems to be an macos issue. Building libsodium on macos fails with the same test failures. I tried to build libsodium (stable) from source and that failed too. Uninstalling `brew remove libtool` allowd me to build from source and run to test successfully. `cargo build` of libsodium-sys still fails though... libsodium-sys is using its own libtool. I guess that leads to the tests to fail.

AxelNennker (Sat, 18 Jan 2020 17:32:05 GMT):
Seems to be an macos issue. I tried to build libsodium (stable) from source and that failed too. Uninstalling `brew remove libtool` allowed me to build from source and run the tests successfully. `cargo build` of libsodium-sys still fails though... libsodium-sys is using its own libtool. I guess that leads to the tests to fail.

KyleHuang (Mon, 20 Jan 2020 06:16:09 GMT):
Thank you very much about these.

MALodder (Mon, 20 Jan 2020 14:08:56 GMT):
Rust implementations are taken first, if none exist like Argon2 then we have no choice but to go out to C

hartm (Mon, 20 Jan 2020 15:29:39 GMT):
I'll try to take a look sometime today.

s.weidenbach (Tue, 21 Jan 2020 16:42:02 GMT):
Could you please send us the Bug ID/Link? We would like to monitor this because it currently prevents us from using revocation in production.

CHempel (Tue, 21 Jan 2020 16:49:57 GMT):
Has joined the channel.

s.weidenbach (Tue, 21 Jan 2020 17:13:11 GMT):
I created a new bug in JIRA and hope that I didn't overlook an existing one: https://jira.hyperledger.org/browse/URSA-9

s.weidenbach (Tue, 21 Jan 2020 17:13:49 GMT):
I created a new bug in JIRA and hope that I didn't overlook an existing one: https://jira.hyperledger.org/browse/URSA-9

s.weidenbach (Tue, 21 Jan 2020 17:17:01 GMT):
I created a new bug in JIRA and hope that I didnt overlook an existing one: https://jira.hyperledger.org/browse/URSA-9

hartm (Wed, 22 Jan 2020 02:46:16 GMT):
@here Just a reminder for tomorrow's meeting. Hope to see many of you all there! Thanks!

brentzundel (Wed, 22 Jan 2020 15:05:22 GMT):
Link for the meeting?

lovesh (Wed, 22 Jan 2020 15:05:30 GMT):
https://zoom.us/my/hyperledger.community.backup

agunde (Wed, 22 Jan 2020 15:18:58 GMT):
Has left the channel.

hartm (Wed, 22 Jan 2020 15:27:10 GMT):
https://obj.umiacs.umd.edu/papers_for_stories/crlite_oakland17.pdf

MALodder (Wed, 22 Jan 2020 15:28:13 GMT):
https://arxiv.org/abs/1905.13737

MALodder (Wed, 22 Jan 2020 15:37:02 GMT):
https://www.usenix.org/system/files/sec19-thomas.pdf

hartm (Wed, 22 Jan 2020 15:44:19 GMT):
https://eprint.iacr.org/2018/727.pdf

MALodder (Wed, 22 Jan 2020 15:44:34 GMT):
https://github.com/privacypass/challenge-bypass-extension

hartm (Wed, 22 Jan 2020 15:47:59 GMT):
https://content.sciendo.com/view/journals/popets/2018/3/article-p164.xml

hartm (Wed, 22 Jan 2020 15:57:02 GMT):
https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Pseudo%20Randomness/Verifiable_Random_Functions.pdf

MALodder (Thu, 23 Jan 2020 18:37:24 GMT):
Ursa 0.3.1 is now released

esplinr (Thu, 23 Jan 2020 19:39:21 GMT):
Who will be attending the Hyperledger Global Forum?

esplinr (Thu, 23 Jan 2020 19:39:58 GMT):
I grabbed us a 10 minute project presentation slot to present about Ursa. If you want to present, let me know and I'll substitute your name for mine.

esplinr (Thu, 23 Jan 2020 19:40:42 GMT):
https://wiki.hyperledger.org/display/HGF/Projects+Kiosk

MALodder (Fri, 24 Jan 2020 00:27:53 GMT):
I was planning to present on building secure protocols using Ursa

hartm (Fri, 24 Jan 2020 00:47:27 GMT):
@esplinr Are you going? If so, you're more than welcome to talk if you like.

esplinr (Fri, 24 Jan 2020 00:48:25 GMT):
I'm going, and can help out if needed. But you or @MALodder would be better qualified. Once you know your schedules at the conference, let me know if you are available.

esplinr (Fri, 24 Jan 2020 00:48:56 GMT):
@brentzundel would also do great.

brentzundel (Fri, 24 Jan 2020 02:13:10 GMT):
Mike and I are already presenting on Ursa

hartm (Fri, 24 Jan 2020 03:32:12 GMT):
@esplinr You're plenty qualified. I doubt people at the booth are going to be asking theoretical questions, which is basically what I'm good for answering anyway.

AxelNennker (Fri, 24 Jan 2020 10:01:15 GMT):
Maybe help the author of https://crates.io/crates/rust-argon2 to achieve version 1.0. I don't agree with the author that the limitations he describes are really limitations. For example he writes that the implementation is not optimized. I think that password hashing does not really need to be optimized, often it is desirable to be slow. The other thing he writes about clearing memory after use: I guess this was written before zeroize 1.x

AxelNennker (Fri, 24 Jan 2020 10:31:13 GMT):
Looked at the zeroizing and noticed that rust-argon2 just does not attempt to clean the memory that is left to the caller, which is OK, I think.

AxelNennker (Fri, 24 Jan 2020 10:32:07 GMT):
Wondering why argon2 is not part of ring...

MALodder (Fri, 24 Jan 2020 18:35:00 GMT):
Ring just supports algorithms mostly from boringssl. The author has done some interesting trade offs that I’m not sure if I agree with

Dan (Mon, 27 Jan 2020 17:13:52 GMT):
Hi Everyone, We are hoping to hear from everyone as we assess the health of our open source community. Please take 2 minutes to respond here: https://www.surveymonkey.com/r/DCIWGsurvey

Silona (Mon, 27 Jan 2020 22:28:10 GMT):
The Linux Foundation’s CommunityBridge engineers are working on a tool to measure the health of critical open source projects and one of the key areas identified is QA Testing. They request that our communities provide honest and detailed information on testing tools and methodologies you use in your projects for us to come up with a detailed analysis, which they will share with all respondents and projects. https://www.surveymonkey.com/r/9H5G2GV. It’s only 5 questions long.

cam-parra (Mon, 27 Jan 2020 22:45:29 GMT):
algebra

cam-parra (Mon, 27 Jan 2020 22:51:21 GMT):
I am attending if you need more of an implementation presentation

AxelNennker (Tue, 28 Jan 2020 12:04:14 GMT):
Would you mind setting the dependency to zeroize to "1" instead of to "1.0"? The current version of zeroize is 1.1.0 The author of aes-gcm does use "1" as well.

AxelNennker (Tue, 28 Jan 2020 12:08:32 GMT):
https://github.com/hyperledger/ursa/blob/master/libursa/Cargo.toml#L139

AxelNennker (Tue, 28 Jan 2020 12:10:49 GMT):
When will ursa 0.3.1 be released? Could zeroize-1.1.0 be part of that?

AxelNennker (Tue, 28 Jan 2020 12:13:56 GMT):
Hm, just saw that ursa-0.3.1 is out already. I missed that because libindy's Cargo.lock is still at ursa-.0.3.0

hartm (Tue, 28 Jan 2020 18:07:51 GMT):
@esplinr @brentzundel @MALodder @cam-parra @Silona Hi Everyone, Silona wants to put together some stuff for the Ursa kiosk at the global forum. You all have expressed an interest--I'm linking everyone here so Silona can get in touch with us all. Thanks!

Silona (Tue, 28 Jan 2020 18:11:44 GMT):
https://wiki.hyperledger.org/display/HGF to sign up

cam-parra (Wed, 29 Jan 2020 00:48:42 GMT):
I believe that @esplinr has signed us up already for a slot. Now we have to figure out what we will do with the time at the kiosk

Silona (Wed, 29 Jan 2020 17:21:41 GMT):
I would like to get a diversity of faces for each of the videos

lovesh (Fri, 31 Jan 2020 07:11:27 GMT):
I am in India (diversity, check) and can do a video presentation if that's an option

EdEykholt (Tue, 04 Feb 2020 01:26:45 GMT):
Has joined the channel.

MALodder (Wed, 05 Feb 2020 15:46:09 GMT):
https://docs.google.com/document/d/1M3zgsRoOxlkjNPbDp4_7YWxuqO2EyefOT3Bt7ZgGIDY/edit

MALodder (Wed, 05 Feb 2020 18:49:39 GMT):
formal audit of the rust dalek crypto libraries https://blog.quarkslab.com/resources/2019-08-26-audit-dalek-libraries/19-06-594-REP.pdf

hartm (Wed, 05 Feb 2020 19:10:24 GMT):
Interesting, thanks for the link Mike.

mccown (Thu, 06 Feb 2020 21:50:56 GMT):
Has joined the channel.

AxelNennker (Sat, 08 Feb 2020 20:22:54 GMT):
shouldn't tests always succeed in master? These fail for me: ``` failures: cl::prover::tests::test_update_proof cl::test::credential_with_negative_attribute_and_empty_proof_works cl::test::demo cl::test::demo_revocation cl::test::multiple_predicates ffi::cl::prover::tests::ursa_cl_proof_free_works ffi::cl::prover::tests::ursa_cl_proof_from_json_works ffi::cl::prover::tests::ursa_cl_proof_to_json_works ffi::cl::prover::tests::ursa_cl_prover_process_credential_signature_signature_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_add_common_attribute_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_add_sub_proof_request_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_finalize_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_add_common_attribute_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_add_sub_proof_request_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_primary_proof ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_revocation_proof ffi::cl::verifier::tests::ursa_cl_verifier_new_proof_verifier_works test result: FAILED. 235 passed; 17 failed; 6 ignored; 0 measured; 0 filtered out ```

AxelNennker (Sat, 08 Feb 2020 20:35:25 GMT):
Am I doing something wrong? cargo test in libursa fails ``` failures: cl::prover::tests::test_update_proof cl::test::credential_with_negative_attribute_and_empty_proof_works cl::test::demo cl::test::demo_revocation cl::test::multiple_predicates ffi::cl::prover::tests::ursa_cl_proof_free_works ffi::cl::prover::tests::ursa_cl_proof_from_json_works ffi::cl::prover::tests::ursa_cl_proof_to_json_works ffi::cl::prover::tests::ursa_cl_prover_process_credential_signature_signature_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_add_common_attribute_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_add_sub_proof_request_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_finalize_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_add_common_attribute_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_add_sub_proof_request_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_primary_proof ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_revocation_proof ffi::cl::verifier::tests::ursa_cl_verifier_new_proof_verifier_works test result: FAILED. 235 passed; 17 failed; 6 ignored; 0 measured; 0 filtered out ```

rjones (Sat, 08 Feb 2020 23:11:35 GMT):
```SODIUM_BUILD_STATIC=yes cargo test -q running 258 tests ```

rjones (Sat, 08 Feb 2020 23:21:12 GMT):
@AxelNennker this is what I got: ```libursa % rustc --version rustc 1.41.0 (5e1a79984 2020-01-27) libursa % git log -1 commit 919d8ac1daec50fb9c3d5ee6ff3476e19e319015 (HEAD -> master, origin/master, origin/HEAD) Author: Michael Lodder Date: Thu Feb 6 11:43:12 2020 -0700 Add VarBlake2 Signed-off-by: Michael Lodder libursa % SODIUM_BUILD_STATIC=yes cargo test -q running 258 tests (elided) test result: ok. 252 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out running 42 tests (elided) test result: ok. 39 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out running 1 test . test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out running 41 tests (elided) test result: ok. 41 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out ry@mba libursa % ```

tplooker (Sun, 09 Feb 2020 10:05:59 GMT):
wasm

thomas_kim (Mon, 10 Feb 2020 10:24:57 GMT):
Has joined the channel.

thomas_kim (Mon, 10 Feb 2020 10:24:59 GMT):
Is the Anoncreds 2.0 available now?

MALodder (Mon, 10 Feb 2020 15:25:41 GMT):
yes

MALodder (Mon, 10 Feb 2020 16:46:41 GMT):
I'm going to release ursa 0.3.2 today. I will notify when that is completed

MALodder (Mon, 10 Feb 2020 21:34:03 GMT):
ursa 0.3.2 is now released

thomas_kim (Tue, 11 Feb 2020 00:54:28 GMT):
Thanks.

hartm (Tue, 11 Feb 2020 06:04:02 GMT):
Thanks Mike!

andrew.whitehead (Tue, 11 Feb 2020 16:54:21 GMT):
I'm seeing an odd error in libzmix (rust analyzer is so nice) - undefined method `eval_alt` on a `VecPoly3` in bulletproofs_amcl/benches/vec_poly_eval.rs. I can't see that the method ever existed or is part of a trait though :thinking:

lovesh (Wed, 12 Feb 2020 07:32:03 GMT):
I had that function at some point but removed it. I might not have upgraded the version of that crate. Will raise a PR with upgraded version.

Silona (Thu, 13 Feb 2020 18:26:36 GMT):
Howdy Contributors and Maintainers! Are you wondering about tapping into Developer marketing for your group or project? Do you have a blog post idea? An awesome announcement? Please attend our Contributor/marketing meeting! https://wiki.hyperledger.org/display/Marketing/2020-02-19+Meeting+notes

thomas_kim (Fri, 14 Feb 2020 04:28:47 GMT):
@MALodder Do you have a specific plan for supporting calculation of witness on cloud agent to avoid downloading of the tails file on edge devices. Thanks in advance!

MALodder (Fri, 14 Feb 2020 04:29:35 GMT):
I don't speicifically but BCGov has more implementation experience in this area. I would take to @andrew.whitehead @swcurran for more info

sankarshanm (Fri, 14 Feb 2020 09:05:12 GMT):
Has joined the channel.

swcurran (Fri, 14 Feb 2020 15:41:56 GMT):
We have thought about that, but have not done it. There is some work being done on the implementation right now and that seems like a good improvement that we'll consider.

swcurran (Fri, 14 Feb 2020 15:43:00 GMT):
Our currently plan is that Anoncreds 1 will be for limited use cases and hence relatively small tails file. Hopefully when we get to broader use cases, Anoncreds2 will be in place in indy/Aries agents.

swcurran (Fri, 14 Feb 2020 15:43:50 GMT):
Let me know if you are interested in helping with the design/implementation--glad to have the help!

hartm (Mon, 17 Feb 2020 00:12:17 GMT):
Are we having the Sovrin crypto call tomorrow morning (the US holiday may make it hard for some to attend)?

brentzundel (Mon, 17 Feb 2020 00:15:52 GMT):
It was moved to Thursday, I believe.

hartm (Mon, 17 Feb 2020 01:07:08 GMT):
Oh, OK--wasn't sure if that was for a different, one-time meeting.

MALodder (Mon, 17 Feb 2020 02:37:02 GMT):
Yes it’s moved to Thursday

MALodder (Mon, 17 Feb 2020 02:37:44 GMT):
@swcurran would love your help in implementing the Aries side

Silona (Mon, 17 Feb 2020 22:19:42 GMT):
Are you wondering about tapping into Developer marketing for your group or project? Do you have a blog post idea? An awesome announcement? Please attend TOMORROW! https://wiki.hyperledger.org/display/Marketing/2020-02-19+Meeting+notes

hartm (Wed, 19 Feb 2020 15:35:16 GMT):
https://eprint.iacr.org/2007/155

victor.martinez (Wed, 19 Feb 2020 18:00:21 GMT):
Has joined the channel.

nacerix (Sun, 23 Feb 2020 14:38:02 GMT):
Has joined the channel.

echo.harker (Thu, 27 Feb 2020 19:53:15 GMT):
Has joined the channel.

AxelNennker (Fri, 28 Feb 2020 12:05:33 GMT):
tried again today ``` axelnennker@Axels-MBP libursa (master) $ SODIUM_BUILD_STATIC=yes cargo test -q running 258 tests ..........................i.....................i.............i.....i.F.FFFF........................ 100/258 .....................................................................FFF...........FFFF............. 200/258 ..........FFFFF................................i....i..... failures: ---- cl::prover::tests::test_update_proof stdout ---- Update Proof test -> start Create RevocationRegistry Time: Duration { secs: 12, nanos: 689417000 } thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UrsaCryptoError { inner: Invalid Signature correctness proof q != q' ```

AxelNennker (Fri, 28 Feb 2020 12:06:38 GMT):
I did `rm -rf ~/.cargo/registry && cd /tmp && git clone ...ursa && cd ursa && cargo test`

AxelNennker (Fri, 28 Feb 2020 12:07:57 GMT):
axelnennker@Axels-MBP libursa (master) $ rustc --version rustc 1.41.1 (f3e1a954d 2020-02-24)

AxelNennker (Fri, 28 Feb 2020 12:08:41 GMT):
axelnennker@Axels-MBP libursa (master) $ git log commit 3230a30f33ea9aa81fa0f0ace68579fa523715bb (HEAD -> master, origin/master, origin/HEAD) Author: Axel Nennker Date: Sun Feb 23 09:25:53 2020 +0100 an inclusive range would be more readable Signed-off-by: Axel Nennker

rjones (Fri, 28 Feb 2020 12:40:07 GMT):
I got this: ```failures: ---- encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail stdout ---- thread 'encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail' panicked at 'assertion failed: res.is_err()', libursa/src/encryption/symm/aesgcm.rs:102:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. failures: encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail test result: FAILED. 251 passed; 1 failed; 6 ignored; 0 measured; 0 filtered out ```

rjones (Fri, 28 Feb 2020 12:40:13 GMT):
different test case

rjones (Fri, 28 Feb 2020 12:41:54 GMT):
Interesting. I turned off a high-CPU load process on the same machine, and that test case passed.

rjones (Fri, 28 Feb 2020 12:49:10 GMT):
worked the second time: ```ry@mba libursa % SODIUM_BUILD_STATIC=yes cargo test -q --lib running 258 tests .......................i.....................i.............i.....i.................................. 100/258 ........................................test cl::test::demo_revocation has been running for over 60 seconds ..............test ffi::cl::issuer::tests::ursa_cl_issuer_new_revocation_registry_def_works has been running for over 60 seconds .............................................. 200/258 ......................................test ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_revocation_proof has been running for over 60 seconds test signatures::bls::normal::tests::batch_signature_verification has been running for over 60 seconds ......i....i.......test signatures::bls::small::tests::batch_signature_verification has been running for over 60 seconds . test result: ok. 252 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out ry@mba libursa % ```

AxelNennker (Sat, 29 Feb 2020 09:38:35 GMT):
I have setup a new ubuntu 16.04 VM and ran the ursa tests there and it works. So, I think that this failure of the ursa tests has to do with macos Darwin Axels-MBP.fritz.box 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64

MALodder (Sat, 29 Feb 2020 17:23:20 GMT):
odd

AxelNennker (Sun, 01 Mar 2020 15:25:37 GMT):
Can somebody with macos confirm this failure of ursa tests?!

MALodder (Sun, 01 Mar 2020 15:26:18 GMT):
they don't fail for me

rjones (Sun, 01 Mar 2020 17:23:15 GMT):
what could I do to debug this?

andrew.whitehead (Sun, 01 Mar 2020 19:09:04 GMT):
Worked for me with SODIUM_BUILD_STATIC and rustc 1.41.0

MALodder (Sun, 01 Mar 2020 19:09:26 GMT):
Works for me

rjones (Sun, 01 Mar 2020 19:13:34 GMT):
from above:

rjones (Sun, 01 Mar 2020 19:13:38 GMT):
```I got this: ```failures: ---- encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail stdout ---- thread 'encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail' panicked at 'assertion failed: res.is_err()', libursa/src/encryption/symm/aesgcm.rs:102:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. failures: encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail test result: FAILED. 251 passed; 1 failed; 6 ignored; 0 measured; 0 filtered out ``` ```

rjones (Sun, 01 Mar 2020 19:13:38 GMT):
I got this: ```failures: ---- encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail stdout ---- thread 'encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail' panicked at 'assertion failed: res.is_err()', libursa/src/encryption/symm/aesgcm.rs:102:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. failures: encryption::symm::aesgcm::aes256_gcm_tests::decrypt_should_fail test result: FAILED. 251 passed; 1 failed; 6 ignored; 0 measured; 0 filtered out ``` ```

rjones (Sun, 01 Mar 2020 19:18:36 GMT):
`SODIUM_BUILD_STATIC=yes cargo test -q -- --test-threads=1`

rjones (Sun, 01 Mar 2020 19:19:05 GMT):
generates some failures. I suspect the other failures are due to CPU load, but I don't have my power adapter with me to run my load generator

andrew.whitehead (Sun, 01 Mar 2020 19:30:26 GMT):
I'm getting failures with --test-threads=1, some weird ones like ursa_cl_proof_free_works

andrew.whitehead (Sun, 01 Mar 2020 19:34:10 GMT):

ursa-test-failures.txt

AxelNennker (Sun, 01 Mar 2020 21:15:20 GMT):
@andrew.whitehead Those are the failures I see as well on macos

AxelNennker (Mon, 02 Mar 2020 07:20:00 GMT):
What is the ursa update schedule? How often is Cargo.lock updated? On average?

MALodder (Mon, 02 Mar 2020 15:53:15 GMT):
About once a month

Artemkaaas (Tue, 03 Mar 2020 10:02:52 GMT):
@MALodder Does Ursa provides asymmetric encryption? We are going to migrate Libindy from sodiumoxide to ursa but I can't find the required functionality.

Artemkaaas (Tue, 03 Mar 2020 10:04:29 GMT):
Is there a documentation regarding the public functions?

Artemkaaas (Tue, 03 Mar 2020 10:04:29 GMT):
Is there documentation regarding the public functions?

MALodder (Tue, 03 Mar 2020 13:39:17 GMT):
Asymmetric encryption is something I’m working on. Ecies only no RSA

hartm (Tue, 03 Mar 2020 17:23:14 GMT):
@here We are cancelling tomorrow's meeting due to the HGF. Feel free to ask questions here if you'd like to bring things up. Thanks!

nage (Tue, 03 Mar 2020 18:09:39 GMT):
HGF == Hyperledger Global Forum in Phoenix Arizona (going on now!)

arsulegai (Wed, 04 Mar 2020 04:54:26 GMT):
Nice to meet you at the event @hartm

hartm (Wed, 04 Mar 2020 04:54:45 GMT):
@arsulegai Same!

sergey.minaev (Wed, 04 Mar 2020 15:32:27 GMT):
Has joined the channel.

sergey.minaev (Wed, 04 Mar 2020 15:32:28 GMT):
@MALodder @brentzundel is https://github.com/hyperledger/ursa-docs/tree/master/specs/anoncreds2 the latest source to read about Revocation 2.0? I'm going to start 2nd round of learning this topic for me and looking for up-to-date math... Could you please point me out the right place.

brentzundel (Wed, 04 Mar 2020 15:54:50 GMT):
Yes, it is

daveek (Mon, 09 Mar 2020 09:27:32 GMT):
Has joined the channel.

daveek (Mon, 09 Mar 2020 09:27:34 GMT):
Hi.. What Cryptographic Primitives are used in Indy & Aries?

MALodder (Mon, 09 Mar 2020 13:32:25 GMT):
The Sovrin Crypto call has been moved to Thursday as a follow up to the HW suggestions from last time and to accomadate those in Europe who wish to attend.

MALodder (Mon, 09 Mar 2020 13:33:49 GMT):
Do you need an exact listing? Is there something specific you are looking for?

cam-parra (Mon, 09 Mar 2020 15:15:33 GMT):
Great article I shared with a few of you at HLGF : https://arxiv.org/pdf/2002.08437.pdf

JonGeater (Mon, 09 Mar 2020 16:53:31 GMT):
"The adversarial model presented by trusted execution envi- ronments (TEEs) has prompted researchers to investigate unusual attack vectors." I think this is a real issue: if you presetn something as 'unbreakable', or even set the context as 'attack by very motivated adversaries' then you make the perfect the enemy of the good and any crazy-ass edge case failure blows up the whole value proposition. Don't get me wrong, I think it's very important to understand the limits of any tchnology and build systems accordingly, but it's also really important with research like this to know how likely it is that YOUR adversary will have THIS capability. I feel rather the same way about emissions-based side channels in mobile devices: they're very clever and occassionally relevant, but in general the risks of someone following you around at close quarters with a directional antenna and you NOT NOTICING are pretty bloody unlikely, and yet the scare about those can put people off putting in place some good basic protections for the pareto attack case

MALodder (Tue, 10 Mar 2020 13:02:41 GMT):
https://wiki.hyperledger.org/display/TSC/2020+Q1+Hyperledger+Ursa

MALodder (Tue, 10 Mar 2020 13:03:17 GMT):
@JonGeater are you planning to come to the Thursday meeting follow up on the HW Interface?

JonGeater (Tue, 10 Mar 2020 13:05:40 GMT):
Sorry I can’t - I’m with a customer. I could do Friday, same time if that works

MALodder (Tue, 10 Mar 2020 14:52:58 GMT):
That works for me. I’ll check with the others

MALodder (Tue, 10 Mar 2020 17:34:39 GMT):
@JonGeater what about these https://www.zdnet.com/article/intel-cpus-vulnerable-to-new-lvi-attacks/

Dan (Tue, 10 Mar 2020 18:10:28 GMT):
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html

sigma67 (Tue, 10 Mar 2020 19:16:36 GMT):
Has joined the channel.

daveek (Wed, 11 Mar 2020 14:37:36 GMT):
Yes, like what libraries are being used in the core and what Primitives are being used.

MALodder (Wed, 11 Mar 2020 19:29:09 GMT):
Dependencies - Openssl - Libsodium - Libsecp256k1 - Apache Milagro - Rust Crypto - Rust Curve25519 Dalek Crypto offered: - Signatures: - Ecdsa - Eddsa - Boney Lynn Shachum (BLS) - Camenisch Lysyanskaya - Boneh Boyen Shachum (BBS+) - Pointcheval Saunders - Groth - Key agreement - Ecdh - x25519 - Encryption - AES-CBC - AES-GCM - XCHACHA20-POLY1305 - Zero-Knowledge proofs - Signature Proofs of Knowledge - Bulletproofs - Range proofs - Set memberships

daveek (Thu, 12 Mar 2020 09:02:14 GMT):
Thanks a lot :) and kindly please put that in Usra Document, it really hard for someone to finds it.

MALodder (Thu, 12 Mar 2020 12:54:41 GMT):
We accept PRs 🙂

MALodder (Thu, 12 Mar 2020 14:14:57 GMT):
The dependencies list is front and center in the README already

andrew.whitehead (Thu, 12 Mar 2020 16:06:34 GMT):
Is there a reason why `issued` and `revoked` are tracked on revocation registry deltas? I can't see that they are used anywhere, but they get published to the ledger and could lead to much larger deltas

andrew.whitehead (Thu, 12 Mar 2020 16:11:15 GMT):
I'm also curious why the newer signature types are in zmix and not ursa, what's the criteria for that?

MALodder (Thu, 12 Mar 2020 17:08:32 GMT):
The plan is actually to move those to ursa and just leave the ZKP stuff in libzmix

Abhishekkishor (Thu, 12 Mar 2020 19:33:48 GMT):
Has joined the channel.

kdenhartog (Fri, 13 Mar 2020 02:21:44 GMT):
Got it added https://github.com/hyperledger/ursa/pull/102

MALodder (Fri, 13 Mar 2020 02:23:04 GMT):
sweet thanks for that

MALodder (Fri, 13 Mar 2020 02:23:09 GMT):
already approved

nage (Fri, 13 Mar 2020 20:27:39 GMT):
https://chat.hyperledger.org/channel/indy?msg=q5X9yyWP5oY5sgFwe

Artemkaaas (Mon, 16 Mar 2020 10:23:37 GMT):
@MALodder Libursa crashes with assertion in case invalid key bytes were provided to ``` Ed25519Sha512::ver_key_to_key_exchange(&PublicKey(node_verkey)) ```

Artemkaaas (Mon, 16 Mar 2020 10:23:53 GMT):
``` thread 'main' panicked at 'assertion failed: `(left == right)` left: `32`, right: `23`: destination and source slices have different lengths', src/libcore/slice/mod.rs:2138:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ```

Artemkaaas (Mon, 16 Mar 2020 10:23:53 GMT):
``` node_verkey = [8, 6, 91, 127, 212, 71, 158, 12, 162, 54, 83, 82, 242, 119, 16, 131, 152, 32, 68, 28, 54, 190, 75] ``` ``` thread 'main' panicked at 'assertion failed: `(left == right)` left: `32`, right: `23`: destination and source slices have different lengths', src/libcore/slice/mod.rs:2138:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. ```

MALodder (Mon, 16 Mar 2020 14:25:49 GMT):
https://github.com/hyperledger/ursa/pull/103

AnnaJ (Tue, 17 Mar 2020 01:42:39 GMT):
From the Sovrin Foundation Board of Trustees: Next Steps for the Sovrin Foundation https://sovrin.org/next-steps-for-the-sovrin-foundation/

shemnon (Tue, 17 Mar 2020 14:39:00 GMT):
Has joined the channel.

hartm (Wed, 18 Mar 2020 01:14:09 GMT):
@here Just a reminder of tomorrow's meeting! You can find the agenda on the wiki as usual. Due to a calendar bug, you may not be able to see the meeting information on the overall calendar, but you can find it on https://lists.hyperledger.org/g/ursa/calendar or just go to https://zoom.us/my/hyperledger.community.backup at 7:00 AM Pacific time as usual. Thanks for your time!

MALodder (Wed, 18 Mar 2020 01:14:25 GMT):
I'll be there

hartm (Wed, 18 Mar 2020 01:24:19 GMT):
@MALodder Great!

hartm (Wed, 18 Mar 2020 01:24:28 GMT):
I suspect we'll have a lot of questions for you.

MALodder (Wed, 18 Mar 2020 01:25:19 GMT):
sounds good

nage (Wed, 18 Mar 2020 22:20:49 GMT):
Your personal effects are some of the last few things left here at the office

nage (Wed, 18 Mar 2020 22:21:05 GMT):
Probably a good idea to stop by and gather them when you have the chance

MALodder (Wed, 18 Mar 2020 22:35:03 GMT):
https://signal.org/blog/secure-value-recovery/

MALodder (Wed, 18 Mar 2020 22:35:18 GMT):
this is interesting, similar to what I was talking about on the call this morning

Artemkaaas (Thu, 19 Mar 2020 18:52:33 GMT):
@MALodder Is Ursa function `keypair` of `Ed25519Sha512 SignatureScheme` with passing seed equal to libsodium `crypto_sign_ed25519_seed_keypair?

Artemkaaas (Thu, 19 Mar 2020 18:57:05 GMT):
I try to use it for transactions signing but when I use `KeyGenOption::UseSeed` option for keys generation I receive the different keys. When I use `KeyGenOption::FromSecretKey` option for keys generation the generated keys and signature are correct.

MALodder (Fri, 20 Mar 2020 02:33:16 GMT):
No they are not the same

MALodder (Fri, 20 Mar 2020 02:34:59 GMT):
Libsodium computes the SHA512 hash of the seed and takes the first 32 bytes, clamps it and that's the private key

MALodder (Fri, 20 Mar 2020 02:36:13 GMT):
Ursa computes the sha256 hash of the seed which then seeds ChaCha which is then used to randomly generate 32 bytes

MALodder (Fri, 20 Mar 2020 02:36:33 GMT):
those bytes are clamped to be the private key

PatrikStas (Sat, 21 Mar 2020 15:19:33 GMT):
Has joined the channel.

tomislav (Sat, 21 Mar 2020 19:52:10 GMT):
Would this be a cause for backward compatibility when moving to ursa from indy?

MALodder (Sat, 21 Mar 2020 19:53:43 GMT):
we could implement something to make them compatibile

mohammadhossein73 (Sun, 29 Mar 2020 05:52:53 GMT):
Has joined the channel.

hartm (Wed, 01 Apr 2020 01:44:14 GMT):
@here Just a reminder for tomorrow's Ursa meeting. Hope to speak to many of you tomorrow!

kdenhartog (Wed, 01 Apr 2020 12:47:21 GMT):
what was the reason for switching @MALodder? Last I was reading libsodium's implementation matches how FIPS 186-5 defines it and how RFC 8032 defines it.

MALodder (Wed, 01 Apr 2020 12:48:41 GMT):
I’m not aware that libsodium does that but will take a look

kdenhartog (Wed, 01 Apr 2020 12:53:03 GMT):
Might be worth looking at Openssl as well. I think they've preemptively implemented against RFC 8032 which is probably why NIST defined things the way they did

kdenhartog (Wed, 01 Apr 2020 12:53:24 GMT):
This is the implementation for OpenSSL https://github.com/openssl/openssl/blob/97b50f67f212589661c9f1edd5285822c6cc642b/crypto/ec/curve25519.c#L5447

SethiSaab (Wed, 01 Apr 2020 13:05:23 GMT):
Has joined the channel.

MALodder (Wed, 01 Apr 2020 13:44:24 GMT):
@kdenhartog what you're pointing at is signing not key generation

MALodder (Wed, 01 Apr 2020 13:44:49 GMT):
ursa is completely compliant with FIPS 186-5 in that way

kdenhartog (Wed, 01 Apr 2020 13:45:46 GMT):
Thanks, key generation is here: https://github.com/openssl/openssl/blob/97b50f67f212589661c9f1edd5285822c6cc642b/crypto/ec/curve25519.c#L5584

kdenhartog (Wed, 01 Apr 2020 13:46:52 GMT):
Similarly RFC 8032 is here https://tools.ietf.org/html/rfc8032#section-5.1.5

MALodder (Wed, 01 Apr 2020 13:47:50 GMT):
What @tomislav and indy are wanting is the creation from a seed - https://github.com/jedisct1/libsodium/blob/master/src/libsodium/crypto_sign/ed25519/ref10/keypair.c#L18

MALodder (Wed, 01 Apr 2020 13:48:18 GMT):
we are following RFC8032

MALodder (Wed, 01 Apr 2020 13:48:43 GMT):
what we are doing differently is seeding the random number generator that is passed to the dalek library

MALodder (Wed, 01 Apr 2020 13:49:35 GMT):
https://docs.rs/ed25519-dalek/1.0.0-pre.3/ed25519_dalek/struct.Keypair.html

MALodder (Wed, 01 Apr 2020 13:49:47 GMT):
They only allow creating the keys from an RNG

MALodder (Wed, 01 Apr 2020 13:50:00 GMT):
otherwise you have to handle the bytes and the clamping manually

MALodder (Wed, 01 Apr 2020 13:50:32 GMT):
https://docs.rs/ed25519-dalek/1.0.0-pre.3/ed25519_dalek/struct.Keypair.html#method.sign

MALodder (Wed, 01 Apr 2020 14:27:29 GMT):
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/?include_text=1

kdenhartog (Wed, 01 Apr 2020 14:35:07 GMT):
Ok I get what you're referring to now, no concerns about your approach now

kdenhartog (Wed, 01 Apr 2020 14:43:04 GMT):
https://eprint.iacr.org/2019/403.pdf

rjones (Wed, 01 Apr 2020 15:30:14 GMT):
Has left the channel.

gnarula (Wed, 01 Apr 2020 18:45:46 GMT):
Has joined the channel.

gnarula (Wed, 01 Apr 2020 18:45:47 GMT):
Hi! I'm working on something that involves validating an indy txn and as a result I need to validate the BLS signatures. Does anyone know which curve is used by Indy? I think it's BN254 but are https://tools.ietf.org/id/draft-kasamatsu-bncurves-01.html#curve254a the parameters?

brentzundel (Thu, 02 Apr 2020 14:16:13 GMT):
I followed the [directions here](https://github.com/hyperledger/ursa/blob/master/docs/build-environment.md) for setting up an ursa build environment on Ubuntu 18.04 yesterday. I was eventually able o get ursa to build, but when I run `cargo test --release` I have 17 failing tests.

brentzundel (Thu, 02 Apr 2020 16:30:29 GMT):
okay, something is seriously wrong with my machine. I installed IntelliJ with the rust plugin and ran tests there. when I run tests in IDE: 411 pass, 0 fail, 9 ignored when I run tests on command line: 235 pass, 17 fail, 6 ignored

brentzundel (Thu, 02 Apr 2020 16:31:09 GMT):
I'm almost to the point of re-installing everything and starting from scratch.

MALodder (Thu, 02 Apr 2020 16:39:37 GMT):
sounds like a good idea to start fresh

andrew.whitehead (Thu, 02 Apr 2020 17:00:43 GMT):
Which tests were failing? I was also seeing 17 failures in the CL module, but it seems to depend on how many threads are running

MALodder (Thu, 02 Apr 2020 17:01:03 GMT):
shouldn't depend on the number of threads

andrew.whitehead (Thu, 02 Apr 2020 17:01:42 GMT):
We were discussing this back on March 1 looks like

pavithraes (Thu, 02 Apr 2020 19:24:18 GMT):
Has joined the channel.

MALodder (Thu, 02 Apr 2020 22:24:57 GMT):
has anyone tried https://blog.filippo.io/rustgo/

MALodder (Thu, 02 Apr 2020 22:25:11 GMT):
call rust code from golang without using cgo

MALodder (Thu, 02 Apr 2020 22:25:18 GMT):
just dynamic linking

MALodder (Thu, 02 Apr 2020 22:27:13 GMT):
its a little weird method but it works

genggjh (Fri, 03 Apr 2020 08:28:14 GMT):
Has joined the channel.

brentzundel (Fri, 03 Apr 2020 17:33:14 GMT):
``` failures: cl::prover::tests::test_update_proof cl::test::credential_with_negative_attribute_and_empty_proof_works cl::test::demo cl::test::demo_revocation cl::test::multiple_predicates ffi::cl::prover::tests::ursa_cl_proof_free_works ffi::cl::prover::tests::ursa_cl_proof_from_json_works ffi::cl::prover::tests::ursa_cl_proof_to_json_works ffi::cl::prover::tests::ursa_cl_prover_process_credential_signature_signature_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_add_common_attribute_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_add_sub_proof_request_works ffi::cl::prover::tests::ursa_cl_prover_proof_builder_finalize_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_add_common_attribute_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_add_sub_proof_request_works ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_primary_proof ffi::cl::verifier::tests::ursa_cl_proof_verifier_verify_works_for_revocation_proof ffi::cl::verifier::tests::ursa_cl_verifier_new_proof_verifier_works ```

ultimo2020 (Fri, 03 Apr 2020 19:45:59 GMT):
Has joined the channel.

ultimo2020 (Fri, 03 Apr 2020 19:46:13 GMT):
Hi everyone. Is Ursa FIPS compliant?

brentzundel (Fri, 03 Apr 2020 20:25:42 GMT):
@MALodder :point_up:

ultimo2020 (Fri, 03 Apr 2020 20:38:42 GMT):
@MALodder - thanks for the info. Is there some online documentation on how Ursa is FIPS compliant? Without HSM or with?

MALodder (Fri, 03 Apr 2020 20:40:51 GMT):

FIPS Compliance and Hyperledger Ursa_Indy_Aries.docx

MALodder (Fri, 03 Apr 2020 20:41:11 GMT):
@ultimo2020 ^^^

ultimo2020 (Fri, 03 Apr 2020 20:42:20 GMT):
Thanks will read it

ultimo2020 (Fri, 03 Apr 2020 21:02:36 GMT):
As far as roadmaps go, the Ursa community is advocating to NIST to approve the algorithms in Ursa first. So still no compliance because of threshold encryption and performance but working towards it with NIST. Hope it gets there. Great document by the way. Are some big industry players using SSI although not quite

MALodder (Fri, 03 Apr 2020 21:35:23 GMT):
A few

MALodder (Fri, 03 Apr 2020 21:36:31 GMT):
Govt and Healthcare are two industries they are in

MALodder (Sat, 04 Apr 2020 00:40:32 GMT):
Performance is not the issue. The algorithms in Ursa are very fast

ultimo2020 (Sat, 04 Apr 2020 05:55:25 GMT):
Yes the are fast. Thanks. But we are still waiting for FIPS compliance? Which big health care industries used although it is still not FIPS compliant?

notsteward (Sun, 05 Apr 2020 20:11:27 GMT):
Has joined the channel.

MALodder (Tue, 07 Apr 2020 05:17:14 GMT):
https://github.com/cryptosubtlety/final-security-bug/blob/master/finalsecuritybug.pdf

MALodder (Tue, 07 Apr 2020 05:17:30 GMT):
Why we don’t use java with google tink

shemnon (Tue, 07 Apr 2020 21:49:24 GMT):
For those who don't want to hand type the link here's the fix - https://github.com/google/tink/commit/d4665a4fdb55fb9f61a0e1c155516138096afb16

shemnon (Tue, 07 Apr 2020 21:50:31 GMT):
They were using an parameter in a mutable context, and using the same variable as both input and output (by reference) from a method call. Google's code reviews should have caught this as it's a fairly run of the mill no-no. But your code reviews are only as good as the code reviewer.

wizAmit (Thu, 09 Apr 2020 10:15:52 GMT):
Has joined the channel.

MALodder (Wed, 15 Apr 2020 14:00:45 GMT):
Ursa meeting in zoom https://zoom.us/my/hyperledger.community.backup

MALodder (Wed, 15 Apr 2020 14:20:14 GMT):
https://eprint.iacr.org/2020/278.pdf

MALodder (Wed, 15 Apr 2020 14:24:40 GMT):
another NIZK paper https://eprint.iacr.org/2020/223.pdf

hartm (Wed, 15 Apr 2020 14:29:06 GMT):
Universal Circuits: https://eprint.iacr.org/2016/017

MALodder (Wed, 15 Apr 2020 14:34:58 GMT):
https://eprint.iacr.org/2020/274.pdf

MALodder (Wed, 15 Apr 2020 14:52:32 GMT):
https://eprint.iacr.org/2020/096.pdf

dhuseby (Wed, 15 Apr 2020 14:57:20 GMT):
https://hub.link/8LLkRtm

nage (Wed, 15 Apr 2020 14:57:34 GMT):
Harts broken fiber story reminded me of this classic https://www.ibiblio.org/harris/500milemail.html

Dan (Thu, 16 Apr 2020 22:02:26 GMT):
[ot] fun with covid and bluetooth https://arstechnica.com/information-technology/2020/04/apple-and-google-detail-bold-and-ambitious-plan-to-track-covid-19-at-scale/

MALodder (Sat, 18 Apr 2020 14:35:36 GMT):
Received an email back from Jan Camenischs team about deriving BBS+ generators as we are on the fly and they approved it

MALodder (Sat, 18 Apr 2020 14:35:53 GMT):
For the DeterministicPublicKey

daveek (Sun, 19 Apr 2020 12:35:55 GMT):
Hi, Can anyone please explain or share some docs about Indy/Usra Threat Model? a) What's the Threat Model for Hyperledger Indy/Usra? b) Where is Indy/Usra most vulnerable to attack? c) What are the most relevant threats? d) What do I need to do to safeguard against these threats?

kdenhartog (Sun, 19 Apr 2020 22:28:36 GMT):
Just saw this paper on a way to optimize the number of operations when using Montgomery ladders. Seemed pretty interesting: https://eprint.iacr.org/2020/437.pdf

hartm (Sun, 19 Apr 2020 23:25:19 GMT):
Thanks for your questions! Ursa is a library, rather than a system, so there really isn't a thread model other than the definitions of the primitives themselves. Questions b) and c) are all really a matter of opinion since we are implementing standard or published primitives. Question d) depends on how you are using the primitives.

daveek (Mon, 20 Apr 2020 11:42:53 GMT):
Thanks for response, anyone who knows about Indy?

daveek (Mon, 20 Apr 2020 11:42:53 GMT):
Thanks for response, anyone with a knowledge of Indy?

daveek (Mon, 20 Apr 2020 11:42:53 GMT):
Thanks for response, anyone with a knowledge of Indy Threat Model?

MALodder (Mon, 20 Apr 2020 13:26:26 GMT):
I would ask that question in the #indy channel

daveek (Mon, 20 Apr 2020 21:48:38 GMT):
@MALodder thanks, I'll be waiting.

SethiSaab (Wed, 22 Apr 2020 07:13:45 GMT):
Hi Guys , When do we have Ursa's weekly calls ?

SethiSaab (Wed, 22 Apr 2020 07:13:50 GMT):
please share the schedule

MALodder (Wed, 22 Apr 2020 12:09:54 GMT):
Ursa has bi-weekly calls on Wednesday morning at 8am MDT. Our next call is on Apr 29

Siva_Kannan (Mon, 27 Apr 2020 14:49:45 GMT):
Has joined the channel.

danielhardman (Mon, 27 Apr 2020 16:58:33 GMT):
@MALodder : do you have time this afternoon to teach me some things about the ursa impl of merkle trees. Some of the impl is not making sense to me, and I think it's because I've got a subtle assumption or two wrong somewhere.

MALodder (Mon, 27 Apr 2020 16:58:50 GMT):
sure

MALodder (Mon, 27 Apr 2020 16:58:51 GMT):
what time

tplooker (Tue, 28 Apr 2020 20:44:12 GMT):
Want to take an opportunity to recognise all the hard work of the URSA maintainers, thankyou all! We open sourced these repos today that rely on URSA's implementation of BBS to achieve ZKP capable verifiable credentials https://github.com/mattrglobal/node-bbs-signatures https://github.com/mattrglobal/jsonld-signatures-bbs-spec https://github.com/mattrglobal/jsonld-signatures-bbs

tplooker (Tue, 28 Apr 2020 20:44:12 GMT):
I want to take an opportunity to recognise all the hard work of the URSA maintainers, thankyou all! We open sourced these repos today that rely on URSA's implementation of BBS to achieve ZKP capable verifiable credentials https://github.com/mattrglobal/node-bbs-signatures https://github.com/mattrglobal/jsonld-signatures-bbs-spec https://github.com/mattrglobal/jsonld-signatures-bbs

brentzundel (Tue, 28 Apr 2020 21:04:13 GMT):
It was a great presentation.

brentzundel (Tue, 28 Apr 2020 22:20:18 GMT):
Is there still an Ursa meeting tomorrow?

brentzundel (Tue, 28 Apr 2020 22:20:55 GMT):
@MALodder :point_up:

MALodder (Tue, 28 Apr 2020 22:21:06 GMT):
I hope so

MALodder (Tue, 28 Apr 2020 22:21:13 GMT):
@hartm ^^

brentzundel (Tue, 28 Apr 2020 22:21:20 GMT):
Cool. I'll be there then.

hartm (Tue, 28 Apr 2020 23:22:52 GMT):
Yes, there is always a meeting every other Wednesday!

hartm (Tue, 28 Apr 2020 23:30:05 GMT):
I've pushed a meeting agenda. Feel free to add what you like! I don't have a ton of stuff so please add what you like.

MALodder (Wed, 29 Apr 2020 00:35:42 GMT):
I added stuff

hartm (Wed, 29 Apr 2020 01:54:53 GMT):
Great!

hartm (Wed, 29 Apr 2020 01:54:57 GMT):
Talk to you tomorrow then.

MALodder (Wed, 29 Apr 2020 14:42:04 GMT):
Structure preserving CCA secure encryption and applica-tions.

MALodder (Wed, 29 Apr 2020 14:42:18 GMT):
https://www.iacr.org/archive/asiacrypt2011/70730088/70730088.pdf

MALodder (Wed, 29 Apr 2020 15:11:07 GMT):
Looks like pairing-plus is significantly faster than milagro

MALodder (Wed, 29 Apr 2020 15:11:11 GMT):
``` Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 16: 104 in 3.10s. 28.952 ms/iter Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 64: 107 in 3.20s. 28.234 ms/iter Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 256: 107 in 3.10s. 28.196 ms/iter Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 1024: 105 in 3.20s. 28.790 ms/iter Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 8192: 106 in 3.10s. 28.415 ms/iter Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 16384: 96 in 3.30s. 31.562 ms/iter Doing milagro bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 65535: 93 in 3.00s. 32.355 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 16: 28912 in 3.00s. 0.104 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 64: 28194 in 3.00s. 0.106 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 256: 27713 in 3.00s. 0.108 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 1024: 26663 in 3.00s. 0.113 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 8192: 20693 in 3.00s. 0.145 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 16384: 15840 in 3.00s. 0.189 ms/iter Doing pairing bls12-381-g1-sswu-hash-to-curve-xmd-sha256 for 3s on message size 65535: 6731 in 3.00s. 0.446 ms/iter ```

hartm (Wed, 29 Apr 2020 15:21:32 GMT):
That's quite a bit faster, yeah.

Philser 1 (Thu, 30 Apr 2020 14:39:01 GMT):
Has joined the channel.

Philser 1 (Thu, 30 Apr 2020 14:45:08 GMT):
Hello everyone, not sure if this is the right channel to ask this. Correct me if I'm wrong. So, I have been trying to get my project that depends on Ursa to compile to wasm. Is there any trick to it? Because right now I get a bunch of error messages when trying to compile. Packages like secp256k1 and clear_on_drop always give compile errors during the build. Is there a working example of a project using ursa that is being compiled to wasm, or some guide lying around? Thank you.

MALodder (Fri, 01 May 2020 04:46:23 GMT):
I believe the command you need is `cd libursa`

MALodder (Fri, 01 May 2020 04:47:36 GMT):
`wasm-pack build — —no-default-features —features=portable_wasm`

MALodder (Fri, 01 May 2020 04:50:04 GMT):
There are other flags that can remove everything but secp256k1

MALodder (Fri, 01 May 2020 04:50:56 GMT):
But I’ll look it tomorrow

madiazp (Sat, 09 May 2020 23:35:17 GMT):
Has joined the channel.

madiazp (Sat, 09 May 2020 23:35:19 GMT):
Hi everyone. I have some questions , so Ursa libzmix is wasm friendly? Can I generate a bulletproof proof from an arbitrary computation like zk-snarks? say I want to prove that a public key belongs to a merkle tree and then verify a signature with it where the public key is a witness, can I compute that into a bulletproof? Is somewhere a doc/tutorial to learn how to code and generate a bulletproof? thanks!

madiazp (Sat, 09 May 2020 23:36:40 GMT):
I meant a more detailed doc about zkl

alexpuig (Mon, 11 May 2020 06:13:08 GMT):
Has joined the channel.

alexpuig (Mon, 11 May 2020 06:16:42 GMT):
Hi everyone. Just new to Ursa, and planning to include it in a Rust project. Any step-by-step tutorial or similar on how to start working with Ursa? If not, with your help, I could write one :)

swcurran (Mon, 11 May 2020 13:36:29 GMT):
@MALodder ^^^

MALodder (Mon, 11 May 2020 14:12:52 GMT):
@madiazp Ursa is wasm compatible, in theory libzmix is too but we haven't tested it yet to be. Nor are there any interfaces exposed to wasm yet. However, its not hard to do and contributions are welcome. To answer your other questions, the answer is yet you can do merkle proofs using the bulletproofs_amcl portion of the code. The documentation we have is here https://github.com/hyperledger/ursa/tree/master/libzmix/bulletproofs_amcl

MALodder (Mon, 11 May 2020 14:13:35 GMT):
@alexpuig good question, is there a specific feature of ursa you are looking to use? That will help with determining which sections you will need to include

shemnon (Mon, 11 May 2020 15:52:42 GMT):
Has left the channel.

MALodder (Mon, 11 May 2020 20:48:56 GMT):
https://github.com/hyperledger/ursa/pull/119

MALodder (Mon, 11 May 2020 20:48:59 GMT):
New PR

MALodder (Mon, 11 May 2020 20:49:02 GMT):
need reviews

spacemandev (Mon, 11 May 2020 23:43:13 GMT):
Has joined the channel.

alexpuig (Tue, 12 May 2020 05:57:03 GMT):
Merkle proofs. But, it would be good to have a step-by-step intro to Ursa for developers

MALodder (Wed, 13 May 2020 02:27:13 GMT):
Ursa call at 7am pst tomorrow

MALodder (Wed, 13 May 2020 02:27:18 GMT):
Hope to see you all there

madiazp (Wed, 13 May 2020 02:47:13 GMT):
Good! So there isn't (yet?) a DSL (like zokrates or circom ) for bulletproof ursa, and if I want to code some constrains I have to do it in a rust program that calls the lib? and what is exactly is zkl then? thanks!

spacemandev (Wed, 13 May 2020 03:07:46 GMT):
Has left the channel.

MALodder (Wed, 13 May 2020 04:57:44 GMT):
Zkl will be description language for creating ZKPs

madiazp (Wed, 13 May 2020 05:00:46 GMT):
zkps like in general, whatever schema? or it will be specific to bulletproof?

MALodder (Wed, 13 May 2020 05:01:26 GMT):
Any kind. We’re starting with Bulletproofs but it can include snarks or starks

madiazp (Wed, 13 May 2020 05:02:00 GMT):
awesome, is there a way to contribute?

MALodder (Wed, 13 May 2020 05:02:25 GMT):
Yes we should discuss on Ursa call tomorrow

madiazp (Wed, 13 May 2020 05:03:07 GMT):
unfortunately I have to be in my works meetings :(

madiazp (Wed, 13 May 2020 05:04:05 GMT):
but you guys work on Jira, like all hyperledger projects

hartm (Wed, 13 May 2020 14:12:51 GMT):
https://eprint.iacr.org/2020/374.pdf

hartm (Wed, 13 May 2020 14:12:55 GMT):
Diogenes paper

MALodder (Wed, 13 May 2020 14:19:20 GMT):
https://tlu.tarilabs.com/cryptography/r1cs-bulletproofs/mainreport.html

hartm (Wed, 13 May 2020 14:24:49 GMT):
https://eprint.iacr.org/2007/155

hartm (Wed, 13 May 2020 14:24:56 GMT):
Groth-Sahai proofs

MALodder (Thu, 14 May 2020 15:43:48 GMT):
pallier encryption is based on groups of unknown order right

MALodder (Thu, 14 May 2020 15:45:01 GMT):
???

hartm (Thu, 14 May 2020 15:49:40 GMT):
Yes, that's right.

pradeeppadmarajaiah (Fri, 15 May 2020 05:51:02 GMT):
Has joined the channel.

MALodder (Fri, 15 May 2020 17:54:32 GMT):
why would pallier encryption be used threshold ECDSA then?

MALodder (Fri, 15 May 2020 17:54:41 GMT):
I've been diving into that too

hartm (Fri, 15 May 2020 19:12:54 GMT):
Which paper are you referring to?

MALodder (Fri, 15 May 2020 20:01:36 GMT):
https://eprint.iacr.org/2016/013.pdf

MALodder (Fri, 15 May 2020 20:02:29 GMT):
section 2.1

MALodder (Fri, 15 May 2020 20:03:03 GMT):
but its through out the entire paper

hartm (Sat, 16 May 2020 00:26:17 GMT):
I think they use Paillier for the "dealerless" (i.e. no central authority) key generation.

jmbarry (Mon, 18 May 2020 15:01:24 GMT):
Has joined the channel.

Philser 1 (Wed, 20 May 2020 09:08:34 GMT):
I seem to have a problem with creating a credential definition when compiling ursa to wasm. I can see that ursa uses glass_pumpkin (https://github.com/mikelodder7/glass_pumpkin) library instead of openssl to generate primes when enabling wasm-compatibility. This library never finishes generating prime numbers there (well, at least I stopped running it after 30 mins). Is this a known behaviour? I was able to recreate that behaviour when creating a new project depending only on glass_pumpkin. In there i run the following code which never stops executing: ``` use glass_pumpkin::safe_prime; fn main() { let size = 1024; let prime = safe_prime::new(size).unwrap(); } ```

Dan (Wed, 20 May 2020 19:42:18 GMT):
Hey, I'm not going to be available for the call next week. On the off chance a lot of other people are out for the short week (U.S. Memorial Day) I thought I'd see about sliding the meeting back a week. If not, I'll just watch the replay. If we do meet 6/3 I've got some old GS slides I dust off for discussion. Maybe update them to a bullet proofs context.

hartm (Wed, 20 May 2020 19:46:59 GMT):
Thanks for bringing this up Dan.

hartm (Wed, 20 May 2020 19:47:07 GMT):
Does anybody else want to push this back a week?

Dan (Wed, 20 May 2020 22:17:05 GMT):
Does anybody else NOT want to push this back a week? (that's a little, 'is anybody listening' test ;) )

hartm (Thu, 21 May 2020 01:41:20 GMT):
I am fine with whatever works.

MALodder (Thu, 21 May 2020 04:42:40 GMT):
haven't seen that behavior before but its usually due to something else

MALodder (Thu, 21 May 2020 04:43:37 GMT):
try another method to see if those return. My bet is that its all slow in wasm

brentzundel (Thu, 21 May 2020 16:25:09 GMT):
moving it back a week works for me

brentzundel (Thu, 21 May 2020 16:25:17 GMT):
or forward, rather

MALodder (Thu, 21 May 2020 21:09:12 GMT):
Either one

danielhardman (Thu, 21 May 2020 23:53:11 GMT):
Does anyone have insight about these 3 persistent warnings emitted by the ursa build? ``` warning: use of deprecated item 'amcl_wrapper::group_elem_g1::G1Vector::inner_product_var_time_with_ref_vecs': Please use the `inner_product_var_time` function instead ``` I wouldn't mind cleaning this up, if it's easy. But am I setting myself an impossible task?

danielhardman (Fri, 22 May 2020 00:20:57 GMT):
BTW, could someone please review and merge this minor PR? https://github.com/hyperledger/ursa/pull/122

danielhardman (Fri, 22 May 2020 00:21:19 GMT):
^ @MALodder or @brentzundel

MALodder (Fri, 22 May 2020 00:22:13 GMT):
@danielhardman I have removed these in other parts of the code so I'm better suited to eliminate these. These will disappear as I remove milagro

MALodder (Fri, 22 May 2020 00:22:26 GMT):
Will review your PR

danielhardman (Fri, 22 May 2020 00:22:37 GMT):
Okay. Thanks. I'll let them disappear organically, then.

danielhardman (Fri, 22 May 2020 00:22:46 GMT):
The PR isn't a code change; it's just a build env instructions change.

MALodder (Fri, 22 May 2020 00:22:55 GMT):
I agree they are annoying, and that's why I've been working on slowly removing it

jmason900 (Fri, 22 May 2020 20:00:41 GMT):
Has joined the channel.

jmason900 (Fri, 22 May 2020 20:04:40 GMT):
NIST has validated a number of crypto packages as FIPS-140.2 compliant. Golang crypto package is not. Does anyone know if URSA is now NIST validated as FIPS compliant ? @dhuseby ? Thanks.

dhuseby (Fri, 22 May 2020 20:50:45 GMT):
@jmason900 you might want to double check with @MALodder but Ursa wraps some FIPS compliant crypto but the code we have written hasn't been formally evaluated to be FIPS compliant.

MALodder (Fri, 22 May 2020 20:51:21 GMT):
The only FIPS compliant stuff we've wrapped is OpenSSL

jmason900 (Fri, 22 May 2020 21:26:02 GMT):
perfect - thanks ! OpenSSL is FIPS compliant

Moshe7 (Sat, 23 May 2020 10:08:56 GMT):
Has joined the channel.

hartm (Wed, 27 May 2020 01:54:16 GMT):
@here Due to popular demand, we will be postponing this week's meeting until next week. We'll go over zero knowledge techniques then. I'll send out some materials soon, probably tomorrow.

hartm (Wed, 27 May 2020 01:54:25 GMT):
Thanks!

toddinpal (Thu, 28 May 2020 19:25:01 GMT):
Are you going to update the Hyperledger calendar?

danintel (Fri, 29 May 2020 16:22:47 GMT):
FYI, OpenSSL is FIPS PUB 140 compliant if the FIPS source is used--it does not apply to other releases

danintel (Fri, 29 May 2020 16:22:47 GMT):
FYI, OpenSSL is FIPS PUB 140 compliant if the FIPS source is used--it does not apply to other releases. See https://www.openssl.org/source/

andrew.whitehead (Fri, 29 May 2020 23:30:23 GMT):
First draft of RFC is here @MALodder @brentzundel https://github.com/andrewwhitehead/ursa-rfcs/tree/non-rev-tree/text/0000-revocation-range-tree

Moshe7 (Sat, 30 May 2020 21:07:58 GMT):
ZPK x20 faster, can help to ursa? https://mobile.twitter.com/StarkWareLtd/status/1264911004099543040

Dan (Mon, 01 Jun 2020 14:56:03 GMT):
one week or one session.. i.e. are we meeting this week or next week (june 3 or 10)?

hartm (Mon, 01 Jun 2020 16:06:44 GMT):
I was planning on this week. I hope that's how others interpreted it....

andrew.whitehead (Mon, 01 Jun 2020 16:14:25 GMT):
I've also added a poseidon hash test to the brangetree library (brt-phash example)

Dan (Mon, 01 Jun 2020 16:31:27 GMT):
Yep. Just double checking.

hartm (Tue, 02 Jun 2020 02:14:01 GMT):
I've tried creating a calendar event but it's taking a while to propogate...

MALodder (Tue, 02 Jun 2020 14:40:41 GMT):
nice, thanks for doing that

hartm (Tue, 02 Jun 2020 22:00:07 GMT):
@rjones @dhuseby I tried to create a one-time event for tomorrow morning on the calendar and it doesn't seem to be going through. Any suggestions? Thanks for your time, and sorry for the trouble.

rjones (Tue, 02 Jun 2020 22:00:07 GMT):
Has joined the channel.

rjones (Tue, 02 Jun 2020 22:19:01 GMT):
is it on the groups.io interface? the google calendar only syncs up once a day or so

rjones (Tue, 02 Jun 2020 22:19:49 GMT):
@hartm I see it on g.io, it will take time to get to Google. If you want I can mail the event to the list

rjones (Tue, 02 Jun 2020 22:20:30 GMT):
Oh, I see you did send it to the list. https://lists.hyperledger.org/g/ursa/message/223

hartm (Wed, 03 Jun 2020 13:52:32 GMT):
@here Let's use https://zoom.us/my/hyperledger.community for the meeting.

hartm (Wed, 03 Jun 2020 13:52:35 GMT):
It seems to be unbooked.

brentzundel (Wed, 03 Jun 2020 14:24:13 GMT):
original document that was the basis of the rfc we are going to look at next time: https://hackmd.io/U75EBm_0QriauVUY_CIayQ

wip-abramson (Wed, 03 Jun 2020 14:34:50 GMT):
Hey is the call now? I have 4pm BST in my calendar

Dan (Wed, 03 Jun 2020 15:04:16 GMT):
sorry just saw your msg now @wip-abramson we just wrapped the call.

wip-abramson (Wed, 03 Jun 2020 15:10:38 GMT):
No worries, I have updated my calendar. Not sure why I was off

wip-abramson (Wed, 03 Jun 2020 15:11:16 GMT):
I don't suppose the calls are recorded

jonnycrunch (Fri, 05 Jun 2020 18:32:47 GMT):
Has joined the channel.

MALodder (Sat, 06 Jun 2020 04:15:47 GMT):
No they’re not

c3226075131 (Sun, 07 Jun 2020 13:58:10 GMT):
Has joined the channel.

MALodder (Mon, 08 Jun 2020 15:36:11 GMT):
Ohh this is nice, I wonder if its practical, https://eprint.iacr.org/2002/657

MALodder (Mon, 08 Jun 2020 15:36:11 GMT):
Ohh this is nice, I wonder if its practical, https://eprint.iacr.org/2020/657

MALodder (Mon, 08 Jun 2020 15:37:30 GMT):
Not necessarily interested in the traceable part, but the aggregation is sweet since the proofs can be collapsed from K issuers to a signature signature

MALodder (Mon, 08 Jun 2020 15:37:30 GMT):
Not necessarily interested in the traceable part, but the aggregation is sweet since the proofs can be collapsed from K issuers to a single signature

MALodder (Mon, 08 Jun 2020 15:39:36 GMT):
Also for those interested https://github.com/mattrglobal/bbs-signatures is a wasm build for the BBS+ signatures

MALodder (Mon, 08 Jun 2020 15:39:56 GMT):
And the nodejs version https://github.com/mattrglobal/node-bbs-signatures

MALodder (Mon, 08 Jun 2020 15:40:10 GMT):
Joint effort between me and MattrGlobal

rjones (Mon, 08 Jun 2020 15:41:21 GMT):
@MALodder [thoughts?](https://github.com/hyperledger/indy-crypto/pull/168)

swcurran (Mon, 08 Jun 2020 16:41:12 GMT):
Hey @MALodder -- any progress on the non-revocation range tree proofs?

MALodder (Mon, 08 Jun 2020 16:42:19 GMT):
yes we discussed it and the cryptographers need more information about @andrew.whitehead's idea

MALodder (Mon, 08 Jun 2020 16:42:32 GMT):
there were concerns about privacy leaks when the tree is updated

MALodder (Mon, 08 Jun 2020 16:44:11 GMT):
because the tree shape is constantly changing

swcurran (Mon, 08 Jun 2020 16:44:19 GMT):
Been thinking about that. Is that because of the bit updates being visible to all?

MALodder (Mon, 08 Jun 2020 16:48:38 GMT):
no its like path 1 was valid before but is not now but you proved in path 2. Assuming paths are zero-knowledge it shouldn't be a problem but we just want to check it

swcurran (Mon, 08 Jun 2020 16:49:22 GMT):
Where is the conversation happening? Just want to be sure that Andrew's aware.

MALodder (Mon, 08 Jun 2020 16:49:39 GMT):
here and the meeting

swcurran (Mon, 08 Jun 2020 16:49:57 GMT):
k

hartm (Mon, 08 Jun 2020 16:59:22 GMT):
We can talk about it at the meeting on Wednesday, if people are interested.

MALodder (Mon, 08 Jun 2020 23:13:34 GMT):
Can I get some reviewers on https://github.com/hyperledger/ursa/pull/123

MALodder (Mon, 08 Jun 2020 23:13:48 GMT):
I need that merged so it can unblock 124

hartm (Tue, 09 Jun 2020 01:03:05 GMT):
@MALodder is there anything in there you'd particularly like me to look at? I'm guessing this is a PR for the more practical people, though.

MALodder (Tue, 09 Jun 2020 01:11:42 GMT):
It’s more practical. It just adds wasm to BBS

swcurran (Tue, 09 Jun 2020 03:21:38 GMT):
"just" ^^^ :-)

LuisOcegueda (Tue, 09 Jun 2020 14:31:53 GMT):
Has joined the channel.

MALodder (Wed, 10 Jun 2020 13:19:32 GMT):
@hartm are we planning to use the same room as last time or the community.backup?

hartm (Wed, 10 Jun 2020 13:41:49 GMT):
Let's use the one that's in the calendar!

hartm (Wed, 10 Jun 2020 13:45:41 GMT):
We should also go over this paper: https://eprint.iacr.org/2016/663.pdf. Manu (correctly) pointed out that the paper I send out on EPID has some flaws.

MALodder (Wed, 10 Jun 2020 13:59:20 GMT):
here's another paper I'd like to go over https://eprint.iacr.org/2018/1188.pdf

MALodder (Wed, 10 Jun 2020 13:59:43 GMT):
since the main topic I'm wanting from EPID is revocation

Dan (Wed, 10 Jun 2020 14:52:03 GMT):
https://wiki.hyperledger.org/x/kw7cAQ

Dan (Wed, 10 Jun 2020 14:53:34 GMT):
Hyperledger D&I Talk in ~ 2 hrs ^

MALodder (Wed, 10 Jun 2020 14:59:55 GMT):
https://github.com/mikelodder7/accumulator-rs

MALodder (Wed, 10 Jun 2020 20:50:34 GMT):
https://www.vice.com/en_us/article/v7gd9b/facebook-helped-fbi-hack-child-predator-buster-hernandez

MALodder (Wed, 10 Jun 2020 20:50:45 GMT):
This is both cool and frightening

MALodder (Wed, 10 Jun 2020 20:51:27 GMT):
Goes to show that even with a high amount of anonymity, enough resources can still unmask you

Dan (Thu, 11 Jun 2020 14:13:59 GMT):
true enough.. a good way to think of any security property.. all about resources to be captured vs expended.

S3bb1 (Fri, 12 Jun 2020 11:48:05 GMT):
Has joined the channel.

S3bb1 (Fri, 12 Jun 2020 13:27:23 GMT):
Hi, were currently using ursa with CL ... one question is, when i create a Schema with 3 fields .... then creating a definition out of this and issue a credential with only 2 fields ... afterwards creating a proof request of 1 field ... the created proof cannot be verified and always returns revoked. When i instead issue a credential with all 3 fields the proof works

domwoe (Fri, 12 Jun 2020 13:35:43 GMT):
AFAIK you can't issue a credential with less attributes than defined in the credential definition. You have to provide at least an empty string.

S3bb1 (Fri, 12 Jun 2020 13:40:04 GMT):
thx! :)

tomislav (Mon, 15 Jun 2020 18:43:09 GMT):
can't issue with less or more, indy will throw invalid structure error

MALodder (Tue, 16 Jun 2020 15:20:36 GMT):
As discussed on the last ursa call, I have written a project organization proposal https://github.com/hyperledger/ursa-rfcs/pull/26/files?short_path=dc0e8c0#diff-dc0e8c0571512902d7473706879a71ff

MALodder (Tue, 16 Jun 2020 15:20:45 GMT):
Please add comments

MALodder (Tue, 16 Jun 2020 15:23:12 GMT):
I hope you can all review it and comment before the next meeting. Looking forward to hearing from you.

MALodder (Thu, 18 Jun 2020 15:41:23 GMT):
https://eprint.iacr.org/2020/724.pdf relevant to our discussions around revocation

MALodder (Fri, 19 Jun 2020 17:44:55 GMT):
Can I get some lovin with https://github.com/hyperledger/ursa/pull/123

swcurran (Sun, 21 Jun 2020 13:39:48 GMT):
I'm trying to do a `cargo run` on Windows for an app built using indy-vdr, which in turn uses Ursa. After a few bumps, I have it to the point of compiling Ursa, whenre where I'm getting 493 Unresolved External errors on the linking process. Presumably, when it is compiling the source, it is not including external symbols. Example: ` libopenssl_sys-93af6d3e2a3e76ab.rlib(openssl_sys-93af6d3e2a3e76ab.openssl_sys.dpmbxioq-cgu.9.rcgu.o) : error LNK2019: unresolved external symbol _SSL_CTX_callback_ctrl referenced in function __ZN11openssl_sys4tls138SSL_CTX_set_tlsext_servername_callback17h954b337050a52513E` Anyone ever run this on Windows? Any ideas for how to deal with this? Failing step: `Compiling ursa v0.3.4 (https://github.com/hyperledger/ursa?rev=5444d41707c05399e191c2290d2767658d14fbc4#5444d417)`

swcurran (Sun, 21 Jun 2020 13:40:44 GMT):
I have the OPENSSL_DIR set and that seems to be working.

swcurran (Sun, 21 Jun 2020 13:41:18 GMT):
Works fine on a Mac; googling is not giving me much.

rjones (Sun, 21 Jun 2020 17:29:37 GMT):
so the question is: how to build Ursa for Windows?

rjones (Sun, 21 Jun 2020 17:29:53 GMT):
are you using WSL2?

rjones (Sun, 21 Jun 2020 17:48:33 GMT):
@swcurran do you have a test app I could compile? I see that the compilation works on AppVeyor

swcurran (Sun, 21 Jun 2020 18:26:08 GMT):
So for this issue, @andrew.whitehead changed the app build script, I think to download vs. build ursa. So that solved the issue. ** That said, I did try building ursa itself, following the prereq instructions here: https://github.com/hyperledger/ursa/blob/master/docs/build-environment.md#windows-10 It went pretty well, until I hit a compile error here on compiling Ursa itself: ``` Compiling ursa v0.3.4 (C:\Users\swcur\repos\ursa\libursa) error[E0512]: cannot transmute between types of different sizes, or dependently-sized types --> libursa\src\ffi\mod.rs:59:18 | 59 | unsafe { std::mem::transmute(self) } | ^^^^^^^^^^^^^^^^^^^ | = note: source type: `ffi::ByteArray` (64 bits) = note: target type: `ffi_support::ByteBuffer` (128 bits) warning: 3 warnings emitted error: aborting due to previous error For more information about this error, try `rustc --explain E0512`. error: could not compile `ursa`. To learn more, run the command again with --verbose. warning: build failed, waiting for other jobs to finish... error: build failed ```

swcurran (Sun, 21 Jun 2020 18:27:05 GMT):
For the original issue - the repo I was using is: https://github.com/andrewwhitehead/endorser-tool

rjones (Sun, 21 Jun 2020 18:27:11 GMT):
OK; I was building with WSL2

swcurran (Sun, 21 Jun 2020 18:27:22 GMT):
I'm on plain Jane Windows 10

andrew.whitehead (Sun, 21 Jun 2020 18:27:25 GMT):
Actually I'm just building with `cl` instead of `cl_native` so there's no openssl dependency, it only needs the data types anyway

swcurran (Sun, 21 Jun 2020 18:28:00 GMT):
Ah...so slower but that's not a big issue for this app.

rjones (Sun, 21 Jun 2020 18:28:36 GMT):
should Ursa be publishing to AppVeyor or similar?

dhuseby (Mon, 22 Jun 2020 16:00:48 GMT):
@swcurran your issue makes me wonder if the W10 vs WSL2 implementations of the Rust libstd has different type sizes for standard types.

dhuseby (Mon, 22 Jun 2020 16:01:00 GMT):
like usize might be different

dhuseby (Mon, 22 Jun 2020 16:01:37 GMT):
I know on Linux it is an alias for u64 but on Win10 it *might* be a u128 :man_shrugging_light_skin_tone:

dhuseby (Mon, 22 Jun 2020 16:02:04 GMT):
oh duh

dhuseby (Mon, 22 Jun 2020 16:02:05 GMT):
= note: source type: `ffi::ByteArray` (64 bits) = note: target type: `ffi_support::ByteBuffer` (128 bits)

dhuseby (Mon, 22 Jun 2020 16:02:18 GMT):
says in the error. thankyouverymuch awesome rustc errors

dhuseby (Mon, 22 Jun 2020 16:03:06 GMT):
my guess is ByteArray is a naked pointer and ByteBuffer is pointer + length of buffer

andrew.whitehead (Mon, 22 Jun 2020 16:11:36 GMT):
ByteBuffer source says '`i64` is used for the length instead of `u64` and `usize` because JNA has interop issues with both these types'

MALodder (Mon, 22 Jun 2020 18:07:51 GMT):
ursa does build in AppVeyor and tests cl as long as openssl is already installed

MALodder (Mon, 22 Jun 2020 18:08:43 GMT):
@dhuseby @swcurran my PR fixes those already https://github.com/hyperledger/ursa/pull/123

MALodder (Mon, 22 Jun 2020 18:09:13 GMT):
@dhuseby can you review my PR?

MALodder (Mon, 22 Jun 2020 18:09:29 GMT):
this needs to get merged soon, its blocking three other PRs

MALodder (Mon, 22 Jun 2020 18:09:41 GMT):
and people are starting to hit this problem everywhere

MALodder (Mon, 22 Jun 2020 18:09:59 GMT):
@brentzundel @cam-parra

MALodder (Mon, 22 Jun 2020 18:10:01 GMT):
^^^^

MALodder (Mon, 22 Jun 2020 18:12:23 GMT):
ByteArray is solely used for receiving pointers and a length, ByteBuffer is for returning them

rjones (Mon, 22 Jun 2020 19:07:57 GMT):
It looks like it's approved by one - do you want me to set the review requirement for ursa to one review required for mergin?

rjones (Mon, 22 Jun 2020 19:07:57 GMT):
It looks like it's approved by one - do you want me to set the review requirement for ursa to one review required for merging?

MALodder (Mon, 22 Jun 2020 20:54:49 GMT):
Let’s leave it at two for now

MALodder (Mon, 22 Jun 2020 20:54:57 GMT):
I got the one blocker merged

brentzundel (Mon, 22 Jun 2020 21:13:15 GMT):
I think two is good, even if it does slow things down sometimes.

rjones (Mon, 22 Jun 2020 21:59:35 GMT):
I rebased https://github.com/hyperledger/ursa/pull/125

MALodder (Tue, 23 Jun 2020 13:38:17 GMT):
@dhuseby @brentzundel @cam-parra can we get another reviewer on https://github.com/hyperledger/ursa/pull/104. This has been a standing PR for a while and we appreciate the effort he went through to maintain it until it finally could be merged

seriousmountain (Tue, 23 Jun 2020 13:53:02 GMT):
Has joined the channel.

brentzundel (Tue, 23 Jun 2020 15:21:08 GMT):
How are tasks/tickets/issues tracked for ursa? Is there a Jira instance we can use, should we use github issues?

swcurran (Tue, 23 Jun 2020 16:59:08 GMT):
+1 for github issues.

rjones (Tue, 23 Jun 2020 17:06:17 GMT):
if you want github issues, it's easy to turn on.

rjones (Tue, 23 Jun 2020 17:07:00 GMT):
@swcurran change [this line of code](https://github.com/hyperledger/ursa/blob/7e8ba24c7c907e3144a9192e963df7fa2346d8ef/.github/settings.yml#L11) and merge it

andrew.whitehead (Tue, 23 Jun 2020 17:52:13 GMT):
Is there a release version planned? I have a few things building from git right now

andrew.whitehead (Tue, 23 Jun 2020 17:52:13 GMT):
Is there a release version planned? I have a few things building from git right now that can't be published as crates

eduelias (Wed, 24 Jun 2020 13:00:34 GMT):
Has joined the channel.

eduelias (Wed, 24 Jun 2020 13:49:58 GMT):
Hi, does anyone have a working example of using WASM + NodeJS without weird "import" errors?

MALodder (Wed, 24 Jun 2020 14:22:00 GMT):
What are weird “import” errors

Dan (Wed, 24 Jun 2020 14:47:16 GMT):
https://chris.beams.io/posts/git-commit/

MALodder (Wed, 24 Jun 2020 15:05:49 GMT):
@eduelias its hard to help at the general level, can you be more specific

eduelias (Wed, 24 Jun 2020 15:46:23 GMT):
@MALodder I'm trying to call the module inside the pkg folder, generated by building libursa using wasm-pack. But when I try to use it on Nodejs I get a lot of import issues (because it's clear that this pkg is not for nodejs) and, when I try to import it on my Front-end project, it has some loading issues with CORS and other stuff so, what I need, is an example on how you guys are using it to start. My final goal is to extract the CL signature and generate CLAIM_DEF transactions using a browser.

MALodder (Wed, 24 Jun 2020 15:47:01 GMT):
I have done this in the past, I'll see if I can find where and how I did that

eduelias (Wed, 24 Jun 2020 15:47:17 GMT):
I am not that familiar with WASM, but quite experienced with nodejs/javascript.

MALodder (Wed, 24 Jun 2020 17:32:47 GMT):
if you just want nodejs, this project might help

MALodder (Wed, 24 Jun 2020 17:33:04 GMT):
https://github.com/mattrglobal/node-bbs-signatures/

Dan (Thu, 25 Jun 2020 16:24:54 GMT):
I think someone gave a presentation on sha3 last year? I recall seeing slides that explained the sponge construction better than what I'd seen elsewhere (or it could have been the presenter just describing it better). Do we have that retained somewhere? Possibly it was one of the chaps from Dfinity. Anyone know what I'm talking about?

hartm (Thu, 25 Jun 2020 18:07:09 GMT):
I don't remember this, but it's entirely possible that it happened.

Dan (Thu, 25 Jun 2020 18:08:08 GMT):
It was the same meeting where you agreed you owed me that money.

Dan (Thu, 25 Jun 2020 18:09:52 GMT):
Actually, maybe it was a presentation on the new hash algorithm (we adopted? planned to adopt?) and that algorithm might have also used the sponge construction. I'm just filled with useful details here.

rjones (Thu, 25 Jun 2020 18:21:13 GMT):
I thought you both owed me like 200 BTC? Wallet address forthcoming, thanks.

Dan (Thu, 25 Jun 2020 18:22:59 GMT):
I don't think i even own 20 british tea crumpets.

rjones (Thu, 25 Jun 2020 18:23:28 GMT):
slacker.

hartm (Thu, 25 Jun 2020 19:52:04 GMT):
It could have been on the Poseidon hash function, and it would make sense that Dmitry gave that talk. So you're information is consistent!

hartm (Thu, 25 Jun 2020 19:52:14 GMT):
Why are you interested in sponge hash constructions?

Dan (Thu, 25 Jun 2020 21:16:55 GMT):
Because the other constructions seem so dry.

Dan (Thu, 25 Jun 2020 21:17:07 GMT):

rjones (Thu, 25 Jun 2020 21:17:22 GMT):
_reaches for the `rename Dan` buttong_

rjones (Thu, 25 Jun 2020 21:17:22 GMT):
_reaches for the `rename Dan` button`**

madiazp (Fri, 26 Jun 2020 07:15:36 GMT):
Hi, is there a gadget of digital signatures for bulletproofs?

MALodder (Mon, 29 Jun 2020 04:48:21 GMT):
Like verifying a signature with Bulletproofs?

S3bb1 (Tue, 30 Jun 2020 12:19:15 GMT):
Hi all, when will the next version of libursa released on crates.io? Because when looking at crates.io the last released version is 0.3.2 but when looking at the cargo.toml in libursa it points to 0.3.4

madiazp (Wed, 01 Jul 2020 01:45:31 GMT):
yeah, something like proof he knowledge of a digital signature and it corresponding public key such that the hash of the public key belongs to a certain list or something like that, both pk and signature are witness.

madiazp (Wed, 01 Jul 2020 01:47:16 GMT):
the part of hash and list are covered with posseidon and membership of a list gadgets, but there is no schema to verify a digital siganture

MALodder (Wed, 01 Jul 2020 01:48:00 GMT):
that's not implemented yet, and the only thing I'm aware of is JubJub from ZCash

MALodder (Wed, 01 Jul 2020 01:48:26 GMT):
If you want proof of knowledge of a signature, we have BBS+ or PS signatures that can do that without gadgets

madiazp (Wed, 01 Jul 2020 01:56:24 GMT):
so, is the jubjub (or babyjubjub ) curve bulletproof friendly? like the same way they are to zk snark? I'm truly interested in a implementation of the eddsa protocol based on jubjub for bulletproof.

MALodder (Wed, 01 Jul 2020 01:57:25 GMT):
That's how zcash works. Its a SNARK that does two checks, is the UTXO in the set of spendable txns and is the signature valid

MALodder (Wed, 01 Jul 2020 01:57:43 GMT):
@brentzundel has studied it more than I have

madiazp (Wed, 01 Jul 2020 03:24:46 GMT):
yeah, that's why I'm interested, I've a rust implementation (need a lot of test and validations) of the eddsa protocol over the babyjubjub curve based on the work of ethsnark people https://github.com/HarryR/ethsnarks/blob/master/ethsnarks/eddsa.py. If the curve and its arithmetics operations are friendly to bulletproofs (the (scalar,Point) product ) I will more than happy to *try* to impement the verification of a signature for bulletproof. The thing is that I don't want to try to implement it and in the end come out with a proof that took like 10 minutes to be produced or verified. because eddsa is really heavy in terms of arithmetic gates. So the question is: It is heavy for bulletproof do elliptic curve arithmetic?

MALodder (Wed, 01 Jul 2020 03:32:30 GMT):
Yes it is

madiazp (Wed, 01 Jul 2020 03:32:59 GMT):
nice! thanks, I'll try to do my best

MALodder (Wed, 01 Jul 2020 03:33:50 GMT):
What’s the use case? Do you have to apply it? Curve25519 is friendly young bulletproofs

MALodder (Wed, 01 Jul 2020 03:34:08 GMT):
Ursa has implemented Bulletproofs over BLS12-381

madiazp (Wed, 01 Jul 2020 03:40:57 GMT):
Yeah but I don't only need a signature proof, I need to proof that someone has a valid pubkey and valid signature of public message (both wotness), proof that the hash of say public key belongs to a merkle tree by match a public merkle root with the array of path (all the path are witness), and proof that the hash of that signatures is a valid nullifier (in order to "burn" the credential once the proof is published)

madiazp (Wed, 01 Jul 2020 03:40:57 GMT):
Yeah but I don't only need a signature proof, I need to proof that someone has a valid pubkey and valid signature of public message (both witness), proof that the hash of say public key belongs to a merkle tree by match a public merkle root with the array of path (all the path are witness), and proof that the hash of that signatures is a valid nullifier (in order to "burn" the credential once the proof is published)

madiazp (Wed, 01 Jul 2020 03:40:57 GMT):
Yeah but I don't only need a signature proof, I need to proof that someone has a valid pubkey and valid signature of public message (both witness), proof that the hash of say public key belongs to a merkle tree by re-building a public merkle root with the array of path (all the path are witness), and proof that the hash of that signatures is a valid nullifier (in order to "burn" the credential once the proof is published)

madiazp (Wed, 01 Jul 2020 03:40:57 GMT):
Yeah but I don't only need a signature proof, I need to prove that someone has a valid pubkey and valid signature of public message (both witness), proof that the hash of say public key belongs to a merkle tree by re-building a public merkle root with the array of path (all the path are witness), and proof that the hash of that signatures is a valid nullifier (in order to "burn" the credential once the proof is published)

madiazp (Wed, 01 Jul 2020 03:40:57 GMT):
Yeah but I don't only need a signature proof, I need to prove that someone has a valid pubkey and valid signature of public message (both witness), prove that the hash of say public key belongs to a merkle tree by re-building a public merkle root with the array of path (all the path are witness), and prove that the hash of that signatures is a valid nullifier (in order to "burn" the credential once the proof is published)

madiazp (Wed, 01 Jul 2020 03:46:20 GMT):
So I have to combine all those constrains in a single proof, that's why I can't use only a signature proof

madiazp (Wed, 01 Jul 2020 03:52:46 GMT):
So of all curves which would you say is the most efficient(ish) in bulletproofs?

MALodder (Wed, 01 Jul 2020 04:01:30 GMT):
Curve25519 for now but zcash just came up with two new curves tweedledum and tweedledee

madiazp (Wed, 01 Jul 2020 04:02:12 GMT):
ok! will check them out

madiazp (Wed, 01 Jul 2020 04:03:41 GMT):
thanks

rjones (Wed, 01 Jul 2020 05:50:09 GMT):
@S3bb1 when I look here, I don't see releases for 0.3.3 or 0.3.4: https://github.com/hyperledger/ursa/releases

S3bb1 (Wed, 01 Jul 2020 05:53:19 GMT):
@rjones jup, but in the cargo.toml the version is stated to 0.3.4 https://github.com/hyperledger/ursa/blob/master/libursa/Cargo.toml#L3

MALodder (Wed, 01 Jul 2020 14:05:21 GMT):
@rjones are you talking about binaries?

MALodder (Wed, 01 Jul 2020 14:05:51 GMT):
ursa releases to crates.io

MALodder (Wed, 01 Jul 2020 14:24:45 GMT):
in case your interested https://www.rand.orgg/pubs/research_reports/RR4418.html

MALodder (Wed, 01 Jul 2020 14:24:45 GMT):
in case your interested https://www.rand.org/pubs/research_reports/RR4418.html

rjones (Wed, 01 Jul 2020 16:13:06 GMT):
@MALodder right - @S3bb1 is saying there are versions that are not published to crates.io; I'm saying they don't exist, or weren't released.

AnneGoellnitz (Thu, 02 Jul 2020 08:33:38 GMT):
Has joined the channel.

MALodder (Fri, 03 Jul 2020 15:07:05 GMT):
Correct we want to release 0.3.4 but I need one more approval for the PR then we’ll be good

assit (Sat, 04 Jul 2020 04:51:00 GMT):
Has joined the channel.

assit (Sat, 04 Jul 2020 18:38:20 GMT):
Hello! I hope that you are all doing well during these unprecedented times. My name is Tareq Assi and I am a finance student at McMaster University. I am self-taught in various programming languages and hardware development tools. With the need to learn more about blockchain technology, I want to contribute to the URSA project. As I am relatively new to blockchain technology, I find that the best way to learn new topics is by diving in and doing as much work as possible. If there is anything I can do to help you all with strategy management and project management, please let me know. I want to contribute as much as possible. May it be project management or brief blockchain research, I want to help. Linkedin: https://www.linkedin.com/in/tareq-assi

S3bb1 (Mon, 06 Jul 2020 08:50:02 GMT):
Thx for the information! Do you have a rough ETA on this release?

airskipper (Mon, 06 Jul 2020 12:48:16 GMT):
Has joined the channel.

Dan (Tue, 07 Jul 2020 14:43:01 GMT):
@MALodder I gather you got the PR approval you were looking for (regarding v0.3.4)? I don't see any open PRs.

MALodder (Tue, 07 Jul 2020 15:02:53 GMT):
Yes. I’ll get to it when my internet is better

Dan (Tue, 07 Jul 2020 15:05:07 GMT):
Just pour some draino into the intertubes.

MALodder (Tue, 07 Jul 2020 16:30:48 GMT):
done

MALodder (Tue, 07 Jul 2020 16:30:55 GMT):
v0.3.4 is release

MALodder (Tue, 07 Jul 2020 16:30:55 GMT):
v0.3.4 is released

MALodder (Tue, 07 Jul 2020 16:34:51 GMT):
bbs v0.4.1 is released

S3bb1 (Wed, 08 Jul 2020 14:15:09 GMT):
@Dan thanks for the release, we're using ursa with wasm, but the whole wasm folder is missing in the 0.3.4 release

hartm (Wed, 08 Jul 2020 14:17:33 GMT):
Crypto problems most likely have to fall in NP intersect coNP, which is even a much stronger restriction than being in NP.

hartm (Wed, 08 Jul 2020 14:35:39 GMT):
https://theory.cs.princeton.edu/complexity/

hartm (Wed, 08 Jul 2020 14:36:14 GMT):
(The above is a good primer on complexity, including circuit SAT).

alexx (Wed, 08 Jul 2020 15:41:21 GMT):
Here's the notes of today's sharing, if anyone is interested: https://drive.google.com/file/d/1CK7FREfY9ly0ySiHgkQFVQqy6BpvTPJa/view?usp=sharing It's more of a hodgepodge of my exploration rather really only on GS proof. Big thanks all who joined the call. I feel slightly contrite that I didn't present in a more fluent and didn't articulate many concepts very clearly and drag some of you for too long (haha). I shall be better next time (if there is one) and trial run myself before. In any case, feel free to ping me for further clarification or follow up questions. thanks :blush:

alexx (Wed, 08 Jul 2020 15:41:21 GMT):
Here's the notes of today's sharing, if anyone is interested: https://drive.google.com/file/d/1CK7FREfY9ly0ySiHgkQFVQqy6BpvTPJa/view?usp=sharing It's more of a hodgepodge of my exploration rather really only on GS proof. Big thanks all who joined the call. I feel slightly contrite that I didn't present in a more fluent way and didn't articulate many concepts very clearly and drag some of you for too long (haha). I shall be better next time (if there is one) and trial run myself before. In any case, feel free to ping me for further clarification or follow up questions. thanks :blush:

alexx (Wed, 08 Jul 2020 15:41:21 GMT):
Here's the notes of today's sharing, if anyone is interested: https://drive.google.com/file/d/1CK7FREfY9ly0ySiHgkQFVQqy6BpvTPJa/view?usp=sharing It's more of a hodgepodge of my exploration rather really only on GS proof. Big thanks all who joined the call. I feel slightly contrite that I didn't present more fluently and didn't articulate many concepts very clearly and drag some of you for too long (haha). I shall be better next time (if there is one) and trial run myself before. In any case, feel free to ping me for further clarification or follow up questions. thanks :blush:

alexx (Wed, 08 Jul 2020 15:41:21 GMT):
Here's the notes of today's sharing, if anyone is interested: https://drive.google.com/file/d/1CK7FREfY9ly0ySiHgkQFVQqy6BpvTPJa/view?usp=sharing It's more of a hodgepodge of my exploration rather really only on GS proof. Big thanks all who joined the call. I feel slightly contrite that I didn't present more fluently and didn't articulate many concepts very clearly and drag some of you for too long (haha). I shall be better next time (if there is one) and trial run myself beforehand. In any case, feel free to ping me for further clarification or follow up questions. thanks :blush:

hartm (Wed, 08 Jul 2020 16:33:53 GMT):
Thanks for the talk Alex!

MALodder (Wed, 08 Jul 2020 18:24:17 GMT):
we didn't delete the folder

MALodder (Wed, 08 Jul 2020 18:24:43 GMT):
its there https://github.com/hyperledger/ursa/tree/master/libursa/src/wasm

andrew.whitehead (Wed, 08 Jul 2020 18:32:14 GMT):
Looks like it might need to be added to includes in cargo.toml?

swcurran (Wed, 08 Jul 2020 21:38:52 GMT):
I'm not a crypto person but I did click on the doc above and loved the style :-)

S3bb1 (Thu, 09 Jul 2020 05:21:27 GMT):
[ ](https://chat.hyperledger.org/channel/ursa?msg=Y9JDTXW6hmYmRqEKS) but in the released version on crates.io it is not published

MALodder (Thu, 09 Jul 2020 13:34:05 GMT):
https://eprint.iacr.org/2020/823.pdf

MALodder (Thu, 09 Jul 2020 13:34:13 GMT):
good news for those of us that use Ed25519

MALodder (Thu, 09 Jul 2020 13:34:28 GMT):
Which part of WASM do you need

MALodder (Thu, 09 Jul 2020 13:34:35 GMT):
I'll start taking a look

S3bb1 (Thu, 09 Jul 2020 13:35:13 GMT):
wer're using the "portable_wasm" feature

MALodder (Thu, 09 Jul 2020 13:35:30 GMT):
for which crypto primitives?

MALodder (Thu, 09 Jul 2020 13:35:35 GMT):
ed25519? secp256k1?

MALodder (Thu, 09 Jul 2020 13:35:39 GMT):
CL signatures?

S3bb1 (Thu, 09 Jul 2020 13:36:58 GMT):
in our cargo.toml is the following referenced: ursa = { version = "0.3.4", features=["portable_wasm"], default-features = false } this results in the build with the following error: error[E0583]: file not found for module `wasm` --> /Users/sebastiandechant/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.4/src/lib.rs:203:1 | 203 | pub mod wasm; | ^^^^^^^^^^^^^ | = help: to create the module `wasm`, create file "/Users/sebastiandechant/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.3.4/src/wasm.rs"

S3bb1 (Thu, 09 Jul 2020 13:38:17 GMT):
and in docs.rs the folder is missing: https://docs.rs/crate/ursa/0.3.4/source/src/

MALodder (Thu, 09 Jul 2020 13:46:47 GMT):
found the error

MALodder (Thu, 09 Jul 2020 13:46:48 GMT):
https://github.com/hyperledger/ursa/pull/132

MALodder (Thu, 09 Jul 2020 13:47:09 GMT):
Can I this PR reviewed? https://github.com/hyperledger/ursa/pull/132

MALodder (Thu, 09 Jul 2020 13:47:22 GMT):
its small so it should be quick

S3bb1 (Thu, 09 Jul 2020 13:48:11 GMT):
thank you!!! :)

MALodder (Thu, 09 Jul 2020 13:48:33 GMT):
good catch

S3bb1 (Thu, 09 Jul 2020 13:51:45 GMT):
no problem, thanks for the fast response

MALodder (Thu, 09 Jul 2020 13:52:31 GMT):
the error occurred when we revamped the deployment to shrink the package

JelleFm (Fri, 10 Jul 2020 11:35:40 GMT):
Has joined the channel.

MALodder (Fri, 10 Jul 2020 14:10:09 GMT):
@rjones can you trigger appveyor to run again for https://github.com/hyperledger/ursa/pull/132

MALodder (Fri, 10 Jul 2020 14:10:17 GMT):
there's no reason it should've failed

MALodder (Fri, 10 Jul 2020 14:10:26 GMT):
I just ran it manually in appveyor and it succeeded

rjones (Fri, 10 Jul 2020 18:08:13 GMT):
@MALodder done

rjones (Fri, 10 Jul 2020 18:09:42 GMT):
I can't figure out how to delegate permission in the appveyor interface, but I'll keep looking

rjones (Fri, 10 Jul 2020 18:38:47 GMT):
@MALodder could you look at appveyor when logged in using GitHub? I think your team should have permissions to run builds, etc now without my intervention

MALodder (Fri, 10 Jul 2020 19:04:01 GMT):
Will do

MALodder (Sat, 11 Jul 2020 02:12:35 GMT):
https://eprint.iacr.org/2017/043.pdf

MALodder (Sat, 11 Jul 2020 02:13:12 GMT):
Interesting paper ^^ that uses CL-RSA signatures with range proofs to implement a revocation accumulator

alexx (Tue, 14 Jul 2020 03:55:00 GMT):
update on groups of unknown order with hyperelliptic curve by Galbraith: https://twitter.com/EllipticKiwi/status/1276301663406448640?s=20

hartm (Tue, 14 Jul 2020 15:08:18 GMT):
Yep! @MALodder and I were talking about this yesterday!

MALodder (Tue, 14 Jul 2020 15:26:18 GMT):
yep the paper is here

MALodder (Tue, 14 Jul 2020 15:26:19 GMT):
https://eprint.iacr.org/2020/196.pdf

Madhava 16 (Fri, 17 Jul 2020 04:20:59 GMT):
Has joined the channel.

Madhava 16 (Fri, 17 Jul 2020 04:20:59 GMT):
Hi all! :)

Madhava 16 (Fri, 17 Jul 2020 04:21:45 GMT):
I am looking at doing some Ares stuff and wanted to know about integrating the ursa rust code base into our rust code.

Madhava 16 (Fri, 17 Jul 2020 04:27:19 GMT):
I am just trying to understand the layers of indirection starting with this: https://github.com/hyperledger/aries-cloudagent-python it seems it utilises this: https://github.com/hyperledger/indy-sdk which in turn depends on ursa and other packages

Madhava 16 (Fri, 17 Jul 2020 04:28:22 GMT):
To ensure we can implement some kind of SSI / DIDComm in our code, would the indy-sdk make the most sense? Or do we need to implement stuff inside ursa directly?

PatrikStas (Fri, 17 Jul 2020 10:56:15 GMT):
@Madhava 16 yes IndySDK is the right place to build on top of. Especially if you working in rust. You might also find useful some of the code inside libvcx https://github.com/hyperledger/indy-sdk/tree/master/vcx/libvcx as that's basically rust implementation of Aries / didcomm, but beware there's lots of legacy non-didcomm non-aries code in it.

MALodder (Fri, 17 Jul 2020 18:58:21 GMT):
https://eprint.iacr.org/2020/735 - Bulletproofs+ TL;DR 85% Shorter proofs than Bulletproofs

MALodder (Fri, 17 Jul 2020 18:58:34 GMT):
only 576 bytes

hamidm (Sat, 18 Jul 2020 00:54:56 GMT):
Has joined the channel.

hamidm (Sat, 18 Jul 2020 00:56:59 GMT):
Hello, is there ursa wrappers for Dotnet ? Thanks

hamidm (Sat, 18 Jul 2020 00:56:59 GMT):
Hello, are there ursa wrappers for Dotnet ? Thanks

MALodder (Sat, 18 Jul 2020 01:53:57 GMT):
for the whole thing? no

MALodder (Sat, 18 Jul 2020 01:54:03 GMT):
for BBS+ there is

MALodder (Tue, 21 Jul 2020 16:11:00 GMT):
For the call tomorrow, I'd like to discuss changing the current RFCs to FCP since no feedback has been given in weeks for many of them

brentzundel (Wed, 22 Jul 2020 13:59:05 GMT):
I'll be joining 5 minutes late

brentzundel (Wed, 22 Jul 2020 14:54:17 GMT):
https://github.com/scoir/canis

brentzundel (Wed, 22 Jul 2020 15:08:19 GMT):
somewhere in the project above is GO wrapping ursa, iiuc

swcurran (Wed, 22 Jul 2020 16:36:46 GMT):
Any progress on revocation to report from the meeting today? Work done on that?

MALodder (Wed, 22 Jul 2020 21:56:18 GMT):
PQ Round 3 candidates https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/0ieuPB-b8eg/m/Cl7Ji8TpCwAJ?pli=1

ashlinSajan (Mon, 27 Jul 2020 06:18:24 GMT):
Has joined the channel.

eadventurous (Wed, 29 Jul 2020 15:25:50 GMT):
Has joined the channel.

eadventurous (Wed, 29 Jul 2020 15:25:50 GMT):
I have found ursa docs repository https://github.com/hyperledger/ursa-docs and there it is mentioned that ursa has an mdbook, though I can't find a link to it. Can someone give me the link? Also what is the best place to read ursa documentation is it https://docs.rs/ursa/0.3.4/ursa/ ?

eadventurous (Wed, 29 Jul 2020 15:54:09 GMT):
A bit more code specific question: why is `ursa::signatures::SignatureScheme` only implemented for ed25519 and secp256k1 but not for bls or cl?

eadventurous (Wed, 29 Jul 2020 15:54:58 GMT):
I thought this trait was used to abstract away the actual algorithm, so it would be logical to implement it for all of the algorithms

MALodder (Wed, 29 Jul 2020 20:40:52 GMT):
We’ll add it for BLS, however BLS and CL are more advanced signatures

MALodder (Wed, 29 Jul 2020 20:41:20 GMT):
BLS supports aggregation and two variants of the schemes

MALodder (Wed, 29 Jul 2020 20:41:41 GMT):
CL is largely for ZKP based signatures

brentzundel (Wed, 29 Jul 2020 20:53:43 GMT):
@hartm any recommendations for Crypto 2020 talks we shouldn't miss?

hartm (Wed, 29 Jul 2020 21:09:42 GMT):
I haven't looked over the program in detail. But it looks like there should be an interesting ZKP section that most people here might want to watch.

MALodder (Fri, 31 Jul 2020 17:21:27 GMT):
I'm planning to attend these ones Compressed Sigma-Protocol Theory and Practical Application to Plug & Play Secure Algorithmics A non-PCP Approach to Succinct Quantum-Safe Zero-Knowledge Round-optimal Black-box Commit-and-prove with Succinct Communication The MALICIOUS Framework: Embedding Backdoors into Tweakable Block Ciphers New Techniques for Zero-Knowledge: Leveraging Inefficient Provers to Reduce Assumptions, Interaction, and Trust Fast and Secure Updatable Encryption MPC with Friends and Foes Shorter Non-Interactive Zero-Knowledge Arguments and ZAPs for Algebraic Languages The Memory-Tightness of Authenticated Encryption Efficient Constant-Round MPC with Identifiable Abort and Public Verifiability Always Have a Backup Plan: Fully Secure Synchronous MPC with Asynchronous Fallback Breaking the decisional Diffie-Hellman problem for class group actions using genus theory Lattice-Based Blind Signatures, Revisited Security Analysis and Improvements for the IETF MLS Standard for Group Messaging Spartan: Efficient and general-purpose zkSNARKs Fully Deniable Interactive Encryption Multiparty Generation of an RSA Modulus Non-Interactive Zero-Knowledge Arguments for QMA, with preprocessing

ashutosh_kumar (Fri, 31 Jul 2020 20:42:10 GMT):
can you/somebody give me the information about the conference ? Thanks in advance.

swcurran (Fri, 31 Jul 2020 22:29:59 GMT):
\

swcurran (Fri, 31 Jul 2020 22:34:06 GMT):
https://crypto.iacr.org/2020/

MALodder (Fri, 31 Jul 2020 23:38:39 GMT):
Added Shamir Secret Sharing to Ursa - https://github.com/hyperledger/ursa/pull/137

ashutosh_kumar (Sat, 01 Aug 2020 14:54:36 GMT):
Thanks a lot.

S3bb1 (Mon, 03 Aug 2020 09:07:57 GMT):
Hi @MALodder can you release the updated Version also on crates.io?

MALodder (Mon, 03 Aug 2020 15:41:24 GMT):
https://research.kudelskisecurity.com/2020/07/28/the-definitive-guide-to-modulo-bias-and-how-to-avoid-it/ A good read for those of us coding in Ursa

hartm (Mon, 03 Aug 2020 16:19:37 GMT):
I frequently ask/complain about that very thing in code!

brentzundel (Tue, 04 Aug 2020 20:07:11 GMT):
That meeting with Ann Lysyanskaya was fantastic. Regrests for tomorrow's Ursa meeting.

pschwarz (Tue, 04 Aug 2020 20:50:33 GMT):
Has left the channel.

S3bb1 (Wed, 05 Aug 2020 05:24:56 GMT):
Hi @MALodder can you release the version 0.3.5 of ursa on crates.io? thanks!

MALodder (Wed, 05 Aug 2020 12:10:08 GMT):
Will discuss in meeting tomorrow

alexx (Wed, 05 Aug 2020 14:16:52 GMT):
https://twitter.com/oleganza/status/1288384398090477568?s=20

MALodder (Wed, 05 Aug 2020 14:39:04 GMT):
https://www.cs.umd.edu/~gasarch/TOPICS/secretsharing/feldmanVSS.pdf

MALodder (Wed, 05 Aug 2020 14:45:12 GMT):
https://www.cs.cornell.edu/courses/cs754/2001fa/129.PDF

alexx (Wed, 05 Aug 2020 14:49:09 GMT):
this is slightly better print, no cut-off: https://link.springer.com/content/pdf/10.1007%2F3-540-46766-1_9.pdf

MALodder (Wed, 05 Aug 2020 14:49:29 GMT):
thanks alex

Dan (Sat, 08 Aug 2020 23:05:14 GMT):
More relevant article: https://www.theguardian.com/environment/2020/aug/07/bear-attack-advice-sacrificing-friends

rjones (Sun, 09 Aug 2020 00:09:26 GMT):
Is Ursa resistant to this attack?

hartm (Mon, 10 Aug 2020 01:18:32 GMT):
This is an excellent article that illustrates the importance of precise definitions. Note that it says you shouldn't push down "friends" to get eaten by bears to save yourself, but says nothing about "Dan Middletons." Thank you for the insightful example Dan! ;)

Dan (Mon, 10 Aug 2020 04:06:43 GMT):
:-P And I thought you were going to key in on the RFC2119 use of _should_

helloravi (Mon, 10 Aug 2020 14:28:04 GMT):
Has joined the channel.

helloravi (Mon, 10 Aug 2020 14:28:05 GMT):
Guys

helloravi (Mon, 10 Aug 2020 14:28:29 GMT):
Is there documentation on how I can use Ursa to transmit claims in a zero knowledge way?

RGold 1 (Mon, 10 Aug 2020 15:37:07 GMT):
Has joined the channel.

Dan (Mon, 10 Aug 2020 16:35:45 GMT):
Are you working with Indy/Aries? If so they probably have interfaces at the right abstraction level. Ursa is pretty low-level.

S3bb1 (Tue, 11 Aug 2020 06:52:03 GMT):
Hi @MALodder did you got feedback regarding the release?

S3bb1 (Wed, 12 Aug 2020 05:43:39 GMT):
Hi all, we're currently using ursa for ZKP Credentials and faced that the prime number generation is rather "slow" (also with the native openssl compilation) and takes from 10s to 1m 30s. There is the constant pub const LARGE_PRIME: usize = 1024; When setting this const to a lower one (e.g. 512 or 128) it gets faster (like normal because of shorter prime numbers). My question is, are these lower numbers still save and secure? Or which constant value you prefer

hartm (Wed, 12 Aug 2020 08:08:10 GMT):
If I'm not mistaken, this parameter chooses the prime size for the two primes used to generate the RSA modulus. I don't think anyone would recommend using less than a 2048 bit modulus for RSA, so I wouldn't touch those parameters.

JakeZ2020 (Wed, 12 Aug 2020 16:31:44 GMT):
Has joined the channel.

MALodder (Wed, 12 Aug 2020 17:49:55 GMT):
This is because it has to be safe primes which is much slower than just primes

MALodder (Wed, 12 Aug 2020 17:50:16 GMT):
as soon as the next PR is merged then I can cut the release

MALodder (Wed, 12 Aug 2020 17:51:07 GMT):
this is quite funny, why we chose Rust https://www.destroyallsoftware.com/talks/wat

hartm (Mon, 17 Aug 2020 19:52:24 GMT):
Interesting talk from Crypto: 1024 bit range proof using lattices (post-quantum) in 31kb.

Dan (Wed, 19 Aug 2020 14:11:24 GMT):
link?

rjones (Wed, 19 Aug 2020 15:31:10 GMT):
http://vignette4.wikia.nocookie.net/p__/images/9/9d/Link_Artwork_1_(Twilight_Princess).png/revision/latest?cb=20160705025744&path-prefix=protagonist

rjones (Wed, 19 Aug 2020 15:31:58 GMT):

Link.png

hartm (Wed, 19 Aug 2020 15:48:43 GMT):
https://link.springer.com/chapter/10.1007%2F978-3-030-56880-1_17

davidkhala (Thu, 20 Aug 2020 06:06:41 GMT):
Has joined the channel.

davidkhala (Thu, 20 Aug 2020 06:08:39 GMT):
Hi ursa community. I try to play with C API and find https://github.com/hyperledger/ursa#libursa-documentation libursa C API documentation link go to rust source folders still. Did I go to a wrong way?

MALodder (Sat, 22 Aug 2020 03:27:38 GMT):
Look for the ffi folder

MALodder (Sat, 22 Aug 2020 03:27:45 GMT):
That’s where the code is

MALodder (Sat, 22 Aug 2020 03:28:18 GMT):
Also try this

MALodder (Sat, 22 Aug 2020 03:28:21 GMT):
https://github.com/mikelodder7/ffi-bbs-signatures

jcldnatv (Sat, 22 Aug 2020 17:30:51 GMT):
Has joined the channel.

avi23 (Tue, 25 Aug 2020 16:50:17 GMT):
Has joined the channel.

avi23 (Tue, 25 Aug 2020 16:51:13 GMT):
Hi All , can anyone please share some inputs and reference repo links on how to implement ZK-SNARK in Indy thru Ursa? just wondering if this has been achieved before in any Indy project?

SamB (Wed, 26 Aug 2020 01:48:30 GMT):
Has joined the channel.

MALodder (Wed, 26 Aug 2020 03:25:26 GMT):
Ursa doesn’t have any snarks but does have Bulletproofs

SuperSeiyan (Wed, 26 Aug 2020 03:42:50 GMT):
Has joined the channel.

thearhaam (Wed, 26 Aug 2020 05:29:49 GMT):
Has joined the channel.

MALodder (Wed, 26 Aug 2020 12:30:07 GMT):
The problem with snarks is which system to use? use? Spartan, Halo, Hyrax, Libra, Sonic, Plonk, Marlin… Each one has tradeoffs between trusted setups, proof size, bilinear pairings or other elliptic curves, proof generation and generation time. SNARKS are not the only circuit based systems that can be used. Bulletproofs, Bulletproofs+, STARKS, SNARGS… the list goes on but there is no clear winner

MALodder (Wed, 26 Aug 2020 12:30:07 GMT):
The problem with snarks is which system to use? Spartan, Halo, Hyrax, Libra, Sonic, Plonk, Marlin… Each one has tradeoffs between trusted setups, proof size, bilinear pairings or other elliptic curves, proof generation and generation time. SNARKS are not the only circuit based systems that can be used. Bulletproofs, Bulletproofs+, STARKS, SNARGS… the list goes on but there is no clear winner

MALodder (Wed, 26 Aug 2020 12:30:32 GMT):
We’re watching them to see which one emerges as a clear winner

MALodder (Wed, 26 Aug 2020 12:30:32 GMT):
We’re watching them to see which one emerges as a clear winner or winners

avi23 (Wed, 26 Aug 2020 12:36:47 GMT):
@MALodder is there any example repo to refer on implementation on bulletproofs in ursa? can we achieve the same functionality using bulletproofs which we achieve by zk-snark?

MALodder (Wed, 26 Aug 2020 12:38:10 GMT):
It depends on what you are trying to do with snarks. What’s the use case?

avi23 (Wed, 26 Aug 2020 12:57:11 GMT):
@MALodder my use case is to share certified data in anonymous mode where he/she does not wish to share all the data. For example, if the prover does not wish to share his salary however can answer to the query if salary is higher than the required amount that would solve the verifier’s purpose

avi23 (Wed, 26 Aug 2020 12:58:01 GMT):
or just to prove that user hold the signature without revealing the actual signature

MALodder (Wed, 26 Aug 2020 13:03:40 GMT):
We have the BBS signature for withholding the actual signature

MALodder (Wed, 26 Aug 2020 13:04:03 GMT):
Bulletproofs are perfect for range proofs

MALodder (Wed, 26 Aug 2020 13:04:15 GMT):
Smaller and faster than snarks for that

MALodder (Wed, 26 Aug 2020 13:05:24 GMT):
https://github.com/hyperledger/ursa/blob/master/libzmix/bulletproofs_amcl/src/r1cs/gadgets/bound_check.rs

MALodder (Wed, 26 Aug 2020 13:05:45 GMT):
Look at the test code here to see how to use Bulletproofs for range checking

MALodder (Wed, 26 Aug 2020 13:05:54 GMT):
From ursa

avi23 (Wed, 26 Aug 2020 14:56:55 GMT):
@MALodder so do you mean that Zk-snarks implementation is not supported in URSA?

MALodder (Wed, 26 Aug 2020 14:57:14 GMT):
we haven't implemented any SNARKs in ursa

MALodder (Wed, 26 Aug 2020 14:57:19 GMT):
so no

avi23 (Wed, 26 Aug 2020 14:59:56 GMT):
okay, so to achieve ZKP using URSA in Indy we can either use any of these Bulletproofs or BBS approach....right?

MALodder (Wed, 26 Aug 2020 15:00:48 GMT):
absolutely

MALodder (Wed, 26 Aug 2020 15:01:01 GMT):
people are too quick to reach for SNARKs when they shouldn't be

avi23 (Wed, 26 Aug 2020 15:04:11 GMT):
@MALodder okay, understood.. but is there any project on indy which has already used these method of BBS or Bulletproof using URSA?

MALodder (Wed, 26 Aug 2020 15:16:11 GMT):
yes there are

avi23 (Wed, 26 Aug 2020 15:17:23 GMT):
could you please give some reference of same, so that i can explore

MALodder (Wed, 26 Aug 2020 15:19:29 GMT):
Trinsic, MattrGlobal, Evernym are companies using them

MALodder (Wed, 26 Aug 2020 15:19:50 GMT):
@tplooker @tomislav and @brentzundel are who you could contact for that

avi23 (Wed, 26 Aug 2020 15:53:53 GMT):
@MALodder thank you, it would be great if you can share any GitHub repo for any of these projects who successfully implemented these

MALodder (Wed, 26 Aug 2020 15:54:15 GMT):
again ask those individuals

avi23 (Wed, 26 Aug 2020 16:06:21 GMT):
Okay sure, thanks

avi23 (Wed, 26 Aug 2020 16:14:37 GMT):
@tplooker @tomislav @brentzundel i am interested in exploring the ZKP using methods supported by URSA like bulletproofs and other , could you please share some repos where we have already implemented these ZKP techniques , so that i can get a good understanding

avi23 (Wed, 26 Aug 2020 16:43:37 GMT):
@tplooker @tomislav @brentzundel i am interested in exploring the ZKP using methods supported by URSA like bulletproofs and other , could you please share some repos where we have already implemented these ZKP techniques , so that i can get a good understanding

avi23 (Wed, 26 Aug 2020 17:08:21 GMT):
@MALodder i saw about that ZkP can be achieved in Indy using anoncreds that is mentioned in their official reference as well...

avi23 (Wed, 26 Aug 2020 17:09:21 GMT):
So wanted to understand that does Ursa have use of that?

avi23 (Wed, 26 Aug 2020 17:09:39 GMT):
It its totally different like any other techniques

tomislav (Wed, 26 Aug 2020 17:46:37 GMT):
Sure. I'm only aware of BBS implementations. An early version of BBS for JSON-LD can be found here: BBS for JSON-LD in .NET https://github.com/streetcred-id/ld-proofs-dotnet This is based on a BBS FFI wrapper now maintained at https://github.com/mattrglobal/ffi-bbs-signatures/. There are available wrappers for .NET and C, with Java coming in. For NodeJS environment, BBS sigs for JSON-LD https://github.com/mattrglobal/jsonld-signatures-bbs For example usage, I can point you to the unit tests in each repo, to see how these are used with practical LD documents

tomislav (Wed, 26 Aug 2020 17:46:37 GMT):
Sure. I'm only aware of BBS implementations. BBS for JSON-LD in .NET https://github.com/streetcred-id/ld-proofs-dotnet This is based on a BBS FFI wrapper now maintained at https://github.com/mattrglobal/ffi-bbs-signatures/. There are available wrappers for .NET and C, with Java coming in. For NodeJS environment, BBS sigs for JSON-LD https://github.com/mattrglobal/jsonld-signatures-bbs For example usage, I can point you to the unit tests in each repo, to see how these are used with practical LD documents

avi23 (Wed, 26 Aug 2020 18:04:09 GMT):
@tomislav thanks ! that would be a great help if you can share

brentzundel (Wed, 26 Aug 2020 19:34:46 GMT):
I don't know of anyone yet who is using bulletproofs from Ursa. Evernym is currently using the CL signatures for zkp credentials through Indy.

avi23 (Thu, 27 Aug 2020 03:55:59 GMT):
@brentzundel could you please give some reference repo of same?

avi23 (Thu, 27 Aug 2020 08:12:38 GMT):
@MALodder i saw about that ZkP can be achieved in Indy using anoncreds that is mentioned in their official reference as well... So wanted to understand that does Ursa have use of that? It its totally different like any other techniques

MALodder (Thu, 27 Aug 2020 12:45:47 GMT):
Ursa provides those yes

MALodder (Thu, 27 Aug 2020 12:46:13 GMT):
They are quite fast to do and small in size

brentzundel (Thu, 27 Aug 2020 13:59:21 GMT):
the high level API for using the credentials is here: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs

avi23 (Thu, 27 Aug 2020 14:28:04 GMT):
@MALodder any example repos of implementation

avi23 (Thu, 27 Aug 2020 14:30:11 GMT):
@MALodder could you please share any repo where this annoncreds has been implemented?

MALodder (Thu, 27 Aug 2020 14:30:34 GMT):
https://github.com/hyperledger/indy-sdk

avi23 (Thu, 27 Aug 2020 16:27:19 GMT):
@MALodder i am aware of this repo, but couldn't see any specific where we have used annoncreds to achieve zkp, is there any projects who have implemented it ?

MALodder (Thu, 27 Aug 2020 16:28:16 GMT):
if you look https://github.com/hyperledger/indy-sdk/tree/master/libindy/src/domain/anoncreds, the code is right there

avi23 (Thu, 27 Aug 2020 16:28:16 GMT):
@MALodder i am still not very clear, from i can start to use zkp in Indy, could you please help?

MALodder (Thu, 27 Aug 2020 16:28:55 GMT):
here another https://github.com/mikelodder7/ursa_demo/blob/master/src/main.rs

MALodder (Thu, 27 Aug 2020 16:29:18 GMT):
Lines 94-123

avi23 (Thu, 27 Aug 2020 16:31:34 GMT):
@MALodder thank you, let me take a look

avi23 (Thu, 27 Aug 2020 17:44:12 GMT):
thank you @brentzundel , let me check this

MALodder (Fri, 28 Aug 2020 17:09:50 GMT):
good read for any ursa developers: https://soatok.blog/2020/08/27/soatoks-guide-to-side-channel-attacks/

MALodder (Wed, 02 Sep 2020 14:32:14 GMT):
https://eprint.iacr.org/2005/123

MALodder (Wed, 02 Sep 2020 15:08:48 GMT):
https://github.com/hyperledger/ursa/pull/142

hartm (Wed, 02 Sep 2020 23:52:58 GMT):
@here I posted a draft quarterly report. Please feel free to edit if you like! Thanks!

MALodder (Thu, 03 Sep 2020 17:02:34 GMT):
thanks @hart I made some updates

chakshujain (Sun, 06 Sep 2020 14:37:24 GMT):
Has joined the channel.

ashlinSajan (Mon, 07 Sep 2020 09:44:31 GMT):
Hi @MALodder @tomislav @tplooker Other than Hyperledger Indy and Aries, Is Hyperledger Ursa integration with other platforms like fabric released officially?

MALodder (Mon, 07 Sep 2020 15:35:58 GMT):
Transact is one that uses it

paul.bastian (Tue, 08 Sep 2020 11:40:52 GMT):
Has joined the channel.

AryamaI (Tue, 08 Sep 2020 15:41:53 GMT):
Has joined the channel.

jcldnatv (Fri, 11 Sep 2020 01:07:39 GMT):
So I will use transact in order to get ursa? Am I right?

MALodder (Fri, 11 Sep 2020 01:08:58 GMT):
No you can use Ursa directly

jcldnatv (Fri, 11 Sep 2020 01:16:09 GMT):
thank you that was quick. any example?

MALodder (Fri, 11 Sep 2020 01:41:08 GMT):
Here’s one https://github.com/hyperledger/ursa/tree/master/libzmix/bbs

MALodder (Fri, 11 Sep 2020 01:43:03 GMT):
https://github.com/mikelodder7/ursa_demo

davidkhala (Mon, 14 Sep 2020 01:24:40 GMT):
Hi Mike, is it the answer to me C API quesion?

AryamaI (Tue, 15 Sep 2020 10:24:40 GMT):
Hello Everyone, I am trying to understand briefly how User/holder anonymity is maintained at the time of credential verification. I see that holder's wallet data is encrypted by a master key. So, is there any api that allows a user to know his wallet master key? As a response to the proof of request, I see a master_secret value in the API Response sent by the holder, what is it.?In the AliceFaber example I see that some attribute values are revealed like name, degree at the point of verification. Only the age is kept hidden based on the predicate. So, cant we ensure a complete anonymity by even hiding the other fields. So, how does user anonymity works in here and similarly , what is the prurpose of master key used for encrypting the wallet, in brief? Kindly help me understand these points. Any help is appreciated, thank you.

AryamaI (Tue, 15 Sep 2020 10:24:40 GMT):
Hello Everyone, I am trying to understand briefly how User/holder anonymity is maintained at the time of credential verification. I see that holder's wallet data is encrypted by a master key. So, is there any API that allows a user to know his wallet master key? As a response to the proof of request, I see a master_secret value in the API Response sent by the holder, what is it.? In the AliceFaber example, I see that some attribute values are revealed like name, degree at the point of verification. Only the age is kept hidden based on the predicate. So, cant we ensure complete anonymity by even hiding the other fields. Also, from my understanding, all encryption works internally work using URSA, but do we still need to do any extra enablement when running the ALiceFaberDemo for master key or anything? I haven't done anything differently. So, how does user anonymity works in here, and similarly, what is the purpose of the master key used for encrypting the wallet, in brief? Kindly help me understand these points. Any help is appreciated, thank you.

tarkochevamik (Tue, 15 Sep 2020 19:25:18 GMT):
Has joined the channel.

hartm (Wed, 16 Sep 2020 02:04:37 GMT):
@here Just a reminder for tomorrow's meeting. Please add items to the agenda as you see fit.

the_identity_guy (Wed, 16 Sep 2020 03:35:05 GMT):
Hello Ursa team! Is there any solution/open source platform that has implemented a full cycle (issue, manage, verify and revoke) support of zero knowledge proof claims using verifiable credentials? Is there any article/link for that?

JonGeater (Wed, 16 Sep 2020 10:58:49 GMT):
That's possibly a better questiion for the

JonGeater (Wed, 16 Sep 2020 10:58:49 GMT):
That's possibly a better question for the Indy channel. Folks here happen to know about ZKPs and SSI but you'll find more project/business type people (who deal in use cases and case studies more broadly than just crypto) over in the Indy channel

Dan (Wed, 16 Sep 2020 14:31:39 GMT):
wrapper rfc: https://github.com/hyperledger/ursa-rfcs/tree/master/text/language-bindings

m00sey (Wed, 16 Sep 2020 15:13:24 GMT):
Has joined the channel.

tarkochevamik (Wed, 16 Sep 2020 15:15:07 GMT):
Hello! Per the Ursa call, we'd like to be added as maintainers of the ursa-wrapper-go repo, here are our github names: pfeairheller (Philip Feairheller) , m00sey (Kevin Griffin), and mikaelaTar (Mikaela Tarkocheva). As soon as we get access we will move our PR over and close the one against ursa. Thank you!

MALodder (Wed, 16 Sep 2020 16:12:26 GMT):
repo is up https://github.com/hyperledger/ursa-wrapper-go

rjones (Thu, 17 Sep 2020 15:27:46 GMT):
Hi, if you have anything you'd like to see added to the /dev/weekly newsletter, please comment in the next two hours: https://wiki.hyperledger.org/pages/viewpage.action?pageId=39618911

ianco (Fri, 18 Sep 2020 17:05:36 GMT):
Has joined the channel.

hcsatish (Sun, 20 Sep 2020 16:10:22 GMT):
Has joined the channel.

tarkochevamik (Mon, 21 Sep 2020 20:23:12 GMT):
Hey folks, thanks for making us code owners in https://github.com/hyperledger/ursa-wrapper-go, however none of us seem to have write access on ursa-wrapper-go. We were hoping to not impose the burden of the wrapper's PRs on this group.

Dan (Mon, 21 Sep 2020 20:31:14 GMT):
@rjones can you give them write on this repo? (it's same id's as for code owners + the ursa maintainers)

rjones (Mon, 21 Sep 2020 21:33:14 GMT):
@Dan done. @tarkochevamik I added two comments on your PR

rjones (Mon, 21 Sep 2020 21:39:21 GMT):
@tarkochevamik https://github.com/hyperledger/ursa-wrapper-go/pull/3 is ready to merge (I did a rebase/squash)

Dan (Tue, 22 Sep 2020 16:59:36 GMT):
Glad to see Ry and Brent engaged on that PR. I think for the first few PRs to make sure that community norms are understood it would be good for some of the existing ursa maintainers to be reviewing along with the principal but newer contributors for this go repo.

Dan (Tue, 22 Sep 2020 17:12:43 GMT):
I'd like to check my intuitive understanding of some of snark concepts so I'm going to try to use plain english rather than parroting technical terms. We want to show that we can create these proofs for general programs/algorithms. Consequently papers often started with binary circuits as those directly reflect what you can make with an electronic circuit, and because we are dealing in just individual bits, the proofs of correctness for the systems are easier to write. Dealing with individual bits is inefficient though so once you've shown the properties you want hold in a binary circuit it's good to show they hold in an arithmetic circuit (i.e. now I'm working with bigints instead of bits). Even that is not a super efficient way to encode statements so that gave rise to other constructions like QSPs and QAPs with the current state of the art focused on R1CS. I'll pause here before maybe digging into r1cs.

hartm (Tue, 22 Sep 2020 19:55:29 GMT):
Are you comfortable with circuit definitions? People like to use arithmetic circuits (and things that are built on them, like QAPs) because they are closer to cryptographic assumptions in that they work over large fields.

Dan (Tue, 22 Sep 2020 20:19:43 GMT):
I think I am, but probably don't know what I should be uncomfortable about in my knowledge :) I know what 3-sat is, and that an arithmetic circuit just lets you apply normal operations at each gate. The examples for snarky things generally use multiplication at each gate and collapse additions in to those multiplications.. possibly because their group operation is multiplication?

hartm (Tue, 22 Sep 2020 20:23:07 GMT):
Arithmetic circuits are defined over finite fields, with ADD gates and MULTIPLY gates.

hartm (Tue, 22 Sep 2020 20:23:23 GMT):
Is that what you meant by "normal" operations?

Dan (Tue, 22 Sep 2020 20:23:32 GMT):
yeah

hartm (Tue, 22 Sep 2020 20:24:47 GMT):
Many of the ZK things use pairings. Group multiplication == addition in the exponent, group exponentiation == multiplication in the exponent. To multiply in the exponent you need pairings.

Dan (Tue, 22 Sep 2020 20:24:48 GMT):
I guess instead of AND and OR in boolean circuits (with binary inputs) you have ADD and MULT (with finite field inputs).

hartm (Tue, 22 Sep 2020 20:24:53 GMT):
That's correct.

Dan (Tue, 22 Sep 2020 20:45:07 GMT):
Ok thanks. I set that up like I was going to go across the breadth of the snarks concept, but really just dialing into this encoding thing to go from circuits to r1cs before I try to dig some more on r1cs. At the moment I'm on an excursion into FHE and reading some of the Gentry stuff from 2009/2010.. the application of circuits there brought my mind back to their use in Snarks and this progression towards r1cs.

hartm (Tue, 22 Sep 2020 20:46:17 GMT):
What's gotten you into FHE? I would read the GSW paper if you want to understand FHE: https://eprint.iacr.org/2013/340

hartm (Tue, 22 Sep 2020 20:46:40 GMT):
It's much easier to understand why and how it works than with the earlier schemes, which need rings, modulus switching, or other complicated techniques.

Dan (Tue, 22 Sep 2020 20:50:11 GMT):
Someone wanted to assert that FHE did things that TEEs do and ... anyway there's some productive stuff with FHE so I'm trying to get a visceral sense of it. I started with the jewelry paper which is hilarious and accessible. I'm reading the FHE over the Integers 2010 paper right now. I wasn't aware of the GSW paper but thought this integers paper had a similar purpose... like you're probably not going to make this integer based system, but look how easy it is to understand! ;)

Dan (Tue, 22 Sep 2020 20:51:41 GMT):
I'm so underqualified to make any judgements, but it seems like using crazy big numbers to hide one bit and then a lot of corner case coverage to manage the cumulative noise.

hartm (Tue, 22 Sep 2020 20:51:42 GMT):
TEEs give you essentially VBB (virtual black-box obfuscation). FHE doesn't allow you to learn anything about the message encrypted in the ciphertext, which you really want to allow (selectively) for most TEE applications.

hartm (Tue, 22 Sep 2020 20:51:59 GMT):
Most people really want functional encryption when they mention FHE.

hartm (Tue, 22 Sep 2020 20:52:18 GMT):
Yeah, FHE schemes are very inefficient right now.

hartm (Tue, 22 Sep 2020 20:52:40 GMT):
The GSW paper is currently (I think) the simplest and cleanest construction.

Dan (Tue, 22 Sep 2020 20:53:42 GMT):
Cool thanks for that cite, I'll take a crack at that one tomorrow.

hartm (Tue, 22 Sep 2020 20:59:27 GMT):
Of course!

hartm (Tue, 22 Sep 2020 22:12:30 GMT):
Glad you are getting more into crypto stuff, by the way!

Dan (Thu, 24 Sep 2020 14:41:45 GMT):
do we need a new zoom link? I've started an agenda for next week. If there's a new zoom can someone add it there (and update the community calendar) https://wiki.hyperledger.org/display/ursa/2020-09-30+Meeting+Agenda

rjones (Thu, 24 Sep 2020 14:57:32 GMT):
@Dan yes, you will need a new one.

valesken (Thu, 24 Sep 2020 18:19:15 GMT):
Has joined the channel.

arsulegai (Sun, 27 Sep 2020 12:07:32 GMT):
Hello Ursa community from the Hyperledger India Chapter, we are calling for speakers to engage with the community in Asia Pacific, Europe and Africa. Please see our event details here https://www.linkedin.com/feed/update/urn:li:activity:6715897303481372672 Calling the tech enthusiasts, maintainers to be part of it.

manoranjith (Fri, 02 Oct 2020 06:23:41 GMT):
Has joined the channel.

dgt1nsty (Fri, 02 Oct 2020 13:54:43 GMT):
Has joined the channel.

mccown (Mon, 05 Oct 2020 23:05:12 GMT):
ecies

Sandeepk40 (Wed, 07 Oct 2020 04:26:37 GMT):
Has joined the channel.

mirgee (Mon, 12 Oct 2020 17:52:03 GMT):
Has joined the channel.

tosirisuk (Tue, 13 Oct 2020 16:05:05 GMT):
Has joined the channel.

tosirisuk (Tue, 13 Oct 2020 16:05:06 GMT):
Hi, I'm pretty new to the hyperledger/ursa. I'm interested in z-mix library and wonder how to import it to my proj. I'm a little confused with the README.md about how to use those compiled artifact(s) https://github.com/hyperledger/ursa#libzmix

tosirisuk (Tue, 13 Oct 2020 16:05:06 GMT):
Hi, I'm pretty new to the hyperledger/ursa. I'm interested in z-mix library and wonder how to import it to my project. I'm a little confused with the README.md about how to use those compiled artifact(s) e.g. use, mod, crate, etc. https://github.com/hyperledger/ursa#libzmix

tosirisuk (Tue, 13 Oct 2020 16:06:38 GMT):
I will appreciate if anyone could guide or hint me on this.

hartm (Wed, 14 Oct 2020 13:59:00 GMT):
In case you have the old calendar link: https://zoom.us/j/6223336701?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09

duuren (Wed, 14 Oct 2020 19:46:35 GMT):
Has joined the channel.

duuren (Wed, 14 Oct 2020 19:56:02 GMT):
Hi, I like to use Zero Knowledge proof capabilities with either Sawtooth or Iroha. Is it possible to do this with Ursa. I noticed that Iroha has already an option to install Libursa, but no mention on Libzmix. On Sawtooth I only read some old emails that there is an intention, but no concrete recent info.

tosirisuk (Mon, 19 Oct 2020 05:12:42 GMT):
I have this issue on this too. I spent about two weeks trying to find the way to use the `libzmix`, but no success yet.

MALodder (Mon, 19 Oct 2020 14:06:27 GMT):
libzmix is just a library like libursa

MALodder (Mon, 19 Oct 2020 14:07:02 GMT):
We are in the middle of migrating an FFI layer into zmix from an external project that will allow you to do this

MALodder (Mon, 19 Oct 2020 14:07:25 GMT):
if you don't want to wait you can find it here

MALodder (Mon, 19 Oct 2020 14:07:26 GMT):
https://github.com/mattrglobal/ffi-bbs-signatures

daidoji (Mon, 19 Oct 2020 14:09:26 GMT):
Has joined the channel.

tosirisuk (Mon, 19 Oct 2020 14:56:14 GMT):
Thanks for the information @MALodder. I'm just new to Rust and right know I don't quite understand how to use those compiled in my Rust project. libursa.so (Linux) libursa.dylib (Mac OS X) libursa.a (Linux, Mac OS X) libursa.dll (Windows) libursa.lib (Windows)

MALodder (Mon, 19 Oct 2020 14:56:50 GMT):
you just need the dynamic library portion

tosirisuk (Mon, 19 Oct 2020 14:57:59 GMT):
OK, will google for more detail on "dynamic library". Appreciate your guide

Dan (Mon, 19 Oct 2020 16:06:04 GMT):
When we talked about GS proofs a while back, modules came up. There was an observation about their relation to vector spaces (which is maybe only important to you if you are close to linear algebra). As I look at lattices, I want to connect these three. While there are different aspects you could look at across these structures, one progression is that the elements of each move from fields -> rings -> integers for vector spaces -> modules -> and lattices respectively. Also it's correct to think of a Lattice as a kind of Module and a Module as a kind of Vector space. Please disagree with me if you see errors here.

duuren (Tue, 20 Oct 2020 21:39:06 GMT):
Thanks, looking forward.

daidoji (Thu, 22 Oct 2020 19:48:24 GMT):
did you ever find out? I think a module is a generalization of a vector space like a vector space can be a generalization of an operation over a field but I could be wrong. Been a long time since I wore a mathematician hat. Am curious to learn what the answers to the other things you mentioned here were though.

Dan (Thu, 22 Oct 2020 21:55:04 GMT):
no one argued with me so that means I'm certainly correct ;) Seriously, though, i think those definitions are correct. I just hadn't seen them side by side before so I wanted to double check.

Dan (Thu, 22 Oct 2020 21:56:10 GMT):
There's a 'category' sort of relationship there that interests me though. And I use category loosely.

hartm (Fri, 23 Oct 2020 00:07:10 GMT):
Module is to ring as vector space is to field is the appropriate analogy.

hartm (Fri, 23 Oct 2020 00:07:25 GMT):
And yes, category theory is a whole field!

Dan (Fri, 23 Oct 2020 18:42:37 GMT):
pun ^

Dan (Fri, 23 Oct 2020 18:42:37 GMT):
pun detected ^

Dan (Fri, 23 Oct 2020 18:47:44 GMT):
So according to GPV and I read this somewhere else too tho I don't remember where now, for the Gram-Schmidt orthogonalized basis, each vector is "clearly" less than or equal to the original basis vector. And I'm fine with that, but I also read that Det(L) doesn't depend on choice of basis. But if you can have a basis with some shorter vectors wouldn't that imply a smaller volume?

hartm (Fri, 23 Oct 2020 18:52:35 GMT):
No! This would be easier to explain if I could draw. But think about the following: I could have a square with side length 1 ( and thus with area 1), or a parallelepiped defined by the vectors (1, 0) and (10, 1). This parallelepiped also has area 1, even though its sides are much longer (draw this out if this isn't clear). This is basically what's going on here, although in high dimension.

hartm (Fri, 23 Oct 2020 18:53:23 GMT):
Note that the lattice spanned by the vectors (1, 0) and (0, 1) is the same as that spanned by (1, 0) and (20, 1).

hartm (Fri, 23 Oct 2020 18:53:56 GMT):
The determinant is dependent on the lattice and independent of the basis.

Dan (Fri, 23 Oct 2020 18:55:12 GMT):
ohhhh. got it....

Dan (Fri, 23 Oct 2020 18:56:31 GMT):
I think with even smaller numbers if I have {(1,0), (1,1)} the orthoganalized basis would be ({1,0}, {0,1}} and the former is a parallelogram with area 1 and the latter is a square with area 1.

Dan (Fri, 23 Oct 2020 18:56:47 GMT):
(tho usually when I try to do math quickly I mess something up)

Dan (Fri, 23 Oct 2020 18:56:58 GMT):
(also happens when I take a lot of time)

hartm (Fri, 23 Oct 2020 18:58:12 GMT):
Yep, that's right!

Dan (Fri, 23 Oct 2020 18:58:37 GMT):
thanks!

hartm (Fri, 23 Oct 2020 18:59:28 GMT):
What I have said is a little bit of an oversimplification of what's going on in high dimensions (and of the GS basis), but it's good for intuition.

Dan (Fri, 23 Oct 2020 19:02:04 GMT):
works for me. and seems to work just fine in low dimension .. more so than seeing intuitively the difficulty in finding the distance between a perturbed point and a lattice point. tho even there I now think of looking at the projection of a 3D point on a 2D drawing. The point will look close to a 'foreground' vertex just because of the projection.

hartm (Fri, 23 Oct 2020 19:04:03 GMT):
This "projecting to the GS basis" idea for lattice reduction has a name: Babai's nearest plane algorithm.

ashutosh_kumar (Mon, 26 Oct 2020 20:56:41 GMT):
Lattice Based system is NP hard because of Super Increasing Subset Sum Problem applied on coefficients of vectors.

hartm (Mon, 26 Oct 2020 21:29:19 GMT):
Lattice-based cryptosystems are not NP-hard themselves. Crypto problems themselves generally have to be in NP intersect coNP, and it is considered to be unlikely that NP = NP intersect coNP. Lattice problems are, however, generally based on finding approximate solutions of problems for which finding exact solutions are NP-hard (e.g. SVP or CVP).

ashutosh_kumar (Mon, 26 Oct 2020 22:49:17 GMT):
The basic idea is solving Zero Sum Problem.

hartm (Tue, 27 Oct 2020 01:17:21 GMT):
Lattice problems are actually quite a bit different from subset sum problems (which are only hard for a relatively narrow band of parameters).

hartm (Tue, 27 Oct 2020 01:17:40 GMT):
Here are some slides that explain some of the hardness connections on lattices pretty well: https://www.iacr.org/workshops/tcc2007/Micciancio.pdf

hartm (Tue, 27 Oct 2020 01:18:16 GMT):
Does anyone have proposed topics for the meeting this Wednesday? Looking to craft an agenda earlier than usual. Thanks!

brentzundel (Tue, 27 Oct 2020 13:35:15 GMT):
I'd like to talk about how issuer-blinded messages in a CL or BBS+ signed credential might be made usable by a prover, and what that would look like for verification.

arunprakashpj (Tue, 27 Oct 2020 20:25:00 GMT):
Has joined the channel.

arunprakashpj (Tue, 27 Oct 2020 20:25:00 GMT):
Again its a post about Libzmix ! I am trying to utilize Libzmix to make a secure pull/push of my github repo !! I was searching through the history here and got some insights. Still, If someone can redirect me to any handy blog articles , it would be great !! Usage is bit hard to understand . Any leads are appreciated !!

MALodder (Tue, 27 Oct 2020 20:57:30 GMT):
which feature of libzmix are you trying to consume

arunprakashpj (Tue, 27 Oct 2020 22:05:42 GMT):
I just wanted to use Zero Knowledge proof for the user and github repo owner

arunprakashpj (Tue, 27 Oct 2020 22:21:16 GMT):
To be precise , Module ursa::signatures

MALodder (Wed, 28 Oct 2020 01:21:39 GMT):
ursa signatures isn't ZKP, libzmix/bbs is and so is libursa/cl

mickra (Wed, 28 Oct 2020 10:18:20 GMT):
Has joined the channel.

Dan (Wed, 28 Oct 2020 14:05:59 GMT):
herzlich willkommen!

S3bb1 (Tue, 03 Nov 2020 07:56:32 GMT):
Hi all, i want to collect some feedback regarding "public Proofs". For example a user wants to show the outside world, that he has a specific claim (CL VC). Our approach would be creating a Presentation/Proof of this Credential and putting the data to a public website (where it can be checked). Since CL also requires a proof request beforehand, this must also be put public. Is this a valid approach or is there an easier/smarter way to have a "public proof" on a website for a specific credential

husnain (Tue, 03 Nov 2020 11:43:58 GMT):
Has joined the channel.

avradip (Thu, 05 Nov 2020 00:24:29 GMT):
Has joined the channel.

seriousm 3 (Fri, 06 Nov 2020 14:21:29 GMT):
Has joined the channel.

evertonzn (Tue, 10 Nov 2020 18:01:12 GMT):
Has joined the channel.

Dan (Wed, 11 Nov 2020 03:57:52 GMT):
I've got a conflict with this week's meeting. @MALodder I can take a stab at that k256 change later this week if you haven't already started on it.

MALodder (Wed, 11 Nov 2020 04:31:44 GMT):
I have not started but feel free to do so

hartm (Wed, 11 Nov 2020 15:03:57 GMT):
https://wiki.hyperledger.org/display/ursa/2020-11-11+Meeting+Agenda

hartm (Wed, 11 Nov 2020 15:18:57 GMT):
https://people.csail.mit.edu/henrycg/pubs/oakland15riposte/

Dan (Fri, 13 Nov 2020 18:24:52 GMT):
Can someone remind me the goal of our docker containers? Are those to shell into and use as dev environments for the respective platforms?

Dan (Fri, 13 Nov 2020 20:29:59 GMT):
n/m. I think I have the gist. I plan to put up a PR with some fixes for the ubuntu ones.

MALodder (Fri, 13 Nov 2020 21:21:44 GMT):
https://github.com/hyperledger/ursa/pull/165

MALodder (Fri, 13 Nov 2020 21:21:53 GMT):
Adds secret sharing schemes

Dan (Fri, 13 Nov 2020 21:57:32 GMT):
If you want more compact license headers you can use spdx... ``` # Copyright contributors to Hyperledger Ursa # SPDX-License-Identifier: Apache-2.0 ```

MALodder (Fri, 13 Nov 2020 22:00:13 GMT):
hmm, okay, I'll change it to that

Dan (Fri, 13 Nov 2020 22:01:33 GMT):
Wow is that all new code? I had my head in something else and I thought your PR was relocating stuff in the new structure, but that looks like you added a whole new feature?

MALodder (Fri, 13 Nov 2020 22:01:43 GMT):
yes that part is all new

Dan (Fri, 13 Nov 2020 22:01:52 GMT):
Super cool!

MALodder (Fri, 13 Nov 2020 22:01:59 GMT):
I wanted that in place before relocating signatures

MALodder (Fri, 13 Nov 2020 22:02:12 GMT):
because I want to add secret sharing to each signature

Dan (Fri, 13 Nov 2020 22:02:18 GMT):
Ok, I'll say wow a couple more times here.

MALodder (Fri, 13 Nov 2020 22:02:58 GMT):
Also add threshold signing to signatures after the refactor which relies on secret sharing schees

MALodder (Fri, 13 Nov 2020 22:02:58 GMT):
Also add threshold signing to signatures after the refactor which relies on secret sharing schemes

MALodder (Fri, 13 Nov 2020 22:03:09 GMT):
same with DKG

MALodder (Fri, 13 Nov 2020 22:03:18 GMT):
thanks for the quick review

Dan (Fri, 13 Nov 2020 22:03:52 GMT):
Unfortunately I've burned all my ursa time for today and I won't get a chance to give you a full and substantive review right now. Maybe we can find some time next week and you could walk me or others through it. We could use the next ursa meeting but I think that's 2 weeks out which isn't ideal.

MALodder (Fri, 13 Nov 2020 22:04:35 GMT):
its in 3 weeks since due to Thanksgiving

MALodder (Fri, 13 Nov 2020 22:06:24 GMT):
maybe we could do it this coming Wednesday

Dan (Fri, 13 Nov 2020 22:08:28 GMT):
Yeah, I've got some open slots wed. I need to jet now, but let's sync up over email or :rocket: at the beginning of the week and pick a slot on Wed.

hartm (Fri, 13 Nov 2020 22:33:32 GMT):
Let's talk this coming Wednesday then?

MALodder (Fri, 13 Nov 2020 22:35:33 GMT):
sure that works for me

hartm (Fri, 13 Nov 2020 22:36:36 GMT):
Let's just shoot for a time a little later than 7 AM ;)

MALodder (Fri, 13 Nov 2020 22:36:39 GMT):
in the mean time, hart feel free to review this as well

hartm (Fri, 13 Nov 2020 22:37:03 GMT):
Sure. I think I've already seen part of it.

MALodder (Fri, 13 Nov 2020 22:37:34 GMT):
I do have a conflict on wednesday at 9. I'm meeting with Rosario Gennaro and Steven Goldfeder to review my tECDSA implementation

MALodder (Fri, 13 Nov 2020 22:37:43 GMT):
so I can't go too much later

hartm (Fri, 13 Nov 2020 22:37:58 GMT):
I don't have time today, but I should be able to finish well before a Wednesday meeting.

hartm (Fri, 13 Nov 2020 22:38:06 GMT):
Oh nice!

MALodder (Fri, 13 Nov 2020 22:38:09 GMT):
right, it doesn't have to be today

MALodder (Fri, 13 Nov 2020 22:38:17 GMT):
hopefully before wednesday

hartm (Fri, 13 Nov 2020 22:38:22 GMT):
Yeah.

hartm (Fri, 13 Nov 2020 22:38:50 GMT):
OK, what times on Wednesday work for you then.

MALodder (Sat, 14 Nov 2020 05:35:21 GMT):
Our normal schedule does

hartm (Sat, 14 Nov 2020 19:16:05 GMT):
@Dan , does that work for you?

Dan (Sat, 14 Nov 2020 20:01:07 GMT):
Wed I can do (pacific time) 6, 9, 11 am. 12 and 2pm. Any of those work?

Dan (Sat, 14 Nov 2020 20:03:44 GMT):
Also if the PR doesn't already mention it is there a certain paper or something I should read first?

Dan (Sun, 15 Nov 2020 03:12:34 GMT):
Incidentally if you use Teams: https://microsoftteams.uservoice.com/forums/599053-schools-and-universities/suggestions/34497136-latex-math-input

MALodder (Sun, 15 Nov 2020 13:31:02 GMT):
Paper 1

MALodder (Sun, 15 Nov 2020 13:31:03 GMT):
https://github.com/hyperledger/ursa/pull/165/files#diff-f98afd2fd215d02a063f519ec33b7ce1914ca6290bd35027423dd5273ea6aeefR23

MALodder (Sun, 15 Nov 2020 13:31:20 GMT):
Paper 2 https://github.com/hyperledger/ursa/pull/165/files#diff-a1484dde30684fe48463ec84fb003a7f6872d15c127269a47f575ea4926253caR28

MALodder (Sun, 15 Nov 2020 13:31:43 GMT):
Paper 3

MALodder (Sun, 15 Nov 2020 13:31:44 GMT):
https://github.com/hyperledger/ursa/pull/165/files#diff-a1484dde30684fe48463ec84fb003a7f6872d15c127269a47f575ea4926253caR34

MALodder (Sun, 15 Nov 2020 13:31:50 GMT):
I always inline the paper references

MALodder (Sun, 15 Nov 2020 13:31:54 GMT):
in the code

MALodder (Sun, 15 Nov 2020 13:35:16 GMT):
references are also in the README.md

Dan (Sun, 15 Nov 2020 16:25:25 GMT):
awesome thanks

hartm (Tue, 17 Nov 2020 02:37:24 GMT):
@MALodder What works for you ?

MALodder (Tue, 17 Nov 2020 02:37:59 GMT):
2pm pst works

hartm (Tue, 17 Nov 2020 02:38:12 GMT):
12 would work best for me.. I could do 30 minutes at 2:00 (have a 2:30 meeting)/

MALodder (Tue, 17 Nov 2020 02:41:12 GMT):
I’ll see if I could do 12

MALodder (Tue, 17 Nov 2020 02:41:20 GMT):
I’ll know tomorrow

hartm (Tue, 17 Nov 2020 02:41:36 GMT):
Awesome, great.

MALodder (Tue, 17 Nov 2020 14:58:08 GMT):
noon PST wednesday works for me

MALodder (Tue, 17 Nov 2020 14:58:14 GMT):
I have a zoom room we can use too

hartm (Tue, 17 Nov 2020 16:55:02 GMT):
Perfect--talk to you all then.

Dan (Tue, 17 Nov 2020 22:38:02 GMT):
ACK

hartm (Tue, 17 Nov 2020 22:38:21 GMT):
SYN ACK

Dan (Tue, 17 Nov 2020 22:38:27 GMT):
FIN

MALodder (Wed, 18 Nov 2020 15:00:45 GMT):
any chance we can meet at 11:30 PST

MALodder (Wed, 18 Nov 2020 15:00:51 GMT):
just 30 minutes early

MALodder (Wed, 18 Nov 2020 15:01:13 GMT):
I have a meeting at 12:30 PST

MALodder (Wed, 18 Nov 2020 15:03:16 GMT):
otherwise I'll only have 30 minutes

hartm (Wed, 18 Nov 2020 16:58:12 GMT):
I can't make it then, unfortunately, but you all are welcome to start without me.

MALodder (Wed, 18 Nov 2020 16:58:39 GMT):
okay lets plan on continuing it at noon then

MALodder (Wed, 18 Nov 2020 19:13:37 GMT):
for anyone who wants to join the ursa code review

MALodder (Wed, 18 Nov 2020 19:13:37 GMT):
https://us02web.zoom.us/j/5897053257

MALodder (Wed, 18 Nov 2020 19:13:42 GMT):
in 45 minutes

MALodder (Wed, 18 Nov 2020 19:13:56 GMT):
@hartm @Dan @brentzundel ^^^

hartm (Wed, 18 Nov 2020 19:15:24 GMT):
I'll join at noon.

MALodder (Fri, 20 Nov 2020 16:03:28 GMT):
pushed changes to the PR after suggestions from @hartm and @Dan

brentzundel (Tue, 24 Nov 2020 22:48:02 GMT):
I can't remember if we're meeting tomorrow or not.

hartm (Tue, 24 Nov 2020 23:00:29 GMT):
I believe we were thinking of cancelling? Will people be available?

hartm (Wed, 25 Nov 2020 02:11:43 GMT):
@here Unless I hear otherwise, I'm going to suggest we cancel tomorrow's meeting. It seems like a lot of people are taking the week off and will be unavailable for the meeting.

MALodder (Wed, 25 Nov 2020 04:15:02 GMT):
I’m out for vacation and won’t be attending

piyushmaheshwari65 (Wed, 25 Nov 2020 04:20:13 GMT):
Has joined the channel.

hartm (Wed, 25 Nov 2020 04:45:52 GMT):
@here I'm technically on vacation too. Let's cancel and meet up again in two weeks. In the meantime, please feel free to discuss things via email or chat. Thanks!

brentzundel (Wed, 25 Nov 2020 16:53:32 GMT):
who owns the account on PyPi for ursa-python?

rjones (Wed, 25 Nov 2020 17:27:59 GMT):
@brentzundel I own https://pypi.org/project/python-ursa/

rjones (Wed, 25 Nov 2020 17:28:30 GMT):
well, the project owns, but I have control of it

brentzundel (Wed, 25 Nov 2020 17:42:49 GMT):
That was my assumption, thanks for confirming.

rjones (Wed, 25 Nov 2020 17:43:04 GMT):
do I need to do something with it?

brentzundel (Wed, 25 Nov 2020 17:43:32 GMT):
Not at this point. I had a team member ask for details.

brentzundel (Wed, 25 Nov 2020 17:45:40 GMT):
@rjones would you mind if they reached out to you directly to try and explain what they are looking to do?

rjones (Wed, 25 Nov 2020 17:47:15 GMT):
please send email to community-architects@hyperledger.org so we're all on the same page

cam-parra (Mon, 30 Nov 2020 21:35:37 GMT):
I own some of those I think... if you can include me in the emails that be great

rjones (Wed, 02 Dec 2020 14:49:41 GMT):
@cam-parra the issue was https://pypi.org/project/python-ursa/ only had the wheel, not the source. I version bumped to 0.1.1 so I could publish the wheel and source.

rjones (Wed, 02 Dec 2020 14:49:58 GMT):
and I deleted 0.1.0 because I didn't realize you couldn't republish deleted files

Dan (Wed, 02 Dec 2020 21:42:10 GMT):
Does signature malleability demonstrate existential forgery? I.e. if a paper formally claims to be secure against existential forgery, but it is possible to mutate a signature and still have it verify with the same key, does that demonstrate a flaw? Or must you contrive a signature for a *different* message?

hartm (Wed, 02 Dec 2020 21:55:29 GMT):
@Dan You have to forge a signature for a *different* message.

hartm (Wed, 02 Dec 2020 21:55:52 GMT):
You can have non-malleable signatures, though, which have the property that you state.

hartm (Wed, 02 Dec 2020 21:56:29 GMT):
Even stronger, there are unique signatures, where for each message there only exists one possible signature.

hartm (Wed, 02 Dec 2020 21:57:34 GMT):
As an example of a signature scheme that is secure but trivially malleable, consider some existing signature scheme (KeyGen, Sign, Verify) with the usual form. We can construct a silly scheme in the following way:

hartm (Wed, 02 Dec 2020 21:57:47 GMT):
KeyGen' := Keygen

hartm (Wed, 02 Dec 2020 21:58:03 GMT):
Sign' = Sign(sk, m) || 1

hartm (Wed, 02 Dec 2020 21:58:28 GMT):
Verify' = Verify( sigma \ last bit, vk)

hartm (Wed, 02 Dec 2020 21:58:30 GMT):
where sigma \

hartm (Wed, 02 Dec 2020 21:58:30 GMT):
where sigma \ last bit means delete the last bit from sigma.

hartm (Wed, 02 Dec 2020 21:59:44 GMT):
Note flipping the last bit in each signature still constitutes a valid signature, which means we also have malleability. But breaking the 'prime' scheme implies breaking the original signature scheme if you generate a signature on an unqueried message.

Dan (Thu, 03 Dec 2020 00:28:46 GMT):
cool. thanks. Another example is flipping the y coord in ecdsa. In the context of how it was used in bitcoin that became a semantic flaw, but I guess that's a consequence of how ecdsa is used in that system and doesn't constitute a formal forgery.

daidoji (Thu, 03 Dec 2020 00:32:38 GMT):
why is it a semantic flaw?

Dan (Thu, 03 Dec 2020 00:34:14 GMT):
that's not a formal term. I just mean that bitcoin made assumptions that there was only one signature for a given message but because elliptic curves are symmetric you can have two valid signatures (one with a +y and one with a -y).

Dan (Thu, 03 Dec 2020 00:39:04 GMT):
Coming back to existential forgery... In most systems you have some sort of hash_to_group function where you take the message and squish it into a point. If I can produce a valid signature for the same key but modifying the hash result does that count? Or must it be a change to the plain text message / know the preimage. i.e. verify(p=hash(m), sig, pk) verify(p'=hash(m)+1, sig, pk) does that count or must I modify m directly?

Dan (Thu, 03 Dec 2020 00:39:04 GMT):
Coming back to existential forgery... In most systems you have some sort of hash_to_group function where you take the message and squish it into an element. If I can produce a valid signature for the same key but modifying the hash result does that count? Or must it be a change to the plain text message / know the preimage. i.e. verify(p=hash(m), sig, pk) verify(p'=hash(m)+1, sig, pk) does that count or must I modify m directly?

hartm (Thu, 03 Dec 2020 00:54:42 GMT):
The hash is deterministic. So if you can find two messages m, m' such that H(m) = H(m'), then you're breaking the collision resistance of the hash.

hartm (Thu, 03 Dec 2020 00:56:37 GMT):
No, you need to modify m directly. Remember that, to win the game, you need to provide a pair (m, \sigma) such that Verify(m, \sigma, vk) = 1. So you have to modify m directly. You can also think about the practical ramifications of this definition. What good is the second verify equation you presented above? No one will accept it as a valid signature, so it's not a good forgery.

Dan (Thu, 03 Dec 2020 03:02:36 GMT):
Fair enough. Thanks. :)

Dan (Fri, 04 Dec 2020 21:26:17 GMT):
@MALodder I'm in the middle of doing the k256 library change. I don't remember why we have this rustlibsecp256k1 feature defined here: https://github.com/hyperledger/ursa/blob/master/libursa/src/lib.rs#L84-L85 as opposed to just relying on `feature = "ecdsa_secp256k1"` I think the latter is the main feature exposure, i.e. we have 3 flavors: ecdsa_secp256k1 (pure rust); ecdsa_secp256k1_native (bitcoin lib); and ecdsa_secp256k1_asm (bitcoin lib);

MALodder (Fri, 04 Dec 2020 21:45:31 GMT):
It’s there for rust only features

Dan (Fri, 04 Dec 2020 21:59:52 GMT):
ok, I thought ecdsa_secp256k1 is (a/the?) feature definition for rust only

Dan (Fri, 04 Dec 2020 22:04:49 GMT):
I don't understand how these are different

Dan (Fri, 04 Dec 2020 22:21:20 GMT):
Question #2... This seems like it should be a build-time error: https://github.com/hyperledger/ursa/blob/master/libursa/src/signatures/secp256k1.rs#L198 As far as I can tell that should be `libsecp256k1::key::PublicKey` The bitcoin library does not list `PublicKey` as a top level object. They have an example with the appearance of a higher level struct but the actual code has to import the `key` module. is there any chance we aren't building this in CI? I mean I know this is 99% probability I'm just missing some language thing but I thought I'd ask before spending an hour side track in to the build.

Dan (Fri, 04 Dec 2020 22:22:38 GMT):
bitcoin lib example code: https://github.com/rust-bitcoin/rust-secp256k1/blob/master/src/lib.rs#L76-L80 actual code: https://github.com/rust-bitcoin/rust-secp256k1/blob/master/src/lib.rs#L76-L80

MALodder (Mon, 07 Dec 2020 03:13:34 GMT):
Native Bitcoin uses C under the hood

Dan (Mon, 07 Dec 2020 14:30:49 GMT):
Sorry I guess I'm not asking clearly, but it's also probably not super important.. there's two 'features' we have that are both labeled for pure rust, i.e. they both use the same rust lib, not the rust-wrapping of the bitcoin lib. If you recall why lemme know.

MALodder (Mon, 07 Dec 2020 15:31:50 GMT):
no they're not the same library

MALodder (Mon, 07 Dec 2020 15:32:18 GMT):
also I can get some +1's for the secret sharing PR

Dan (Tue, 08 Dec 2020 16:58:41 GMT):
fyi, I've got a conflict tomorrow. will miss the ursa meeting. :(

MALodder (Wed, 09 Dec 2020 13:45:34 GMT):
I will most likely be late to the Ursa meeting

daidoji (Wed, 09 Dec 2020 19:02:43 GMT):
not sure if this is the right group, but where do these key prefixes come from? https://w3c-ccg.github.io/did-method-key/#p-256

daidoji (Wed, 09 Dec 2020 19:03:11 GMT):
Or like, how did they choose these prefixes?

zhenbing (Mon, 14 Dec 2020 08:56:39 GMT):
Has joined the channel.

neilbts (Fri, 18 Dec 2020 17:06:37 GMT):
Has joined the channel.

pfeairheller (Mon, 21 Dec 2020 11:57:13 GMT):
Has joined the channel.

hartm (Tue, 22 Dec 2020 19:43:32 GMT):
Is there still interest in having a meeting tomorrow morning? I know some people discussed in the last meeting, but I wanted to make sure everyone still wanted to talk.

MALodder (Tue, 22 Dec 2020 22:00:00 GMT):
I would like to meet to discuss a better signing interface to account for ECDSA, Schnorr, and BLS

MALodder (Tue, 22 Dec 2020 22:00:40 GMT):
how to account for threshold signing as well

swcurran (Tue, 22 Dec 2020 22:05:56 GMT):
@MALodder -- any progress on the new revocation scheme you've been working on with Tobias?

MALodder (Tue, 22 Dec 2020 22:06:39 GMT):
yes the code is finished but I haven't put it into ursa yet

swcurran (Tue, 22 Dec 2020 22:10:07 GMT):
Has the code been peer reviewed? I think you said you were working on that...

MALodder (Tue, 22 Dec 2020 22:26:48 GMT):
hart has reviewed

MALodder (Tue, 22 Dec 2020 22:27:00 GMT):
@hartm and another cryptographyer

MALodder (Tue, 22 Dec 2020 22:27:00 GMT):
@hartm and another cryptographer

brentzundel (Tue, 22 Dec 2020 23:01:05 GMT):
I'm up to meet

hartm (Wed, 23 Dec 2020 00:00:33 GMT):
Great! Let's talk tomorrow morning.

hartm (Wed, 23 Dec 2020 00:12:26 GMT):
I've also written up our quarterly report. https://wiki.hyperledger.org/display/TSC/2020+Q4+Hyperledger+Ursa Please feel free to edit as you see fit.

hartm (Wed, 23 Dec 2020 04:34:34 GMT):
I've also posted an agenda for the meeting tomorrow. Please feel free to edit as you all see fit. Thanks!

MALodder (Mon, 28 Dec 2020 14:56:13 GMT):
heres the paper on distributed BBS+ https://www.orbs.com/wp-content/uploads/2019/04/Crypto_Group_signatures-2.pdf

Dan (Wed, 06 Jan 2021 14:52:08 GMT):
HNY! I have a conflict this morning. I'm working on https://github.com/hyperledger/ursa/issues/163 and should have that ready before our next meeting.

domwoe (Fri, 08 Jan 2021 12:30:55 GMT):
Given digitally signed messages m_i with public keys p_i. Can I prove that the sum is M = Sum_i m_i without disclosing the individual messages? What digital signature schemes and cryptographic primitives would be suitable for this use case? Any pointers?

hartm (Sat, 09 Jan 2021 00:36:13 GMT):
You can do this with general purpose SNARKs (or, more generally, general purpose ZK proofs).

coffeethecup (Wed, 13 Jan 2021 10:28:56 GMT):
Has joined the channel.

daidoji (Thu, 14 Jan 2021 14:13:24 GMT):
In some of the papers that have been posted here and in the meetings they describe their security proofs as "proof by simulation". I think I get the gist of it from the proofs that have been presented in the papers, but is there a more coherent and full write up on the topic of security proof "by simulation"? ex) https://www.orbs.com/wp-content/uploads/2019/04/Crypto_Group_signatures-2.pdf uses this technique

daidoji (Thu, 14 Jan 2021 14:13:24 GMT):
In some of the papers that have been posted here and in the meetings they describe their security proofs as "proof by simulation". I think I get the gist of it from the context of the proofs that have been presented in the papers, but is there a more coherent and full write up on the topic of security proof "by simulation"? ex) https://www.orbs.com/wp-content/uploads/2019/04/Crypto_Group_signatures-2.pdf uses this technique

hartm (Thu, 14 Jan 2021 14:48:34 GMT):
I'm not sure. Maybe a crypto textbook is your best bet (e.g. Katz-Lindell)?

daidoji (Thu, 14 Jan 2021 14:56:31 GMT):
ahh roger.

HarshMultani (Thu, 14 Jan 2021 17:35:01 GMT):
Has joined the channel.

avradip (Tue, 19 Jan 2021 19:06:20 GMT):
Hi Everyone, we at Fujitsu Laboratories are planning to develop a Zero Knowledge Framework where application developers can easily switch among various zero knowledge libraries. I can talk in a bit more details in tomorrow's meeting, but we would like to get Ursa communities feedback and if this is something that you think would be helpful for everybody. Please note, zk-interface by QED-it attains some of the broad goals that we want to achieve https://github.com/QED-it/zkinterface , but it is not exactly user friendly.

hartm (Tue, 19 Jan 2021 19:40:38 GMT):
@avradip Great! I'll add you to the meeting agenda tomorrow.

MALodder (Wed, 20 Jan 2021 19:01:17 GMT):
For those that are interested

MALodder (Wed, 20 Jan 2021 19:01:17 GMT):
https://github.com/algorand/pairing-plus/pull/18

ajayjadhav (Thu, 21 Jan 2021 12:11:48 GMT):
Has left the channel.

MALodder (Thu, 28 Jan 2021 15:33:54 GMT):
we should consider this for ursa https://datatracker.ietf.org/doc/draft-komlo-frost/?include_text=1

hartm (Thu, 28 Jan 2021 17:34:35 GMT):
Yeah. Definitely worth considering.

MALodder (Fri, 29 Jan 2021 20:19:57 GMT):
found someone maintaining pairing-plus in a fork called paired

MALodder (Fri, 29 Jan 2021 20:20:11 GMT):
so if we use that then we don't need to maintain a fork in ursa

MALodder (Fri, 29 Jan 2021 20:37:50 GMT):
unfortunately it requires modifying some stuff

hartm (Sat, 30 Jan 2021 00:18:07 GMT):
Can you link the fork?

MALodder (Sun, 31 Jan 2021 14:26:22 GMT):
https://crates.io/crates/paired

karthiksamaganam (Mon, 01 Feb 2021 14:41:04 GMT):
Has joined the channel.

manikamittal (Wed, 03 Feb 2021 07:54:20 GMT):
Has joined the channel.

rjones (Wed, 03 Feb 2021 15:15:40 GMT):
Howdy - I need one more approval to switch the default branch: https://github.com/hyperledger/ursa/pull/172

luis.marado (Thu, 04 Feb 2021 10:49:52 GMT):
Has joined the channel.

rjones (Mon, 08 Feb 2021 14:42:39 GMT):
Howdy - I'm working on moving the CI to GitHub Actions; [I need a merge for docs please](https://github.com/hyperledger/ursa-docs/pull/16)

rjones (Tue, 09 Feb 2021 13:56:14 GMT):
Howdy - step two for [ursa docs move to GHA](https://github.com/hyperledger/ursa-docs/pull/17) needs a +1

rjones (Tue, 09 Feb 2021 14:01:10 GMT):
I'll also note that you should be able to [delete these stale branches](https://github.com/hyperledger/ursa/branches) if you desire

rjones (Tue, 09 Feb 2021 14:58:01 GMT):
Howdy - step one to move [main repo Ursa CI](https://github.com/hyperledger/ursa/pull/173) from AZP to GHA. I noticed on both, the test step runs 0 tests - is that by design?

rjones (Thu, 11 Feb 2021 01:52:35 GMT):
Hi - I need one more +1: https://github.com/hyperledger/ursa/pull/173

Dan (Wed, 17 Feb 2021 05:52:57 GMT):
fyi, I can't make the wed meeting. unavoidable conflict. plz save me a donut.

da3v21 (Wed, 17 Feb 2021 12:57:14 GMT):
Has joined the channel.

MALodder (Wed, 17 Feb 2021 14:41:55 GMT):
Sorry guys it’s dumped 30 “ of fresh powder and still snowing. I’ll be skiing during the meeting

MALodder (Wed, 17 Feb 2021 14:50:21 GMT):
Might attend if I have reception while waiting in to get up the canyon

hartm (Wed, 17 Feb 2021 15:03:44 GMT):
https://wiki.hyperledger.org/display/ursa/2020-02-17+Meeting+Agenda

hartm (Wed, 17 Feb 2021 15:29:40 GMT):
https://web.eecs.umich.edu/~cpeikert/pubs/nizk-lwe.pdf

hartm (Wed, 17 Feb 2021 15:30:21 GMT):
https://eprint.iacr.org/2017/956.pdf

eadventurous (Thu, 18 Feb 2021 12:36:57 GMT):
Just curious was there any research done into post-quantum cryptography and are there any plans to implement it?

daidoji (Thu, 18 Feb 2021 13:30:39 GMT):
I think there was a discussion about that on the call yesterday if you listen to that recording. There has been work done but that's as far as my understanding goes.

eadventurous (Thu, 18 Feb 2021 14:22:18 GMT):
@daidoji can you send me a link to the recordings? I found the agenda of the meetings but no recordings yet...

daidoji (Thu, 18 Feb 2021 14:24:26 GMT):
oh I'm sorry, I guess we weren't recording. Sorry. Hopefully someone else will be able to help you in here.

hartm (Thu, 18 Feb 2021 14:55:41 GMT):
I have the recording but need to upload it (zoom takes forever to process it, so it's not uncommon for me to forget, unfortunately).

hartm (Thu, 18 Feb 2021 14:56:27 GMT):
What kind of post-quantum crypto are you interested in? I can probably just answer your questions here rather than you having to listen to an entire meeting. We also didn't talk about general post-quantum strategy in the meeting, either.

hartm (Thu, 18 Feb 2021 14:57:21 GMT):
We do have a plan to implement basic post-quantum crypto (i.e. signatures and key exchange/basic encryption). So far, no one is really interested in using it though, so we haven't progressed too far.

hartm (Thu, 18 Feb 2021 14:57:43 GMT):
If you're interested in post-quantum ZK and stuff like that, then it gets much more complicated.

eadventurous (Thu, 18 Feb 2021 15:03:03 GMT):
I am from Hyperledger Iroha team and we are potentially interested in quantum resistant cryptography (public key signatures and encryption algorithms). But it is a long term goal though we were thinking to propose a its research and MVP integration as an internship. And naturally as we are using ursa, we wanted to check at first if you support it already.

hartm (Thu, 18 Feb 2021 15:06:43 GMT):
We're definitely planning on supporting those. We are also waiting on the NIST post-quantum competition to wrap up, as our implementations will likely be based on whatever wins that.

hartm (Thu, 18 Feb 2021 15:06:58 GMT):
That should be later this year.

hartm (Thu, 18 Feb 2021 15:07:05 GMT):
What's your timeline for needing post-quantum crypto?

eadventurous (Thu, 18 Feb 2021 15:19:11 GMT):
We don't have any specific date for this yet, I think if ursa will support it by the end of this year or beginning of the next, this will suit us.

hartm (Thu, 18 Feb 2021 15:20:15 GMT):
Great. Are you following the NIST competition? We're planning on really diving into it once that wraps up. At that point, it makes sense to really spend some time on it (and we'd be happy to have your participation).

eadventurous (Thu, 18 Feb 2021 15:35:27 GMT):
Thank you for the suggestion! Yes, we will try to follow. Sure we will be happy to contribute to Ursa if our priorities will allow that, when the development starts.

hartm (Thu, 18 Feb 2021 15:36:00 GMT):
Even if you don't have time or resources to contribute, it'd still be useful to hear your requirements and how you want to use post-quantum crypto. So definitely stay in touch!

eadventurous (Thu, 18 Feb 2021 16:38:11 GMT):
Ok, sure

hartm (Wed, 03 Mar 2021 15:11:05 GMT):
https://events.linuxfoundation.org/hyperledger-global-forum/program/cfp/

hartm (Wed, 03 Mar 2021 15:19:49 GMT):
@Dan I don't think I've ever heard you this excited!

hartm (Wed, 03 Mar 2021 15:43:57 GMT):
https://www.cs.bu.edu/~reyzin/papers/fuzzy.pdf

Dan (Wed, 03 Mar 2021 20:12:23 GMT):
@FriendsOfBoaty https://www.startribune.com/big-winner-in-mndot-s-snowplow-contest-plowy-mcplowface/600029697/

hartm (Wed, 03 Mar 2021 22:00:38 GMT):
Nice! I assume you were instrumental in the campaign.\

Dan (Thu, 04 Mar 2021 15:55:36 GMT):
I found out about it after the fact. But if I had known I would have told my friend Sybil and there would be 6M more votes :-D

daidoji (Wed, 10 Mar 2021 13:26:11 GMT):
Oh wow, so those "sigils" from the scifi novel Daemon are possible? That's awesome.

hartm (Wed, 10 Mar 2021 17:17:24 GMT):
I have not read that novel. But fuzzy crypto is essential for things like biometrics.

daidoji (Wed, 10 Mar 2021 18:08:08 GMT):
Oh its a "cool ideas" scifi novel. In the novel various agents of the antagonist (which was a giant AI decentralized social network thing) produced "sigils" to prove that they really were working for the giant AI decentralized network. I'm not gonna do it justice but they were like cryptographically signed images that humans could also recreate and verify. So like human being traces some pattern in the air -> generates signed sigil. Other humans could look at a sigil and see if it was valid or not (but also in the background software the AI network gave the human agents would verify it cryptographically).

daidoji (Wed, 10 Mar 2021 18:08:43 GMT):
I thought was a cool idea, but had no way to go about it

hartm (Wed, 10 Mar 2021 18:54:27 GMT):
I'm not sure we'll ever be able to have human verifiable cryptography, unfortunately.

daidoji (Wed, 10 Mar 2021 19:10:59 GMT):
unfortunately, but human eyes are pretty good at spotting differences that aren't pathological

daidoji (Wed, 10 Mar 2021 19:11:03 GMT):
still thought it was a cool idae

Dan (Wed, 17 Mar 2021 13:48:55 GMT):
Conflict this morning. I might make the second half.

hartm (Wed, 17 Mar 2021 14:26:22 GMT):
Blog post: https://dwhuseby.medium.com/the-authentic-data-economy-9802da67e1fa

hartm (Wed, 17 Mar 2021 20:09:18 GMT):
I just created our quarterly report: https://wiki.hyperledger.org/display/TSC/2021+Q1+Hyperledger+Ursa . Feel free to edit as you all see fit! Thanks!

daidoji (Fri, 19 Mar 2021 13:56:11 GMT):
When you put: >The first iteration of this infrastructure was slow, did not scale, was overly simplistic in some ways and wildly over-complicated in other ways and therefore prevented the ADE from being possible. and link to the ToIP RFC what parts did you think were too simple and which parts did you think were far too complex in particular?

daidoji (Fri, 19 Mar 2021 13:56:56 GMT):
or was it just the rest of the stuff in that paragraph below?

hartm (Fri, 19 Mar 2021 15:47:29 GMT):
It's Dave Huseby's blog post--you may want to ask him @dhuseby

daidoji (Fri, 19 Mar 2021 17:18:06 GMT):
ahh indeed

Dan (Tue, 23 Mar 2021 19:21:00 GMT):
Just came across this: https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol Which reminded me of the protocol that @MALodder showed a few weeks back.

hartm (Tue, 23 Mar 2021 22:24:11 GMT):
The protocols Mike described are a bit orthogonal to PAKEs, but for a similar application. ZK authentication is pretty neat, though, and I'd love to see it in practice.

lmtriet (Wed, 24 Mar 2021 13:12:28 GMT):
Hi, just curious, what is the protocol you are talking about ? I've heard of OPAQUE but it is still a PAKE.

lmtriet (Wed, 24 Mar 2021 19:48:17 GMT):
I have read the Groth signature implementation in libzmix (groth_sig.rs) and there is a part in the code that does not follow the paper which might lead to signature forgery. It is OK you to discuss it here ? Please let me know. Thanks.

hartm (Wed, 24 Mar 2021 22:10:41 GMT):
Thanks for bringing this up. here is the link for security bug reporting: https://github.com/hyperledger/ursa/blob/main/SECURITY.md

hartm (Wed, 24 Mar 2021 22:11:33 GMT):
Feel free to PM me or any of the other maintainers if you have questions.

lmtriet (Wed, 24 Mar 2021 23:24:06 GMT):
I have tried Jira but Ursa is not in the dropdown list of the field project. So I just dropped an email for you.

hartm (Thu, 25 Mar 2021 00:02:43 GMT):
I got the email. Thanks! I'll go over it and get back to you.

hartm (Thu, 25 Mar 2021 01:02:35 GMT):
I responded. via email. Let me know what you think. And thanks again!

dgt1nsty (Mon, 29 Mar 2021 14:56:41 GMT):
Hello! I couldn't compile ursa project from source, whnever I try I'm getting seg fault and no descriptive reason why it is happening. So my question is have anyone encounter this error before and know how to solve it?

hartm (Mon, 29 Mar 2021 15:14:37 GMT):
Can you post more details? It's going to be hard to help you otherwise. Thanks!

dgt1nsty (Mon, 29 Mar 2021 15:26:48 GMT):
I build my env for my ubuntu 16.04 machine and get it from ursa project to my local and I build from source using cargo build --release command. When I execute he resulting artifact libursa.so I get seg fault. You can see from picture.

dgt1nsty (Mon, 29 Mar 2021 15:26:48 GMT):
I build my env for my ubuntu 16.04 machine and get ursa project to my local after that I build from source using cargo build --release command. When I execute he resulting artifact libursa.so I get seg fault. You can see from picture.

dgt1nsty (Mon, 29 Mar 2021 15:26:48 GMT):
I build my env for my ubuntu 16.04 machine and get ursa project to my local after that I build from source using cargo build --release command. When I execute the resulting artifact libursa.so I get seg fault. You can see from picture.

dgt1nsty (Mon, 29 Mar 2021 15:26:56 GMT):

error.PNG

hartm (Mon, 29 Mar 2021 15:30:23 GMT):
That's weird. I haven't done an Ubuntu build myself.

dgt1nsty (Mon, 29 Mar 2021 15:32:35 GMT):
I tried it on other ubuntu version but I got the same result. May I ask which platform did you try it.

dgt1nsty (Mon, 29 Mar 2021 15:32:35 GMT):
I tried it on other ubuntu versions too but I got the same result. May I ask which platform did you try it.

hartm (Mon, 29 Mar 2021 15:33:26 GMT):
Most people build it on Macs, I think.

hartm (Mon, 29 Mar 2021 15:34:22 GMT):
I am sure some Aries people work on Ubuntu though--you may want to see if they respond to this eventually.

dgt1nsty (Mon, 29 Mar 2021 15:42:11 GMT):
Thank you.

hartm (Mon, 29 Mar 2021 15:43:15 GMT):
Of course! Sorry I couldn't be more helpful.

dgt1nsty (Mon, 29 Mar 2021 15:47:14 GMT):
No problem, thanks a lot for your reply I guess l need to try to dig deeper to find a solution

andrew.whitehead (Mon, 29 Mar 2021 16:25:20 GMT):
One issue, it’s a shared library, not an executable.

dgt1nsty (Tue, 30 Mar 2021 10:04:27 GMT):
yes you're right @andrew.whitehead actually what I wanted to do is test functions on library but I'm getting errors regarding cargo test

dgt1nsty (Tue, 30 Mar 2021 10:04:27 GMT):
yes you're right @andrew.whitehead actually what I wanted to do is test specific functions in a library but I'm getting errors regarding cargo test

dgt1nsty (Tue, 30 Mar 2021 10:04:58 GMT):

test_errors.PNG

brentzundel (Wed, 31 Mar 2021 14:04:00 GMT):
apologies for missing today. I am double booked.

Dan (Wed, 31 Mar 2021 14:07:39 GMT):
iirc the cargo files are in a weird state.. we turned things off to restructure the repo and are half-way through the restructuring. To get things to build you have to do some fiddling in the cargo files. Sorry that is very hand-wavey. Probably time for us to fix that.

Dan (Wed, 31 Mar 2021 14:15:21 GMT):
@brentzundel we're going to have to dock your ursa pay.

brentzundel (Wed, 31 Mar 2021 14:17:03 GMT):
dang, but only by 6 minutes, my other meeting was cancelled!

Dan (Wed, 31 Mar 2021 14:27:50 GMT):
too bad. we already divided up all your ursacoins.

hartm (Wed, 31 Mar 2021 14:29:45 GMT):
"I'm not calling them stupid, I'm just saying they're doing it all wrong."

Dan (Wed, 31 Mar 2021 14:31:39 GMT):
Liberate the NFTs!! Defend against the truncation attack! Long live the bear!!!

MALodder (Wed, 31 Mar 2021 14:34:36 GMT):

nist.pdf

Dan (Wed, 31 Mar 2021 14:41:17 GMT):
I'm curious to read more about the git usage.

dgt1nsty (Thu, 01 Apr 2021 06:58:53 GMT):
Thanks @Dan for your reply.

echsecutor (Sat, 03 Apr 2021 19:44:19 GMT):
Has joined the channel.

HighBrow (Sun, 04 Apr 2021 07:38:03 GMT):
Has joined the channel.

egidio.casati (Sat, 17 Apr 2021 18:53:58 GMT):
Has joined the channel.

Dan (Thu, 22 Apr 2021 19:21:06 GMT):
Is there a set of standardized claims that are relevant to aries? I'm not sure if it would be a self-sovereign ID thing or something else. I'm looking at JWT right now for example: https://www.iana.org/assignments/jwt/jwt.xhtml

swcurran (Thu, 22 Apr 2021 20:27:10 GMT):
Not at the Aries level as it is up to Issuers to decide what they want to issue and verifiers on what they are will to accept (what claims from what issuers).

Dan (Fri, 23 Apr 2021 17:30:38 GMT):
thanks @swcurran! Is there a standardized claim format? and/or is there something formalized with claims in DID or dependency of DID (I haven't had the opportunity to go deep on DIDs but I did poke around for claims and didn't see formalizations in the core spec).

hartm (Fri, 23 Apr 2021 20:48:34 GMT):
@swcurran Are there recommended/popular specifications?

swcurran (Fri, 23 Apr 2021 23:03:36 GMT):
Claims are put into verifiable credentials. There is a standard for verifiable credentials from the W3C, and Indy AnonCreds has a format that pre-dates the W3C standard. There is not a DID dependency on VCs, VCs are tied to a signature scheme, the keys for which might come from DIDs. VCs hold an arbitrary bucket of claims and can be used for anything. At the Aries level, there are no recommended specs. for credentials or claims. That happens at a higher level in the trust over IP stack and relates to the ecosystem. One of the fun parts (AFAIK) in the use of JWTs to hold the VCs is that JWTs have those preset list of claims. But I'm not deep on JWTs and VCs, as my experience is mostly with Indy credentials and a little bit (but gaining) on JSON-LD. Is that getting towards the answers to what you are asking?

hartm (Fri, 23 Apr 2021 23:15:00 GMT):
Yeah, thanks!

paul.bastian (Mon, 26 Apr 2021 13:01:48 GMT):
Hi, is this paper (https://github.com/hyperledger-archives/indy-crypto/blob/master/libindy-crypto/docs/AnonCred.pdf) the description of what was actually implemented in HL indy/ursa?

MALodder (Mon, 26 Apr 2021 20:04:10 GMT):
yes

hartm (Wed, 28 Apr 2021 14:05:38 GMT):
https://wiki.hyperledger.org/display/ursa/2021-04-28+Meeting+Agenda

brentzundel (Wed, 28 Apr 2021 17:55:12 GMT):
Evernym has assigned an engineer to spend a few hours a week on Ursa. @MALodder is pointing him at the open issues the best thing to do?

nhwn (Wed, 28 Apr 2021 21:05:22 GMT):
Has joined the channel.

nhwn (Wed, 28 Apr 2021 21:34:20 GMT):
Hi, I'm the aforementioned engineer -- glad to be aboard! As I understand it, my task is to get `libursa` to successfully build + have tests running on Ubuntu 20.04. Are there any contribution guidelines/documentation that I should be aware of?

rjones (Wed, 28 Apr 2021 21:45:54 GMT):
@nhwn be sure to use DCO sign-off on every commit - `git commit -s ...`

rjones (Wed, 28 Apr 2021 21:46:44 GMT):
@nhwn [the build stuff lives here](https://github.com/hyperledger/ursa/tree/main/.github/workflows)

rjones (Wed, 28 Apr 2021 21:47:41 GMT):
@nhwn feel free to edit that work flow, or start a new one

rjones (Wed, 28 Apr 2021 22:05:17 GMT):
@MALodder would you be willing to publish a new release - `v0.3.6` - to resolve https://github.com/hyperledger/ursa/issues/178 ? I notice there are more releases on crates.io than on GitHub, as well

rjones (Wed, 28 Apr 2021 22:10:50 GMT):
@hartm Sorry I missed today's call. Looking at the open PRs and issues, I think a lot of weeding could happen - what do the maintainers think about closing the outstanding PRs and doing a pass over the open issues to triage them?

hartm (Wed, 28 Apr 2021 22:58:30 GMT):
There is definitely some refactoring work that needs to be done.

hartm (Wed, 28 Apr 2021 22:59:11 GMT):
I think that would be a part of it @rjones .

paul.bastian (Fri, 30 Apr 2021 14:00:47 GMT):
Hi, I've seen this paper (https://github.com/cryptosubtlety/zero/blob/main/0.pdf) in the BLS Signature RFC, it seems to me that in general the attack model does not apply to Hyperledger Indy, because only nodes generate keys and signatures and they are kind of trustworthy + public keys can be checked against null. I've also seen in the bls.rs comments that the rogue public key attack was considered as a seperate function, are the other zero attacks considered or relevant at all?

MALodder (Fri, 30 Apr 2021 15:51:53 GMT):
I'll take a look later today

dcspinho (Fri, 30 Apr 2021 18:06:25 GMT):
Has joined the channel.

dcspinho (Fri, 30 Apr 2021 18:06:26 GMT):
Hello. Does Ursa SDK exist?

MALodder (Tue, 04 May 2021 14:02:27 GMT):
this isn't a threat to the crypto itself, just how its used. Indy isn't vulnerable since they use proof of possession

MALodder (Tue, 04 May 2021 14:02:49 GMT):
ursa = "0.3.5"

MALodder (Tue, 04 May 2021 14:02:57 GMT):
https://crates.io/crates/ursa

dcspinho (Tue, 04 May 2021 14:03:44 GMT):
only library?

MALodder (Tue, 04 May 2021 14:04:31 GMT):
what do you plan to do with ursa? ursa is a crypto library, if you are looking for higher end protocols, then Aries is what you're looking for

dcspinho (Tue, 04 May 2021 14:08:51 GMT):
in Aries we use aries sdk and libursa?

dcspinho (Tue, 04 May 2021 14:09:46 GMT):

Clipboard - 4 de Maio de 2021 15:09

dcspinho (Tue, 04 May 2021 14:09:50 GMT):
like this

MALodder (Tue, 04 May 2021 14:10:12 GMT):
yes Aries is a consumer of ursa

dcspinho (Tue, 04 May 2021 14:10:51 GMT):
Thanks

paul.bastian (Tue, 04 May 2021 14:58:31 GMT):
thanks for the clarification!

rjones (Tue, 04 May 2021 19:42:11 GMT):
@MALodder any chance to do a new release of Ursa to crates to fix the issue above? https://chat.hyperledger.org/channel/ursa?msg=XceLxCi3aTZLJMqiZ

MALodder (Wed, 05 May 2021 00:13:02 GMT):
@rjones need an approval https://github.com/hyperledger/ursa/pull/179

hartm (Wed, 05 May 2021 00:30:27 GMT):
Done, you should be good to go.

rjones (Wed, 05 May 2021 09:39:41 GMT):
Thank you, @MALodder . How do I publish to crates.io?

rjones (Wed, 05 May 2021 12:32:27 GMT):
I tagged it: https://github.com/hyperledger/ursa/releases/tag/v0.3.6

MALodder (Wed, 05 May 2021 14:07:48 GMT):
published

chris.matichuk (Fri, 07 May 2021 02:27:30 GMT):
Has joined the channel.

chris.matichuk (Fri, 07 May 2021 02:41:47 GMT):
Hi, I am new to this forum, but not new to Indy from (had our company become a Sovrin steward several years ago). I'm just not starting to dig into the details of BBS+ and have a couple questions that if someone could point me to someone that might be willing to help, that would be appreciated. First, BBS+ is noted as based on BLS12381G1_XMD:BLAKE2B_SSWU_RO_, but line 243 of the following indicates that it is using SH-256 not BLAKE2B. Can someone confirm which hash is being used, given the comment in the source? And if the comments are incorrect and blake2b is being used, is it blake2b512 (which produces 64 bytes)? https://github.com/hyperledger/ursa/blob/main/libzmix/bbs/src/keys.rs Second, the messages in the test are passed through a hash. Is this using sha256 or blake2b. And if blake2b, is it blake2b512 (which produces 64bytes)? https://github.com/hyperledger/ursa/blob/main/libzmix/bbs/tests/bbs.rs

andrew.whitehead (Fri, 07 May 2021 04:27:42 GMT):
I believe that first comment you linked to is incorrect (or outdated), the method is using hash_to_g1: https://github.com/hyperledger/ursa/blob/526fcaa39b41cfc8d3f2aa6acd0c85e430ba5c34/libzmix/bbs/src/lib.rs#L310

andrew.whitehead (Fri, 07 May 2021 04:29:41 GMT):
It’s more complicated than just using blake2 though, it’s an instantiation of the hash-to-curve algorithm with blake2 as the hash parameter, producing elements of the G1 group

andrew.whitehead (Fri, 07 May 2021 04:29:41 GMT):
It’s more complicated than just using blake2b though, it’s an instantiation of the hash-to-curve algorithm with blake2b as the hash parameter, producing elements of the G1 group

chris.matichuk (Fri, 07 May 2021 04:30:28 GMT):
Ok. And is it blake2b512 (which produces a 64byte hash)? Asking because I'm modifying a version of expand_message_xmd that uses sha256...which uses a 32byte hash.

chris.matichuk (Fri, 07 May 2021 04:31:02 GMT):
I'm working on a C version of this.

andrew.whitehead (Fri, 07 May 2021 04:33:31 GMT):
Looks like it’s 64 bytes, expanding the FixedOutputDirty trait here https://docs.rs/blake2/0.9.1/blake2/struct.Blake2b.html

andrew.whitehead (Fri, 07 May 2021 04:36:25 GMT):
The spec here also specifies 512 bits: https://mattrglobal.github.io/bbs-signatures-spec/

chris.matichuk (Fri, 07 May 2021 04:36:57 GMT):
Ahh...yes it does.

chris.matichuk (Fri, 07 May 2021 04:42:58 GMT):
A separate observation. Based on ursa, it appears w in calculating h0...hn should be in serialized form (192 bytes) - the spec doesn't indicate that. Or am I miss-reading something there?

andrew.whitehead (Fri, 07 May 2021 05:06:29 GMT):
Looks like it is the 192 byte uncompressed form, and it doesn’t seem clear to me in the spec either because it’s just concatenating a point to some bytes

chris.matichuk (Fri, 07 May 2021 05:08:39 GMT):
Spec should say point_to_octets_norm(w) or something.

chris.matichuk (Fri, 07 May 2021 05:29:50 GMT):
And "C1 = e(A, w * P2 ^ e)" should be changed to "C1 = e(A, w+P2*e)" - at least that is what I ended up doing to get the verify to work.

chris.matichuk (Fri, 07 May 2021 05:29:50 GMT):
And ```"C1 = e(A, w * P2 ^ e)"``` should be changed to ```"C1 = e(A, w+P2*e)"```- at least that is what I ended up doing to get the verify to work.

chris.matichuk (Fri, 07 May 2021 05:29:50 GMT):
And ```C1 = e(A, w * P2 ^ e)``` should be changed to ```C1 = e(A, w+P2*e)```- at least that is what I ended up doing to get the verify to work.

MALodder (Mon, 10 May 2021 15:17:34 GMT):
Both forms are correct. One form is the multiplicative form and the other is the exponential form

nhwn (Fri, 14 May 2021 04:08:59 GMT):
`libursa` tests should successfully build on ubuntu 20.04 now, please review: https://github.com/hyperledger/ursa/pull/180 (apologies for the delay, I had uni spring exams)

nhwn (Fri, 14 May 2021 04:24:12 GMT):
is this a spurious CI failure? https://ci.appveyor.com/project/ryjones/ursa/builds/39159707

rjones (Fri, 14 May 2021 09:27:46 GMT):
@nhwn yes. I reran it and it passed

ksanjayk (Sat, 15 May 2021 13:40:17 GMT):
Has joined the channel.

cmhacker (Sun, 16 May 2021 13:30:44 GMT):
Has joined the channel.

domwoe (Tue, 18 May 2021 17:33:31 GMT):
In the CL verifier implementation the implementation currently only returns a boolean. As a user I might be interested which attribute (group) / sub proof fails or if it fails because of the primary proof or the non revocation proof. Is there a particular reason why there is not a more expressive/richer output or could we add this?

dgt1nsty (Wed, 19 May 2021 07:09:43 GMT):
@nhwn's latest commits solved my problems too :clap: https://chat.hyperledger.org/channel/ursa?msg=R6RfMw3RmSqpFSPs4

hartm (Wed, 19 May 2021 20:34:39 GMT):
Depending on the application, it might violate a user's privacy if verification reveals which particular thing failed. Revealing too much information about failures has been a notable leakage channel and has been used in cryptanalysis some, so in general the best practice is considered to give as little information about failures as possible.

domwoe (Thu, 20 May 2021 14:13:14 GMT):
Thanks for your comment. I was thinking that these proofs might not be totally independent and if there's a failure in one subproof I can't really verify the others, but if these proofs are independently verifiable I wouldn't agree that we should bet on "privacy by non-implementation". In addition the user decided to share this proof before, so I think in many cases the further interaction between verifier and prover would benefit if the verifier could pin point the reason for failure and communicate this to the prover.

hartm (Thu, 20 May 2021 14:16:42 GMT):
I'm not sure I agree with this. In a good world, proofs should fail for technical reasons extremely rarely. As a user, if, say, I am rejected by a credit algorithm for some purchase, I don't want the verifier to be able to figure out why. "Privacy by non-implementation" could be just "privacy by not giving out extra unnecessary information" which is one of the main tenets of privacy.

hartm (Thu, 20 May 2021 14:16:45 GMT):
Does this make sense?

domwoe (Thu, 20 May 2021 14:25:54 GMT):
I'm just not sure if it helps if one implementation of a verifier does not expose all information contained in a proof. We'd need other cryptographic techniques to achieve this like the user has to calculate the credit algorithm in a zkSnark, such that really only this one bit of information is transferred from prover to verifier.

hartm (Thu, 20 May 2021 14:26:43 GMT):
Do you mind explaining your use case a little bit? Perhaps that will help me understand things better.

domwoe (Thu, 20 May 2021 15:15:15 GMT):
I was wondering in general, based on the following observation :) We are part of a pilot project to implement a digital hotel check-in for business travel. Therefore, you provide a few attributes from a personal ID and a few attributes of a corporate ID. I just implemented the UI of a virtual test hotel where our pilot users can test the "check-in process" and play around with it. So I wanted to show them for example when they try to check-in with a revoked corporate Id that it fails exactly because of this. And I guess the verifier has this information but its just not exposed through the API.

hartm (Thu, 20 May 2021 15:16:05 GMT):
Ah, I see.

hartm (Thu, 20 May 2021 15:17:12 GMT):
The verifier may or may not have that information, though, depending on how you have structured the proof.

hartm (Thu, 20 May 2021 15:18:59 GMT):
If you want this extra information, is there a reason you are not just using multiple proofs (i.e. one for a corporate ID, one for a user ID) and perhaps a proof to tie them together? Maybe it's less efficient to do it this way?

domwoe (Thu, 20 May 2021 15:24:13 GMT):
Non-revocation proof is always additive, isn't it? I should always know if only the proof of non revocation fails for a given cred Def. This would be more effort for the user.

jkrstic (Sat, 22 May 2021 18:12:39 GMT):
Has joined the channel.

MALodder (Sun, 23 May 2021 20:25:39 GMT):
The way its coded in Ursa, you are not given the reason for the failure. The reason could be an invalid signature, invalid data, revoked credential, bad range proof. If any proof fails, they all do

jacobsaur (Wed, 26 May 2021 13:14:16 GMT):
Has joined the channel.

jacobsaur (Wed, 26 May 2021 13:40:52 GMT):
Hi, I'm was wondering if there are any ursa functions for zero knowledge set completeness? I know there are functions for zero knowledge set membership, ie a proof that element x exists in set {x, y, z}. I'm looking to prove that a presented set is complete, eg if given set {x, y, z} it would return true, but if given {x, y} it would return false because there is an element missing. The context is for credit history, where an individual discloses a set of credit credentials and they want to prove they they haven't left anything out of their record (eg the credential that they defaulted on their loan). Let me know if there's any code that already does this, or if anyone knows of a paper that talks about it. Thanks.

hartm (Wed, 26 May 2021 16:40:27 GMT):
Can you define "set completeness" more rigorously? Do you mean "a set must contain elements of type A, B, and C"? Or "a set must include all elements added to some blockchain with property XYZ"? It's hard to answer your question without knowing exactly what you mean by set completeness.

jacobsaur (Wed, 26 May 2021 18:45:32 GMT):
So for my particular use case every element is a verifiable credential, but more generally we could say each element is a string. So just like with cryptographic accumulators you can prove that some string x is in set {x, y, z} without revealing the set before hand, I'd like to prove that a set of strings {x, y, z} isn't missing any elements that should be in it without revealing the set beforehand.

jacobsaur (Wed, 26 May 2021 18:45:32 GMT):
So for my particular use case every element is a verifiable credential, but more generally we could say each element is a string. So just like with cryptographic accumulators you can prove that some string x is in set {x, y, z} without revealing the set before hand, I'd like to prove the opposite where is I present {x, y} that I'm not leaving out z from the set (without revealing the set beforehand).

jacobsaur (Wed, 26 May 2021 18:45:32 GMT):
So for my particular use case every element is a verifiable credential, but more generally we could say each element is a string. So just like with cryptographic accumulators you can prove that some string x is in set {x, y, z} without revealing the set before hand, I'd like to prove the opposite where if I present {x, y} that I'm not leaving out z from the set (without revealing the set beforehand).

hartm (Wed, 26 May 2021 21:47:29 GMT):
I guess my question then is the following: how do I know that z has been added to the set (or accumulator) in the first place? How do I know that z is "supposed to be" in the set?

hartm (Wed, 26 May 2021 21:48:09 GMT):
How do I know what the set is "supposed to look like?"

hartm (Wed, 26 May 2021 21:48:53 GMT):
If you define a set in a rigorous way, you may be able to do this. But you need to define a set as some kind of NP-language.

jacobsaur (Thu, 27 May 2021 10:58:18 GMT):
So maybe it's best if I can describe how I imagine the system to work and then we can figure out how to turn that into formal NP-language. I'll first start with a non-zero knowledge solution. We have an issuer I1 who issues a credential C1 to holder H1. We want this credential to be part of the holder's credit history (ie part of the set) so we also broadcast to a blockchain some data that summarizes what happened (H1->C1). Then let's say a second issuer issues a second credential to the same holder so we broadcast (H1->C2). When H1 wants to have their credit history verified by verifier V1 they can present them credentials in a set {C1, C2}, the verifier can then look at the blockchain and see that H1 should have credentials C1 and C2 in their set and therefore the presented set is complete. The problem with this is that all H1 credentials are public so some snooper verifier V2 could also see that H1 has {C1, C2} without H1 giving V2 permission. Storing the hashes of the credentials would be a bit better, because V1 could be presented {C1, C2} and verify that it matches {hash(C1), hash(C2)} for H1 on the blockchain. That's an improvement, but snooper V2 could still see that something is going on with H1 every time a new hash is added, ie H1 has a new hash added every week and then misses a week V2, could guess that H1 missed a repayment. So I was hoping for a solution something like how credential revocation works with cryptographic accumulators - ie an issuer can revoke a credential and broadcast something to a blockchain in a way that no snooper can tell which credential was revoked or which holder it referred to - it's only when a holder tries to construct a non-revoked proof that the verifier can see that a specific presented credential has been revoked. Is there a way to do that with complete sets, where there's something on the blockchain that issuers can update that would reveal nothing to snoopers, but when a holder goes to present a set, a verifier could set whether the set is complete? Thanks for all the clarifying questions, I hope I've described it well enough.

jacobsaur (Thu, 27 May 2021 10:58:18 GMT):
So maybe it's best if I can describe how I imagine the system to work and then we can figure out how to turn that into formal NP-language. I'll first start with a non-zero knowledge solution. We have an issuer I1 who issues a credential C1 to holder H1. We want this credential to be part of the holder's credit history (ie part of the set) so we also broadcast to a blockchain some data that summarizes what happened (H1->C1). Then let's say a second issuer issues a second credential to the same holder so we broadcast (H1->C2). When H1 wants to have their credit history verified by verifier V1 they can present them credentials in a set {C1, C2}, the verifier can then look at the blockchain and see that H1 should have credentials C1 and C2 in their set and therefore the presented set is complete. The problem with this is that all H1 credentials are public so some snooper verifier V2 could also see that H1 has {C1, C2} without H1 giving V2 permission. Storing the hashes of the credentials would be a bit better, because V1 could be presented {C1, C2} and verify that it matches {hash(C1), hash(C2)} for H1 on the blockchain. That's an improvement, but snooper V2 could still see that something is going on with H1 every time a new hash is added, ie H1 has a new hash added every week and then misses a week V2, could guess that H1 missed a repayment. So I was hoping for a solution something like how credential revocation works with cryptographic accumulators - ie an issuer can revoke a credential and broadcast something to a blockchain in a way that no snooper can tell which credential was revoked or which holder it referred to - it's only when a holder tries to construct a non-revoked proof that the verifier can see that a specific presented credential has been revoked. Is there a way to do that with complete sets, where there's something on the blockchain that issuers can update that would reveal nothing to snoopers, but when a holder goes to present a set, a verifier could tell whether the set is complete? Thanks for all the clarifying questions, I hope I've described it well enough.

jacobsaur (Thu, 27 May 2021 10:58:18 GMT):
So maybe it's best if I can describe how I imagine the system to work and then we can figure out how to turn that into formal NP-language. I'll first start with a non-zero knowledge solution. We have an issuer I1 who issues a credential C1 to holder H1. We want this credential to be part of the holder's credit history (ie part of the set) so we also broadcast to a blockchain some data that summarizes what happened (H1->C1). Then let's say a second issuer issues a second credential to the same holder so we broadcast (H1->C2). When H1 wants to have their credit history verified by verifier V1 they can present them credentials in a set {C1, C2}, the verifier can then look at the blockchain and see that H1 should have credentials C1 and C2 in their set and therefore the presented set is complete. The problem with this is that all H1 credentials are public so some snooper verifier V2 could also see that H1 has {C1, C2} without H1 giving V2 permission. Storing the hashes of the credentials would be a bit better, because V1 could be presented {C1, C2} and verify that it matches {hash(C1), hash(C2)} for H1 on the blockchain. That's an improvement, but snooper V2 could still see that something is going on with H1 every time a new hash is added, ie H1 has a new hash added every week and then misses a week V2, could guess that H1 missed a repayment. So I was hoping for a solution something like how credential revocation works with cryptographic accumulators (https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0011-cred-revocation/README.html) - ie an issuer can revoke a credential and broadcast something to a blockchain in a way that no snooper can tell which credential was revoked or which holder it referred to - it's only when a holder tries to construct a non-revoked proof that the verifier can see that a specific presented credential has been revoked. Is there a way to do that with complete sets, where there's something on the blockchain that issuers can update that would reveal nothing to snoopers, but when a holder goes to present a set, a verifier could tell whether the set is complete? Thanks for all the clarifying questions, I hope I've described it well enough.

hartm (Thu, 27 May 2021 14:04:34 GMT):
Thanks, this was a good description!

hartm (Thu, 27 May 2021 14:05:03 GMT):
If I understand correctly, at an abstract level, you have a blockchain with transactions being posted to it that have some ID associated with them.

hartm (Thu, 27 May 2021 14:06:11 GMT):
You want to be able to prove that a set of credentials contains everything associated with a particular ID (or maybe even something more fine-grained, where you can filter on more things).

hartm (Thu, 27 May 2021 14:11:12 GMT):
This is possible with powerful cryptographic techniques, but I'm not sure it's going to be efficient at all. I don't think you can pull this off with what's in Ursa right now, although maybe you can if you have a very weak security model or tolerate a lot of inefficiency (i.e. the verifier has to scan the whole chain).

hartm (Thu, 27 May 2021 14:11:20 GMT):
What kind of efficiency do you need for this?

hartm (Thu, 27 May 2021 14:11:25 GMT):
And thanks for the interesting discussion?

hartm (Thu, 27 May 2021 14:11:25 GMT):
And thanks for the interesting discussion!

jacobsaur (Thu, 27 May 2021 14:17:02 GMT):
Yes that description sounds right. It doesn't need to be terribly efficient since people are used to credit checks taking awhile, but it should at least be scalable - ie verification times shouldn't get exponentially longer as more transactions get added.

hartm (Thu, 27 May 2021 14:30:56 GMT):
What if verification time scales linearly with the number of transactions on the blockchain (i.e. bad, but far from exponential)?

hartm (Thu, 27 May 2021 14:32:53 GMT):
What you are looking for seems similar in flavor to ABE:

hartm (Thu, 27 May 2021 14:32:57 GMT):
https://eprint.iacr.org/2006/309.pdf

hartm (Thu, 27 May 2021 14:33:24 GMT):
But an ABE-style solution would probably require verification to examine the whole blockchain.

hartm (Thu, 27 May 2021 14:36:23 GMT):
It sounds like what you really want is an "attribute-based accumulator" and to my knowledge, no constant-sized one exists.

jacobsaur (Thu, 27 May 2021 14:44:30 GMT):
Interesting paper. Ya even scaling linearly would probably become problematic over time, especially as the number of users grows (ie a single users share of the whole blockchain will get much smaller over time). An attribute-based accumulator sounds interesting...

hartm (Thu, 27 May 2021 15:34:38 GMT):
I'm not sure there are even research solutions for this problem yet.

jacobsaur (Thu, 27 May 2021 15:59:56 GMT):
Gotcha, that's what I was afraid of. Thanks for thinking it through with me though!

hartm (Thu, 27 May 2021 16:00:18 GMT):
Yep, of course!

hartm (Thu, 27 May 2021 16:00:34 GMT):
If you're willing to have weaker privacy properties, you may be able to do things with searchable encryption.

hartm (Thu, 27 May 2021 16:00:44 GMT):
But it all depends on what privacy guarantees you need.

hartm (Thu, 27 May 2021 16:01:11 GMT):
I may also pitch "attribute-based accumulator" as a research problem.

jacobsaur (Thu, 27 May 2021 16:01:28 GMT):
Are there searchable encryption functions in ursa currently?

hartm (Thu, 27 May 2021 20:31:55 GMT):
No. Searchable encryption is not currently used in any blockchain applications of which I'm aware.

da3v21 (Tue, 01 Jun 2021 05:23:16 GMT):
Hi everyone! *MATTR* proposed a way to implement onetime usable credentials using BBS+ signatures(*Domain proofs*). Is this implemented anywhere?

hartm (Tue, 01 Jun 2021 06:13:12 GMT):
You should ask @MALodder .

MALodder (Tue, 01 Jun 2021 13:47:53 GMT):
here's the domain proof POC https://github.com/mikelodder7/commit_twin

MALodder (Tue, 01 Jun 2021 13:52:40 GMT):
I implemented it in go and rust

da3v21 (Tue, 01 Jun 2021 14:08:02 GMT):
Thanks a lot,will look into it

da3v21 (Wed, 02 Jun 2021 07:08:51 GMT):
Is this implemented in Aries go or Acapy?

pritam_01 (Thu, 03 Jun 2021 05:03:38 GMT):
Has joined the channel.

da3v21 (Mon, 07 Jun 2021 14:45:10 GMT):
Hi, Where can I find the math and code of Multi credential proofs using CL signatures.

brentzundel (Mon, 07 Jun 2021 15:59:22 GMT):
With the global forum, will there still be an Ursa call this week?

Maheshbalan (Tue, 08 Jun 2021 17:39:08 GMT):
Has joined the channel.

Maheshbalan (Tue, 08 Jun 2021 17:39:08 GMT):
Hello, from the talk in HGF, I was asked to post here to request links to the work being done on Threshold Signatures. Greatly appreciated if you you could post here.

danyam (Tue, 08 Jun 2021 17:43:49 GMT):
Has joined the channel.

MALodder (Tue, 08 Jun 2021 17:44:08 GMT):
@brentzundel I suggest we cancel the Ursa call tomorrow due to HLGF

MALodder (Tue, 08 Jun 2021 17:47:53 GMT):
https://github.com/hyperledger/ursa-docs/tree/main/specs

MALodder (Tue, 08 Jun 2021 17:48:26 GMT):
No

hartm (Tue, 08 Jun 2021 17:48:51 GMT):
I agree.

hartm (Tue, 08 Jun 2021 17:48:55 GMT):
I'll send out a mail.

hartm (Tue, 08 Jun 2021 17:49:41 GMT):
@MALodder would you mind posting your github link here? Thanks!

MALodder (Tue, 08 Jun 2021 17:50:35 GMT):
I’ve just posted the building blocks for threshold. Haven’t posted the code yet

MALodder (Tue, 08 Jun 2021 17:51:01 GMT):
https://GitHub.com/mikelodder7/paillier-ra

MALodder (Tue, 08 Jun 2021 17:51:01 GMT):
https://GitHub.com/mikelodder7/paillier-rs

Jasonyou (Tue, 08 Jun 2021 18:56:59 GMT):
Has joined the channel.

hartm (Tue, 08 Jun 2021 23:13:38 GMT):
@here Reminder that we are cancelling tomorrow's meeting due to the HGF. If you are available, there is a very interesting session you can attend at the same time: https://sched.co/jgNW

da3v21 (Wed, 09 Jun 2021 02:12:06 GMT):
@MALodder I went through this, at which step do we prove two credentials have the same link secret?

da3v21 (Wed, 09 Jun 2021 02:17:41 GMT):
each subproof has an m_tilde for the link secret https://github.com/hyperledger/ursa/blob/main/libursa/src/cl/prover.rs#L851 , I'm not able to find where they prove that m_tildes have the same link secret

MALodder (Wed, 09 Jun 2021 16:50:14 GMT):
because there is a schnorr proof that is the same for all the subproofs. because its the same you can assume the equality

da3v21 (Thu, 10 Jun 2021 01:11:34 GMT):
Got it!, How do we implement this? https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/zkp-safety.md#technique-2-prevent-link-secret-reuse.

da3v21 (Thu, 10 Jun 2021 06:43:34 GMT):
this step to be precise, given g1xg2yg3z and h1xh2r, it can be proved that x in both of them is same without revealing x, y, z or r

da3v21 (Thu, 10 Jun 2021 06:43:34 GMT):
@MALodder this step to be precise, given g1xg2yg3z and h1xh2r, it can be proved that x in both of them is same without revealing x, y, z or r

MALodder (Mon, 14 Jun 2021 13:43:40 GMT):
you can use this technique https://github.com/mikelodder7/commit_twin

davidv1992 (Fri, 18 Jun 2021 20:05:54 GMT):
Has joined the channel.

davidv1992 (Fri, 18 Jun 2021 20:14:43 GMT):
I have been diving into the ursa CL crypto lately, and while I understand most of the functionality around the CL public and private keys, I have some trouble figuring out what CredentialKeyCorrectnessProof is a proof of. Where can I find the mathematical background of what that proof shows?

SIDDHARTHJAIN (Fri, 18 Jun 2021 21:16:05 GMT):
Has joined the channel.

SIDDHARTHJAIN (Fri, 18 Jun 2021 21:16:05 GMT):
Hey Everyone! I wanted to implement ZKPs for a project using ursa, so wanted to know if there is some project which could be used as a reference. Thanks

SIDDHARTHJAIN (Fri, 18 Jun 2021 21:42:17 GMT):
Just wanted to know, if there is something that could help implement the ZKPs in my project. Please help if you can, highly appreciated. Thanks

hartm (Fri, 18 Jun 2021 22:36:50 GMT):
Have you looked at the bulletproofs implementation?

dgt1nsty (Sat, 19 Jun 2021 06:12:07 GMT):
Hey everyone I wanted to do benchmark test on libursa but benchmarking on cvk_revok.rs file give some scoping issues that I couldn't get around. Do anyone know to solve it or if anyone has any suggestion it would be welcomed. Thanks in advance.

dgt1nsty (Sat, 19 Jun 2021 06:12:07 GMT):
Hey everyone I wanted to do benchmark test on libursa but benchmarking on cvk_revok.rs file give some scoping issues that I couldn't get around. I put the issue I'm getting below. Do anyone know to solve it or if anyone has any suggestion I would be welcomed. Thanks in advance.

dgt1nsty (Sat, 19 Jun 2021 06:12:07 GMT):
Hey everyone I wanted to do benchmark test on libursa but benchmarking on cvk_revok.rs file give some scoping issues that I couldn't get around. I put the issue I'm getting below. Do anyone know to solve it or if anyone has any suggestion I would be welcome. Thanks in advance.

dgt1nsty (Sat, 19 Jun 2021 06:12:07 GMT):
Hey everyone I wanted to do benchmark test on libursa but benchmarking on cvk_revok.rs file give some scoping issues that I couldn't get around. I put the issue I'm getting in below. Do anyone know to solve it or if anyone has any suggestion I would be welcome. Thanks in advance.

dgt1nsty (Sat, 19 Jun 2021 06:12:07 GMT):
Hey everyone I wanted to do benchmark test on libursa but benchmarking on cvk_revok.rs file give some scoping issues that I couldn't get around. I put the issue I'm getting in below. If anyone know to solve it or has any suggestion I would be welcome. Thanks in advance.

dgt1nsty (Sat, 19 Jun 2021 06:12:07 GMT):
Hey everyone I wanted to do benchmark test on libursa but benchmarking on cks_revok.rs file give some scoping issues that I couldn't get around. I put the issue I'm getting in below. If anyone know to solve it or has any suggestion I would be welcome. Thanks in advance.

dgt1nsty (Sat, 19 Jun 2021 06:12:57 GMT):

benchmark_prob.png

SIDDHARTHJAIN (Sat, 19 Jun 2021 06:59:46 GMT):
Is it the ursa implementation, i.e., ursa/libzmix/bulletproofs_amcl that you are referring to

SIDDHARTHJAIN (Sat, 19 Jun 2021 06:59:46 GMT):
Is it the ursa implementation, i.e., ursa/libzmix/bulletproofs_amcl that you are referring to? And does this implementation makes sures that the prover does not generate a fake proof for a certain attribute? Thanks

dgt1nsty (Sat, 19 Jun 2021 07:02:55 GMT):
Here is the issue I'm getting

dgt1nsty (Sat, 19 Jun 2021 07:03:16 GMT):

benchmark_prob.png

hartm (Sat, 19 Jun 2021 19:04:27 GMT):
The prover not being able to generate a false proof is called "prover soundness" and is a property of all secure zero knowledge proofs.

hartm (Sat, 19 Jun 2021 19:05:40 GMT):
Yes, that is the implementation. We've listed everything implemented on the main github page, https://github.com/hyperledger/ursa.

SIDDHARTHJAIN (Sun, 20 Jun 2021 06:27:06 GMT):
Thanks a lot!

SIDDHARTHJAIN (Sun, 20 Jun 2021 11:57:55 GMT):
Hey! I had one more doubt. Does this code makes sure that the one who is generating the proof(the prover) will generate a proof for his real age and not a fake one, given that the prover has a verifiable claim for his age. As while I was going through the tests of bulletproofs, I didn't find anything related to verifiable claims, it looked like a proof for 3 randomly generated numbers. Thanks. Highly appreciate the help.

SIDDHARTHJAIN (Sun, 20 Jun 2021 15:02:20 GMT):
Hey! I had one more doubt. Does this code makes sure that the one who is generating the proof(the prover) will generate a proof for his real age and not a fake one, given that the prover has a verifiable claim for his age. As while I was going through the tests of bulletproofs, I didn't find anything related to verifiable claims, it looked like a proof for 3 randomly generated numbers. Thanks. Highly appreciate the help.

hartm (Sun, 20 Jun 2021 17:02:20 GMT):
Just think about what you want to prove. You want to prove a statement of the form "I have a verifiable claim that my age is > XXXX" not just a statement about numbers.

SIDDHARTHJAIN (Sun, 20 Jun 2021 20:23:32 GMT):
Does this library allows us to prove these kind of statements. As in the tests section of bulletproofs, I could only see proofs for numbers. I'm sorry, my questions might be dumb.

SIDDHARTHJAIN (Sun, 20 Jun 2021 20:27:17 GMT):
Like I was going through the Sovrin Foundation's DID docs, which said that they implemented this verifiable claims (using ZKP) from ursa library.

SIDDHARTHJAIN (Mon, 21 Jun 2021 15:35:53 GMT):
So, yes I just wanted to know if there is some implementation for "Bulletproofs(for ranges) for verifiable claims", similar to that statement that you said. Thanks

hartm (Mon, 21 Jun 2021 23:57:06 GMT):
I'd recommend looking through the Indy/Sovrin docs on how they use ZKPs.

hartm (Mon, 21 Jun 2021 23:57:29 GMT):
We could certainly improve our documentation on use cases.

tarou.y6666 (Wed, 23 Jun 2021 05:30:58 GMT):
Has joined the channel.

rjones (Wed, 30 Jun 2021 15:13:52 GMT):
@hartm I noticed Ursa doesn't have anyone on security@hyperledger - who should I add? Also, I have a security report for Ursa, who should I loop in?

hartm (Wed, 30 Jun 2021 15:20:07 GMT):
Maybe add Mike Lodder and I? If the report is implementation-based in nature, it's probably best to go to Mike. If it's mathematical, you can send it to me. It also depends on which part of the codebase the report is on.

hartm (Wed, 30 Jun 2021 15:20:11 GMT):
Sorry for the complicated answer.

hartm (Wed, 30 Jun 2021 15:20:43 GMT):
Some of the code the Aries folks may want to be looped in as well.

rjones (Wed, 30 Jun 2021 15:27:12 GMT):
```Specifically, the CredentialKeyCorrenctnessProof as generated by _new_credential_key_correctness_proof (in the libursa/src/cl/issuer.rs file) incorrectly uses randomizers generated in the range [3,p*q-1], resulting in a compromise of the zero-knowledge properties of this proof. As a result, based on such a proof, an attacker can efficiently derive the following information for the bases given in the public key: - Approximately the top 256 bits of the discrete log of Z with respect to S. - Approximately the top 256 bits of the discrete log of R[i] with respect to S.```

gaberasturi (Fri, 02 Jul 2021 11:31:29 GMT):
Has joined the channel.

cam-parra (Wed, 07 Jul 2021 19:38:58 GMT):
Anyone have any clue why my tests aren't running for ursa core?

cam-parra (Wed, 07 Jul 2021 19:39:00 GMT):
https://github.com/mac-arrap/ursa/tree/ursa_core

cam-parra (Wed, 07 Jul 2021 19:39:12 GMT):
pretty sure I've structured it out correctly

ianco (Wed, 07 Jul 2021 21:31:22 GMT):
I think you need to check them in on the `main` branch

MALodder (Thu, 08 Jul 2021 16:04:51 GMT):
Are they included in the tests folder or reachable by lib.rs

rjones (Mon, 19 Jul 2021 23:04:15 GMT):
Howdy - RSA submissions are due this week - if anyone wants to submit a talk, Hyperledger can help: https://www.rsaconference.com/

DirkT (Mon, 26 Jul 2021 08:54:34 GMT):
Has joined the channel.

Dan (Wed, 04 Aug 2021 14:05:01 GMT):
Recently returned from annual contributor search: https://photos.app.goo.gl/DJrvWzowcuUH7BXj7

hartm (Wed, 04 Aug 2021 17:01:13 GMT):
Looks hungry! What a shame they didn't eat better that day ;)

rjones (Wed, 04 Aug 2021 18:35:52 GMT):
I live near Bear Creek. People are amazed - AMAZED! - that we've had juvenile bears running around this year

Dan (Wed, 04 Aug 2021 20:55:17 GMT):
Clearly they've been disappointed by misleadingly named creeks before. Finally #truthinadvertising

rjones (Wed, 04 Aug 2021 21:11:08 GMT):

IMG_0223.jpeg

brian.richter (Mon, 09 Aug 2021 21:54:52 GMT):
Has joined the channel.

brian.richter (Mon, 09 Aug 2021 21:54:52 GMT):
hi all, are the meetings still being recorded? this list hasnt been updated since 2020 https://wiki.hyperledger.org/display/ursa/Meeting+Recordings

hartm (Tue, 10 Aug 2021 03:47:47 GMT):
I have some of them, although zoom crashing has lost a bunch of them. Is there anyone in particular you want me to look for?

brian.richter (Tue, 10 Aug 2021 08:51:00 GMT):
2021-08-04

hartm (Tue, 10 Aug 2021 16:32:07 GMT):
OK, try this link: https://wiki.hyperledger.org/display/ursa/2021-08-04

hartm (Tue, 10 Aug 2021 16:32:16 GMT):
I had a couple of wiki issues but hopefully that should work.

brian.richter (Tue, 10 Aug 2021 17:57:31 GMT):
excellent, thank you very very much!

hartm (Tue, 10 Aug 2021 18:47:55 GMT):
No worries! I need to be better about taking care of these things.

jaromil (Sat, 14 Aug 2021 09:20:08 GMT):
Has left the channel.

dgt1nsty (Mon, 16 Aug 2021 07:45:53 GMT):
hello everyone, can someone tell me the difference between the GVT credential and the XYZ credential found as a document comment in the libursa integration test file?

eadventurous (Thu, 19 Aug 2021 12:25:17 GMT):
Can someone suggest an iOS library compatible with ed25519 signature algorithm that is provided by ursa?

tomislav (Fri, 20 Aug 2021 21:46:55 GMT):
https://github.com/trinsic-id/okapi/tree/main/objc This library works exposes `did:key` functionality, but it supports full Ed25519 signatures, even X25519 if you want to do key exchange. I'm the author, happy to help you with any usage.

tomislav (Fri, 20 Aug 2021 21:46:55 GMT):
https://github.com/trinsic-id/okapi/tree/main/objc This library exposes `did:key` functionality, but it supports full Ed25519 signatures, even X25519 if you want to do key exchange. I'm the author, happy to help you with any usage.

tomislav (Fri, 20 Aug 2021 21:48:22 GMT):
This library is not provided by Ursa, however.

tomislav (Fri, 20 Aug 2021 21:48:22 GMT):
This library is not provided by Ursa. It uses dalek crypto - https://github.com/dalek-cryptography/ed25519-dalek. The Okapi library uses Ursa for the BLS key types.

andrew.whitehead (Fri, 20 Aug 2021 21:53:15 GMT):
I think you can also use the built-in CryptoKit framework?

tomislav (Fri, 20 Aug 2021 22:12:07 GMT):
Actually, great point, and better option. They added support for it in 2020. https://developer.apple.com/documentation/cryptokit/curve25519

brentzundel (Fri, 27 Aug 2021 15:36:27 GMT):
I've been asked to create a tag and release a new version of ursa that includes recent changes. @MALodder or @Dan can folks give me guidance on how to do this? Is there any reason I shouldn't?

tomislav (Sun, 29 Aug 2021 12:54:39 GMT):
The `bbs` crate no longer compiles, due to yanked version of the `crypto-mac` crate ``` error: failed to select a version for the requirement `crypto-mac = "^0.7"` candidate versions found which didn't match: 0.11.1, 0.11.0, 0.10.1, ... location searched: crates.io index required by package `blake2 v0.8.1` ```

MALodder (Tue, 31 Aug 2021 15:28:46 GMT):
none go ahead

MALodder (Tue, 31 Aug 2021 15:28:54 GMT):
you use `cargo publish` to do this

brentzundel (Wed, 01 Sep 2021 14:01:15 GMT):
I've been pulled into a meeting where I need to pay attention and participate, so I can't join the Ursa call today even though that's where I'd rather be.

hartm (Wed, 01 Sep 2021 23:26:34 GMT):
We missed you, but understand!

rjones (Fri, 03 Sep 2021 14:34:26 GMT):
Looks like there is a PR needed to fix builds: https://github.com/hyperledger/ursa/pull/190

rjones (Fri, 03 Sep 2021 14:40:55 GMT):
thank you @brentzundel

rjones (Fri, 03 Sep 2021 15:49:51 GMT):
@MALodder could you add me as an owner here, please? https://crates.io/crates/ursa

MALodder (Fri, 03 Sep 2021 17:30:55 GMT):
sure

MALodder (Fri, 03 Sep 2021 17:32:56 GMT):
what's your user on crates.io

rjones (Fri, 03 Sep 2021 17:58:58 GMT):
ryjones

rjones (Fri, 03 Sep 2021 18:00:07 GMT):

Screen Shot 2021-09-03 at 11.00.00 AM.png

rjones (Fri, 03 Sep 2021 18:02:14 GMT):
@MALodder if you could merge https://github.com/hyperledger/ursa/pull/190 as well, that would be great

MALodder (Fri, 03 Sep 2021 18:02:50 GMT):
invite sent

rjones (Fri, 03 Sep 2021 18:03:23 GMT):
thank you, accepted

MALodder (Fri, 03 Sep 2021 18:03:36 GMT):
merged

rjones (Fri, 03 Sep 2021 18:05:14 GMT):
thanks. I assume I need to bump the version to the next 0.3 number and release?

hartm (Wed, 15 Sep 2021 14:12:18 GMT):
Differential privacy: https://medium.com/georgian-impact-blog/a-brief-introduction-to-differential-privacy-eacf8722283b

brentzundel (Wed, 15 Sep 2021 14:46:04 GMT):
yes please

rjones (Wed, 15 Sep 2021 19:08:54 GMT):
@brentzundel I tagged you over on github. please don't _just do it_, I want to get this action working and merged so we don't have to beg one of the people that knows how to do it, to do it

brentzundel (Wed, 15 Sep 2021 19:25:51 GMT):
I totally agree that setting up an automated process is way better. I don't have good guidance for you, but have reached out to @MALodder in hopes that he can chime in.

regiseloi (Wed, 15 Sep 2021 21:39:29 GMT):
Has joined the channel.

rjones (Wed, 15 Sep 2021 22:56:17 GMT):
OK. If you can help me get past the `ffi` error I can keep pushig

rjones (Thu, 16 Sep 2021 02:39:35 GMT):
@brentzundel @hartm if I could get a +1 here: https://github.com/hyperledger/ursa/pull/191

igorkrupczynski (Thu, 16 Sep 2021 10:16:54 GMT):
Has joined the channel.

rjones (Thu, 16 Sep 2021 16:52:41 GMT):
OK. https://github.com/hyperledger/ursa/pull/191 has been updated by @Dan with the inclusion of release notes - please smash like and subscribe so I can get this published this week

hartm (Wed, 29 Sep 2021 14:05:00 GMT):
https://github.com/hyperledger/ursa/pull/192

hartm (Wed, 27 Oct 2021 05:48:01 GMT):
@here We are cancelling the upcoming call due to the member summit. Talk to you all at the next meeting (if not before)!

brian.richter (Fri, 29 Oct 2021 17:32:22 GMT):
Can anybody help me get the portable build working? https://github.com/hyperledger/ursa/issues/193

kukgini (Thu, 04 Nov 2021 08:38:27 GMT):
Has left the channel.

MALodder (Mon, 08 Nov 2021 21:14:03 GMT):
Brian I can tomorrow. Still recovering from surgery and haven’t been able to do much. Finally ramping back up

lmtriet (Tue, 09 Nov 2021 10:55:49 GMT):
Hi, I have problems with the portable build for libzmix/libursa also. I am able to fix sha2 upgrade from 0.8->0.9 and amcl dependencies. But for the k256 migration related errors in /ursa/libursa/src/signatures/secp256k1.rs, the code changes are too important for my understanding. Any expert look at the issue will be great. Thank you!

ChangmingLiu (Thu, 11 Nov 2021 02:09:58 GMT):
Has joined the channel.

ChangmingLiu (Thu, 11 Nov 2021 02:09:59 GMT):
Hi guys, appreciate the works there. Sorry to interrupt but It looks like current ursa implementation only supports zero knowledge range proof, is there any plan or implementation to support set membership proof? Any pointer is appreciated, thanks!

hartm (Thu, 11 Nov 2021 04:35:28 GMT):
You may be interested in this: https://github.com/hyperledger/ursa/pull/192. It's not formally added yet, but it allows general ZK proofs. Also, for set membership proofs, are you sure that you just don't want to use an accumulator?

hartm (Thu, 11 Nov 2021 04:35:34 GMT):
Thanks for your interest!

ChangmingLiu (Thu, 11 Nov 2021 18:44:38 GMT):
Of course! Thank you for the pointer, I'll have a look. ``` ``` yes, accumulators like merkle tree or RSA accumulator can be very helpful (anything that does the trick). And yes, I saw related ZKP code in libzmix about these, but forgive me for failing to see an apparent way to apply them to the protocol in libursa e.g., how to ZK set membership proof about a value certified from the issuer. I guess perhaps you're refering to section 7.2 in https://wiki.hyperledger.org/download/attachments/6426712/Anoncreds2.1.pdf ? I'm wondering why this is not integrated into libursa(since when the verifier is sending predicate on a proof request, only <=, >= are supported.) The protocol in anoncred v2.0 looks very promising, has this been implemented somewhere? otherwise, I'd love to help with integrating this.

uvdsl (Mon, 22 Nov 2021 18:05:05 GMT):
Has joined the channel.

aso (Tue, 23 Nov 2021 16:02:33 GMT):
Has joined the channel.

aso (Tue, 23 Nov 2021 16:03:00 GMT):
Hi folks, I have seen different BBS implementations here and there but none seem to implement the complete suite describe in https://github.com/hyperledger/ursa-docs/tree/main/specs/anoncreds2 Is that a correct statement? If not, I'd be grateful if anyone could point me the right way. Thx in advance!

swcurran (Tue, 23 Nov 2021 18:32:38 GMT):
Answered on another channel -- basic answer -- BBS+ does not have the same features as AnonCreds. Just noticed that you were mentioning AnonCreds 2 -- that also does not exist.

swcurran (Tue, 23 Nov 2021 18:33:14 GMT):
BBS+ does not have the features in AnonCreds v1.

aso (Tue, 23 Nov 2021 20:06:08 GMT):
thx @swcurran

aso (Tue, 23 Nov 2021 20:07:15 GMT):
and when you say BBS+ I guess you are referring to https://identity.foundation/bbs-signature/ right?

aso (Tue, 23 Nov 2021 20:09:22 GMT):
because this https://eprint.iacr.org/2016/663 and references show how to prove knowledge of a BBS+ sig that also includes link secrets

aso (Tue, 23 Nov 2021 20:11:28 GMT):
and this https://github.com/IBM/idemix/ implements it

swcurran (Tue, 23 Nov 2021 20:57:11 GMT):
Not to say link secrets can't be done using BBS+ Signatures sometime in the future. Rather, to say that it can't be done today, and AFAIK, there is no one working on making that happen.

aso (Wed, 24 Nov 2021 07:15:08 GMT):
gotcha - thx again @swcurran !

wip-abramson (Wed, 24 Nov 2021 09:39:08 GMT):
Interesting. So all BBS+ credentials currently include a DID as the subject which the holder has to disclose to prove the credential was issued to them? Surely this compromises the fundamental reason these signature schemes were initially developed for - to support unlinkable presentations of credentials across multiple interactions?

aso (Wed, 24 Nov 2021 11:09:10 GMT):
indeed.. what you still achieve is selective disclosure, so one does not have to disclose all the certified attributes. This may or may not be enough - given the threat model of the scenario

aso (Wed, 24 Nov 2021 11:10:40 GMT):
surely over time, a set of colluding verifiers could do a nifty bit of profiling and reconstruct all attributes of a holder

swcurran (Wed, 24 Nov 2021 14:59:42 GMT):
@wip -- I agree with you. There is a spec for BBS+ Bound Signatures that was written, but it hasn't been implemented and so is theoretical at this point. W3C VCs are very complex to deploy, so I think anyone using BBS+ is focused on just trying to get it to work -- to get JSON-LD behaving in a reasonable way. We've found it very frustrating.

aso (Wed, 24 Nov 2021 15:30:02 GMT):
the steps of i) having the issuer sign some commitment to a client secret and of ii) having the holder prove knowledge of that secret are not particularly complex, so I'm guessing the complexity lies elsewhere. @swcurran do you know what they might be?

swcurran (Wed, 24 Nov 2021 15:32:35 GMT):
Tobias Looker has presented a plan for doing the binding, but it has not been implemented. Basically, the holder provide a public key to the issuer, and that gets used. It seemed reasonable, but it has never AFAIK been implemented. Not sure why.

swcurran (Wed, 24 Nov 2021 15:33:52 GMT):
We'd like to see it go a lot further -- to include the features of AnonCreds (e.g. ZKP revocation at least, and ideally predicates) -- so even the BoundProof approach is not the best.

aso (Wed, 24 Nov 2021 15:49:44 GMT):
right, that does sound reasonable

aso (Wed, 24 Nov 2021 15:50:32 GMT):
I thought actually that DIDcomm would have issues with the fact that at that point, the DID of the subject would no longer have to be included in the presentation

tgalal (Mon, 06 Dec 2021 09:16:53 GMT):
Has joined the channel.

tgalal (Mon, 06 Dec 2021 09:46:54 GMT):
Hey all. I was trying to find out what cryptographic construction is used in `CL` for forming the `aggregated_proof.c_hash` and `aggregated_proof.c_list`? And do I get it right that the purpose of aggregated proof is to ensure that the proofs being verified were in fact generated together?

hartm (Mon, 06 Dec 2021 17:47:28 GMT):
An aggregated proof is usually a way of creating one proof that captures several other different proofs. This can save on verification time and particularly proof space. I'm not sure entirely what you mean by "generated together," sorry.

SeanBohan (Fri, 17 Dec 2021 20:06:30 GMT):
Has joined the channel.

a-p-petrosyan (Wed, 22 Dec 2021 08:12:34 GMT):
Has joined the channel.

a-p-petrosyan (Wed, 22 Dec 2021 08:12:34 GMT):
Hi! I'm An Iroha 2 core developer and we wanted to bump the `ursa` version from `0.3.7` to `0.5.0`. Is there anything that we should watch out for?

hartm (Wed, 22 Dec 2021 14:36:27 GMT):
@here No meeting today due to the holidays! Thanks!

hartm (Wed, 22 Dec 2021 14:36:51 GMT):
I don't think so? Others may have opinions, but unfortunately I think most people are out for the holidays.

hartm (Wed, 22 Dec 2021 14:36:51 GMT):
Deleted for wrong comment.

hartm (Wed, 22 Dec 2021 14:37:36 GMT):
I don't think so? Others may have opinions, but unfortunately I think most people are out for the holidays.

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that the prover splits delta into sum of four squares, creates a Pedersen commitment over each of those as well as the delta, and begins a ZKP for the commited values and the associated commitment secret. What I do not get is the purpose of: $$ Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}}) $$ Would appreciate hints on why this computation is necessary in the proof.

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that the prover splits delta into sum of four squares, creates a Pedersen commitment over each of those as well as the delta, and begins a ZKP for the commited values and the associated commitment secret. What I do not get is the purpose of: \ Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}}) \ Would appreciate hints on why this computation is necessary in the proof.

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that the prover splits delta into sum of four squares, creates a Pedersen commitment over each of those as well as the delta, and begins a ZKP for the commited values and the associated commitment secret. What I do not get is the purpose of: \[ Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}}) \] Would appreciate hints on why this computation is necessary in the proof.

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that the prover splits delta into sum of four squares, creates a Pedersen commitment over each of those as well as the delta, and begins a ZKP for the commited values and the associated commitment secret. What I do not get is the purpose of: \[ $$ Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}}) $$ \] Would appreciate hints on why this computation is necessary in the proof.

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that the prover splits delta into sum of four squares, creates a Pedersen commitment over each of those as well as the delta, and begins a ZKP for the commited values and the associated commitment secret. What I do not get is the purpose of: \[Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}})\] Would appreciate hints on why this computation is necessary in the proof.

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that the prover splits delta into sum of four squares, creates a Pedersen commitment over each of those as well as the delta, and begins a ZKP for the commited values and the associated commitment secret. What I do not get is the purpose of: \[Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}})\] Would really appreciate any hints on why this computation is necessary in the proof if someone knows. Thanks!

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that for a predicate the prover splits delta into the sum of four squares, creates a Pedersen commitment for each of those four components as well as the delta, and begins a ZKP for the commited values and the associated commitment secrets. What I do not get is the purpose of: \[Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}})\] Would really appreciate any hints on why this computation is necessary in the proof if someone knows. Thanks!

tgalal (Sat, 08 Jan 2022 20:49:50 GMT):
Hi, I'm trying to understand how inequality proofs in anoncreds 1 work. So far what I've gathered is that for a predicate the prover splits delta into the sum of four squares, creates a Pedersen commitment for each of those four components as well as the delta, and begins a ZKP for each of the commited values and associated commitment secret. What I do not get is the purpose of: \[Q \leftarrow (S ^{\widetilde{\alpha}}) \prod_{i=1}^{4} T_i^{\widetilde{u_i}})\] Would really appreciate any hints on why this computation is necessary in the proof if someone knows. Thanks!

andrew.whitehead (Mon, 10 Jan 2022 20:21:59 GMT):
What's the reference for this?

WadeBarnes (Thu, 13 Jan 2022 14:51:44 GMT):
Has joined the channel.

RobinKlemens (Thu, 13 Jan 2022 15:26:19 GMT):
Has joined the channel.

RobinKlemens (Thu, 13 Jan 2022 15:27:48 GMT):
Hey folks, I'm Robin from the folks at Hyperledger Indy. Can anybody tell me the process of getting a new version of `hyperledger/python-ursa` pushed to `pypi`? The version of `python-ursa` is at version `0.1.1` and `hyperledger/ursa` is at version `0.3.7`

tgalal (Fri, 14 Jan 2022 10:11:45 GMT):
https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0109-anoncreds-protocol/README.html#validity-proof right above Hashing

tgalal (Fri, 14 Jan 2022 10:12:16 GMT):
and it's implemented by ursa

sbohanlf (Wed, 19 Jan 2022 14:56:53 GMT):
Has joined the channel.

VenessaK (Mon, 24 Jan 2022 14:14:10 GMT):
Has joined the channel.

mzago (Mon, 31 Jan 2022 14:26:57 GMT):
Has joined the channel.

mzago (Mon, 31 Jan 2022 14:28:25 GMT):
Hello, following also my post in #indy I am still looking at specific technical information regarding the key derivation mechanisms for both the wallet and the various agents communication channels. Is there any resource available beside the blog posts?

hartm (Mon, 31 Jan 2022 18:34:25 GMT):
You may also want to look at Aries. Ursa is a cryptographic library, so it contains all the cryptographic protocols themselves. Aries has the wallet software and makes the protocol calls. Which layer interests you? Do you have any specific requirements for key derivation?

mzago (Tue, 01 Feb 2022 08:43:16 GMT):
Hello, yes, I am also looking at Aries as, eventually, I'll have to figure out the keys derivation process for DID to DID communication. So far, however, I am looking at the process of deriving a key from the seed, which I understand is based on PBKDF2. I also understand that the DID is cryptographically associated with a private key derived from the seed itself, so I guess there should be a specific and deterministic way to obtain the pk and the corresponding DID via a key derivation process. Would you please provide some insight or documentation on this? Furthermore, I'm having doubts about selecting the prime numbers p and q. In the documentation, it is stated that: Random 1536-bit primes $p',q'$ such that $p \leftarrow 2p'+1$ and $q \leftarrow 2q'+1$ are primes too. Then compute $n \leftarrow pq$ Aren't these restrictions too strong? In other words, where can I find information about why such primes must belong to that prices space?

hartm (Tue, 01 Feb 2022 18:39:58 GMT):
1. Yes, when you create a secret key you can also create a public key. If you look at the API, look for functions called KeyGen.

hartm (Tue, 01 Feb 2022 18:41:52 GMT):
2. Those restrictions on the primes are unfortunately necessary. You need prime-order subgroups and a "main" group that is a strong composite order group. If you're willing to get technical, going through the proof in (https://dominoweb.draco.res.ibm.com/reports/rz3730_revised.pdf) might be a good way to see why this is the case.

jacobgorman613 (Tue, 01 Feb 2022 22:19:13 GMT):
Has joined the channel.

jacobgorman613 (Tue, 01 Feb 2022 22:19:13 GMT):
does anyone have any recommendations for generating a header for the FFI::CL module? I tried using libcgen which seems to be what most people use but libcgen struggles with the module structure and repeated names. Thanks!

mzago (Wed, 02 Feb 2022 16:04:27 GMT):
Thank you. I will have a look at those.

hartm (Thu, 03 Feb 2022 01:44:38 GMT):
Awesome! Glad to help.

rjones (Fri, 11 Feb 2022 20:20:58 GMT):
this discussion has moved to https://discord.gg/hyperledger