rategy shall be implemented in full prior to the first use of the buildings and maintained in perpetuity the reason I'm suggesting that this would be a condition rather than section 106 is because if the opportunity for the applicant to investigate with the County Council how such a strategy could be implemented what the cost would be and for that to be agreed through a section 278 agreement rather than a section 106 agreement so that would be an agreement between the applicant and the County Council to undertake works on the public highway and yes so that's the recommended condition if members did want to include such a condition for myself I think that would be satisfactory because clearly before this could be implemented we have to get the buy-in of the County Council as well so I will happily have more thought on this when we come to the Council of Rippith's amendments but those are the comments I wanted to make at this stage next we have Councillor Roberts and just to go back I mean Council of Rippith did ask when amendments could come forward and you know there isn't a specific time they could come forward at any part of the debate so Councillor Rippith do you want to mention what those amendments were sorry Councillor Roberts I just realised I hadn't answered her second question there no problem I can re-mention then so the first one as Councillor Batch has just covered active and monitored CCTV on the E10 bridge and I'm personally happy with the condition suggested by Chris Carter and the second one was in in the fullness of time when we have a decision on the E10's future so whether it's dueled online or offline a new wider and in my opinion safer bridge to replace the 1970 structure that is currently there and I mentioned the other reasons for that earlier do you want me to repeat fine so just this is if minded to approve these are the conditions or amendments in some way that you would like to see so condition you'd be happy of that being a condition rather than S106 we can come to that later in the debate I don't know if Chris Carter wants to respond on in terms of looking into the future you know what can we do around what are we able to do yeah thank you thank you chair yeah I think the difficulty here is that we don't have an identified project which we could link this to it's also difficult to in my opinion to justify that the need for a replacement bridge arises as a result of this particular development so I think that given the comprehensive work that would need to be undertaken at some point in the future for the upgrading of the E10 this would be a matter to be resolved through that work rather than through this individual planning application there's no support for a replacement bridge from the highway authority they've reviewed the application and don't consider that's necessary for this development so I think that would be difficult to achieve at this time councillor Rippeth I think it's something that would need to you discuss that at a later date when we know what the E10s future is whenever that is exactly okay that is fair enough in my opinion thank you and could I ask our legal advisor to take the video off please and audio he's on the phone and so councillor Deborah Roberts please thank you very much chairman and I think it's been an interesting discussion actually and we've had lots of clarification on all sides really I'm not convinced entirely that it isn't somewhere down to the cost implications I think it's you know it's pretty to be expected that there will be two very different types of expenditure whether it was just this field and green belt or whether it was on one of the areas that we are actually you know putting high text of etc so I'm not really convinced on that that hasn't come into the decision making of this particular site and you know not having other sites I think a number of people have mentioned it is a very high bar that is set for development in the green belts and the more I think about it the more I don't think it reaches the bar I think that to add this sort of size building and the amount of hard area around it the impact on the landscape there in the green belt next to already that huge car parking area there's a terrible cumulative effect as well on the green belt here which I think actually really can't be very acceptable I think that there are genuine concerns about the safety aspects of it near that road so near to the village so near to that car park area so near to that bridge and we've been told that we can take those into consideration and I think at the end of my thoughts yes it might be very nice for the police to have a nice new police station but wanting something isn't always the same as actually needing it or absolutely needing it at this moment in time we have got a local plan process that is starting up now we're in that and that new local plan is only 10 years away and I really wonder whether we should be even considering something like this in the green belt as we have it now and really it should be something that should be actually been worked upon to be putting into the next local plan as a really appropriate site I don't think it's an appropriate site I think there are genuine reasons for the crime that people have put forward and do stand up but I think mainly it just does not reach the bar that is required and I think more than ever now we have to protect the countryside rounders you know we are as a council saying this all the time to the public how much it means to us you know protecting the countryside protecting the rural nature of South Cans you know we've got to stack up ourselves if we say these things we have to mean them thank you very much chairman thank you with councillor Hawkins next chair could I ask Stephen Reed can he hear me can you turn off your video and audio Stephen please sorry that's fine and sorry we have next sorry it was councillor Hawkins chairman has a doctor to me Hawkins please yeah it certainly has been an interesting discussion so far today about this and I mean the main issue that we all keep coming back to is the fact that it's in the Grimbelt and the harm that is being caused I mean I've heard said that you know a site that's not in the Grimbelt called or should have been found but let's not forget we were shown a list of 22 potential sites site options that were considered and this was then bowed down to three sites which met the design criteria that you know the police federation whatever it is have set down for new police stations so it wasn't a finger in the air you know we think this is okay this has been gone through quite seriously and I hear what the Cambridge past present and future have heard the arguments for you can find something somewhere else but I think we need to bear in mind that there is yes there is a need yes there are specs that have to be met but also yes they have to cut their coat according to their size so I actually am not in agreement with those you know the land they shouldn't have thought about the price of the land they should because everyone has a budget you cannot start building something without actually counting the cost so in my view yes there was I agree with what process has been gone through to get to the the last three now the last three as it happens are in the Grimbelt and in my view this one has been chosen is the least of the I guess you know the least worst of them all and whilst I accept that there is harm caused the question is do the benefits outweigh the harm so in my mind with an ambassador question why is it been put here so that's been answered why now because the current station is inadequate for policing into the next decade and more we have to make sure that our police have the right facilities just as we would want with facilities to work from they need to have that too so they can continue to protect us the harm is there no doubt about it but they need a modern station within the design specs and able to provide for the community that they serve if they don't have that facility now what do we expect it's not going to be the sort of policing that we keep asking them for so we need to bear that in mind I asked if we could have some sort of benchmarking which has been agreed and I think that should also come within into a condition I'm not sure if Mr Carter has actually thought about that because the fear of crying is something that the community is worried about and rightly or wrongly we've heard a lot about how that can be mitigated and the benchmarking the CCTV and the lighting is a set of mitigation measures I think could help with that but also we've heard that there isn't the level of crime that people think exists where the current station is so we've got to weigh this as well in that yes once there might be the fear the question is is it is that strong enough to say no to providing our police service with the facilities they need working into the next decade or more so considering everything that's been said in my view I think the benefits of this station outweigh the harm it is close yes for thinking about the future I think I will be voting for this so thank you chair but if we could make sure that the issue of the benchmarking is taken into account in the condition please chair can we put that to Chris Carter at the moment if yes thank you chair I did give this some consideration as well I think we can construct a condition to deal with that I have noted some wording down which I'll just read out for you to see how members feel about that so prior to the first occupation of the building the applicant shall submit a report to demonstrate existing levels of crime reporting in the parish of Milton following this further updated reports shall be submitted at 6 and 12 months following first use if the data is found to show an increase in reported events it should be accompanied by a strategy for this to be addressed which will then be implemented in the local community that's slightly on the hoof so it would be helpful if members did want to include that I agree the precise wording to be delegated to the chair and vice chair officers agreeing with the chair and vice chair should the vote go that way thank you chair thank you what do you think in terms of that does that address yes I would be happy with delegating the final words to the officers because they know what the intention is but I think the timeline of 6 12 months I wouldn't want that to be a hard limit so that there isn't any further monitoring going forward so my point is shouldn't there shouldn't I'm not sure that would want a hard limit of 6 to 12 months what if it takes longer for that effect to come through is my point I think in order for the condition to be reasonable we would have to put some kind of time limit on it it may be that members consider a longer interval would be more appropriate and I don't know what members think about that but I think that could be flexed in that sense perhaps 12 to 18 months okay thank you very much who do you have next to speak Vice Chair we have two more councillors to speak we also have a request from Mr Read if we can have a two minute adjournment before the vote as I say we have two more councillors to make their comments before we get to that stage chair and the first of those is councillor Harvey thank you councillor Jeff Harvey yes thank you chair sort of two points really I would be interested in we just don't see you there we go thank you yes I would actually appreciate some explanation of the condition in regard to the planning inspector what is expected to happen and why that condition is there just as a sort of background thing but just to more generally about the pros and cons of this I mean I think it's really really a very difficult one and partly that's because one's sort of trying to weigh things that are sort of binary in nature for example is the protection the green belt an absolute you know and I suppose if you read the MPPF you might actually in a very sort of tight reading conclude that that there is harm to the green belt and it's inappropriate but then one's trying to sort of weigh it against things that are harder to really quantify in a sort of binary way which is sort of you know the need and the level of harm and I agree with Peter Fain's point that you couldn't really say that this location is in some way destroying a sort of separation between the city and Milton because it's kind of it's off to the west from that situation so I think that sort of strengthens the case on the other hand you know it is in the green belt so that's a kind of a very serious thing but I think I would really agree with Councillor Hawkins that the problem is that I think we've been sort of shown some evidence here you know we I think we have to sort of accept what we've told that the selection process was robust so therefore we're in a situation where we have three sites that are all in the green belt and I would very much concur that this one is the least worst in that sense so I'm sort of minded to vote for but I mean I am still as I said earlier I'm very disappointed that a public building should have such a low level of ambition in terms of sustainability and it looks to me as though the sort of green rating and the level of on-site renewables has just been set at the minimum that would be allowed and given that we've had that it wasn't a sort of funding issue that led to this site being selected and the fact that failing to provide those sort of on-site regeneration facilities would ultimately cost the service a lot of money and we could talk about this later but I wonder if at the very least we could have a sort of advisory there that nothing in this application should preclude the provision later on of more on-site renewable generation and the provision of EV charging so that's what I've got to say. Thank you Councillor Harvey and I think quite a few people now are saying how difficult, what we're hearing is how difficult it is to weigh this balance you have mentioned the made reference and I think we are now collecting any wanting to understand if it were to be approved, if people were minded to approve this that there would be some conditions and you did mention the EV charging and I think the case officer did say that that could potentially be a condition so it's now to say that if you would like to put something like that forward. Now's the time Councillor Harvey. Okay well should we ask the case officer what that condition would look like if it was about the EV charging within the car park. Yes I think that would be very helpful thank you. Chris or Lewis do we have any support on that? I'll let Lewis deal with that one. Thanks Chris for you chair. If you just bear with me I can draft the condition and share it with members in due course. Okay. Do we have any, thank you very much Councillor Harvey. Thank you. Sorry chair. Just to say unless members wish to see the specific wording I think again the EV charging is one where we could take that away and draft the precise wording following the meeting. I think we've used similar conditions elsewhere so that would be something members would be pretty familiar with anyway I think. Yes rather than sort of trying to draft it on screen I think that's a better way. Thank you and the next speaker. The final speaker chair is Councillor Heather Williams. Thank you. Thank you. I agree with other members this is the least worst option which doesn't always fill you with the most optimism and then voting for it. I think there has been a lot of work done. I do agree and looked at different sites and and I think there is need for the police to have alternative custody suites. Any time that they're spent taking people out there for example to Peaceborough is time that they're not spending serving residents. So I do agree there is a need. The issue I have is probably the same as others is the green belt issue and we've explained how as much as we want to do everything we can to support our police forces we can't give them any special treatment and there is harm that's in its departure but I think when it and you probably can tell by the way I'm speaking that I'm really struggling with it like other members are it's whether there are very special circumstances for it to be where it is and I'm not 100% 100% convinced that there are very very special circumstances that we would normally include in our criteria although there isn't you know with human beings there's going to be an inevitable emotional response and that we want to ensure we do things right by the police and also the neighbours as well because they have concerns which are valid I'm aware from previous issues with Parkside Police Station I think the activity can quite often be a problem with the probation service which is just behind so behind the Parkside Police Station as opposed to the station itself so that does give me some reassurance that the probation service isn't moving with them but overall I think it comes down to that planning balance of is this very special circumstances and I'm not sure the need to relocate qualifies as very special circumstances but yeah wrestling desperately here good and so thank you very much Councillor Williams for that and I think we're hearing need we also have to talk about public benefit as well with that so I hear Stephen Reed our legal advisor is proposing that there's an adjournment Stephen are you proposing that that's before we look at what conditions would be before we go to the final vote or can we move to any conditions first or Chris you know I would understand that we would vote on each of the conditions first rather than wrapping them up all in the one vote I think you probably need Stephen to advise on his request there Chair if I may I would be relaxed about a vote being taken on the conditions I would just like to speak to you and to Mr Carter before the vote itself is taken if you did ask me my preference would be that actually a two minute adjournment even before addressing conditions would be more beneficial than leaving it to just before the vote itself okay and vice chair I don't think we have anybody else to speak that's right chair no one else no and I really thank everybody I think we're all really weighing this up in the balance and we've had some good debate there and all the issues have come through it would in terms of if people were minded not to support this I'm trying to note down what those reasons were now what I'm hearing is that in general it's not seeing that the public benefit outweighs the harms because of harm to green belt openness and visual impact so it's the principle of development and the green belt and the fear of safety are those those are the reasons that I've heard if those who are minded not to approve but if there's anything additional to that please do let me know and meanwhile we can have this adjournment how should we do that Chris the adjournment chair I've just sent a dire appointment to yourself and Stephen Reed which contains a team's appointment to join so you would leave this meeting and join that one momentarily and so should we invite vice chair to attend as well Chris yes the meeting stays live we just have ask everybody to have the video and audio off. Yes we could ask Liam just to put a slide up to say that we'll be returning shortly. Okay so members can I ask that we follow Stephen's advice and just to find out what this is about and have this two minute adjournment obviously we'll come back and explain to you what that is I've just had a quick one cumulative effect I think it is the cumulative effect as well as the building the car park being so very in close proximity to the park and ride sites I don't know whether the officers think that that one would be appropriate but it's one that I think is important thank you. In terms of our key material considerations where would you say that we've got what would that be layout scale or highway safety scale chairman as I say I think because of the the potential of the massing effect of it and then all that concrete area of the park and ride I just think the the overall effect is going to be very very bad. Chair if I may could I suggest possibly if we took a 15 minute adjournment we'll deal with Stephen Reid's query initials to give officers a chance to draft a potential reason for refusal should the committee wish to go that way so that when we return we can present that to the committee as well if that be okay. Be really helpful yes thank you. Thank you everybody so if it's now I've got 135 so if we come back at 150 Liam thank you very much you've put up a slide and everybody take their video and audio off are we live Liam let me know one more live. Hi yeah I just confirming now yeah we're now live thank you. Thank you Welcome back everybody to the South Cambridge District Planning Committee and after a short adjournment we're now coming back having had the debate on this application and now moving forward towards the vote we just had this short adjournment to look at the reasons for either approval or rejection if people were minded either to approve or refuse this and before we go any further there have been recommendations in terms of conditions if the committee was minded to approve and so I'd just like now to go through those three proposed conditions one by one and see whether by affirmation or roll call those would be accepted if committee was minded to approve Steven. Sorry you're just going to take your roll call before doing that. Thank you very much and once again. Yes thank you very much. So a roll call before we go to that which would be very very helpful. Councillor Henry Batchelor Present. Councillor Dr Martin Kahn Present but you won't be voting. Councillor Peter Fein Present. Councillor Dr Toomey Hawkins Present. Councillor Judith Rippeth Present. Councillor Deborah Roberts Present Chairman. Present. Thank you. Councillor Sue Allington Present. Councillor Jeff Harvey Present. Thank you everybody. Good. So taking that so as I said we've had three proposed conditions if committee was minded to approve the application and I'd just like to take those one by one if see first of all if we can do it by affirmation and obviously this is affirmation if committee was minded to approve otherwise we'll go by roll call. The three conditions are as had been proposed in terms of wording by Chris Carter which one would be the CCTV on the A10 pedestrian bridge strategy. The second would be around a crime reporting strategy to have a benchmarking and to help with monitoring. And the third would be an EV strategy for the application to the car park. So I'll take the first one which is around the CCTV A10 pedestrian bridge strategy. Who would like to propose that? If you propose a chair I'm happy to. Thank you and who'd like to second that? Can I second? Yep. Okay. Can I take that by affirmation? Agreed. Agreed. Thank you everybody. Anybody against? Abstain. Okay. So that condition if minded to approve that would be accepted. The second one is around a crime reporting strategy. It would help with benchmarking and monitoring and assessment. Anybody who would like to propose that? Yes, please. Councillor Hawkins. Councillor Dr Tumi Hawkins, who would like to second that? Happy to second. Councillor Rippus. Thank you. And committee can we take that by affirmation? Agreed. Anybody against? Or abstaining? Okay. Thank you. And the third one which is the EV strategy for the car park. Who would like to propose that motion for a condition? I would like to propose that. Councillor Jeff Harvey. Yes. Who would like to second it? Happy to second. Hawkins. Thank you, Councillor Tumi Hawkins. Committee can that be by affirmation? Agreed. Agreed. Agreed. Agreed. Thank you very much. And now we come to the vote and members that's on page 38 which is the recommendation and we've had a thank you very much everybody. I think a really good and serious debate where this has challenged everybody to look at weighing the balance between the public benefit and the harm to the green belt. So thank you all for that. The recommendation here is to approve the proposal subject to a consultation with and confirmation from the Secretary of State that the application is not to be called in for his determination and B the planning conditions are set below in the report and that's just voted upon and I know there will be differences in I think in voting as from what we've heard from people during the debate. So if that's okay I will go according to Chris. Sorry chair, sorry Tintin. Would you like me to for those members who may wish to vote for refusal which I think there may be some would you like me to put up on screen the proposed wording that we've arrived at? Yes please. I'll just do that now. Would you like me to read it now or is it okay to read? I think you should quite so yeah. So the applicants have failed to demonstrate very special circumstances to outweigh the harm that would arise from the proposal to the green belt by reason of its inappropriateness. The harm both individually and cumulatively with nearby development would be significant representing a formal development which would fail to assist in the safeguarding of the countryside from encroachment and fail to preserve the setting and special character of Cambridge and Milsen. The benefits arising from the scheme would not outweigh harm to the green belt or harm in terms of impacts to the landscape and from the loss of agricultural land. The proposal is therefore contrary to the South Cambridge local plan 2018 policies HQ 1, S4, S7, NH2, NH3 and NH8 and paragraphs 143 and 144 of the NPPF National Planning Policy Framework 2019. Thank you and members is that okay in terms of capturing your reasons for refusal if you are minded to refuse? Yeah, very much so chairman, thank you. Thank you. Councillor Harvey would like to speak chair. Councillor Jeff Harvey. Yes, chair I just wanted could we take it then that the EV strategy which will be prepared later will touch upon the onsite renewable as part of that? No, not as not as worded. Okay chair given the wording but if I may I know Councillor Harvey suggested possibly an informative with regard to wider sustainability measures to be included. I think that would be appropriate. I think a strategy for the electric vehicle charging points we can include as conditioned but I'd suggest perhaps an informative along the lines that Councillor Harvey suggested to advise the applicant that they shouldn't shy away from any further additional sustainability measures in the future if committee were agreeable to that. Councillor Harvey is that does that address your Yes, I think it would. I was just concerned that potentially useful avenue was left unexplored if you like so thank you very much. No, and we've done that in informatives in the past on other applications I think that's fine so committee if minded to approve by affirmation would you approve of that informative also to be included Agreed Agreed Thank you very much Thank you for that Councillor Harvey Thank you chair Okay, so members I will now go to this. So the recommendation is to approve the proposal subject to a consultation with and confirmation from the secretary of state that the application is not to be called into his determination and be the informative and planning conditions are set out below and as voted on just now by committee those three additional conditions please in the roll call answer for against or abstain as I call out your names and I will try and insert in the subs in alphabetical order as well within the roll call. So I'll start councillor Henry bachelor for chair councillor Doctor Martin Carnes not voting chair oh sorry there I go badly sorry councillor Sue Ellington against councillor Peter Fein for councillor Jeff Harvey for councillor Doctor Toomey Hawkins for councillor Judith Rippeth for councillor Deborah Roberts against councillor Heather Williams against councillor Doctor Richard Williams against and my vote would be for that would be six in favour and for against and no abstentions so the application is approved thank you everybody if we now turn to our agenda and we are on to agenda item six the enforcement report and who do we have to take us through that please that will be me how did you appear magically like that wonderful thank you very much had a little elf tap me on the shoulder thank you Alistair do you want to take us through the enforcement report is anything to make us note in the report there's no updates to the report it is as it is if any questions I'll do my best to answer members do you have any questions for Alistair no one's indicated chair so nothing on that one thank you very much Alistair thank you and agenda item seven which are appeals against planning decisions and a report on that recent appeals chair no particular updates we spoke about the appeal decision which is noted on page 57 and the east of Cody road and north of bannled road at the last meeting so I won't repeat that but otherwise the other two appeals were both dismissed which is good news happy to take any questions any questions members please chair councillor Rippers chair councillor Judith Rippers apologies if this has been repeated because I wasn't present at the previous meeting Chris Carter who you chair could you give any more information on the allowed with costs and what the reasons for that were on the bannled road application you're testing me now councillor Rippers I'd rehearsed this for the previous meeting and not for this one but would you be happy to receive a summary after the meeting just so I can refresh myself on the appeal decision if everybody else has heard it yeah that's fine thank you thank you and is there one more question for myself chair if that's okay sorry yes councillor bachelor it's on the informal hearing section I note the hearing for 100 houses society is listed as being appealed because of non-determination is actually appealed against refusal granted by this committee so just just want to correct an inaccuracy in the papers there thank you councillor bachelor that's noted thank you and thank you anything else councillor vice chair no one else chair okay and as I understand the next planning committee meeting is on Tuesday 13th of April is that right Patrick that's right I think I've got it in my notes here so that would be good thank you so thank you everybody for your time today and for all of the contributions that was a difficult balance that was struck today I now declare the meeting closed and thank members of the public as well for viewing the stream leaning stream streaming of this meeting thank you everybody bye


Hello everyone. I'm Boris Brezio and I'm working for Freelictron for almost four years now. As part of my job for Freelictron, I'm actually doing a lot of stuff around RMS OCS. And one of these drivers I have developed for Marvellous OCS is the crypto engine driver, which is what I'm going to talk about today. So let's see what we'll see during this talk. First, I'll try to introduce various cryptographic concepts. So this will be a short introduction to those concepts and I don't pretend to be explaining everything about cryptography here. Then I'll try to explain what kind of services the crypto, the internal crypto API provides. So you can use those services and after that we'll dig a bit into the crypto API to develop a crypto giant driver. And finally, I'd like to share my experience, the experience I had while developing the Marvellous crypto giant driver. So let's start with the basic concepts. Of course, if you've already heard about Alisa Bob, I guess you don't need this introduction, but for those who would don't know these people, then I'll try to sum up a bit what cryptography is about. So cryptography is about ensuring that a communication with two people or more than two people is protected. And this protection is actually separated in three main concepts. So the first one is confidentiality, which means that no one else can spy on the communication, which is happening between those people. The second one is the integrity, which means no one else supposed to modify the content of the communication or at least if someone modifies the content, then all the people can notice and decide to close the channel. And the last one is making sure that when someone sends you a message, this message is actually coming from this person and not from someone else. Why, how do we do that? It's basically we're just manipulating input and output data and adding some metadata to it. And then thanks to that, we can ensure those three things. So the first thing we'll see in cryptography is the cryptographic hash or what is called sometime digest. And this is the part which is supposed to guarantee the integrity of your data. So ashing functions basically operate on a random number of input data. And then it's generating a unique fixed size data, which is most of the time shorter than the input data. So for example, you have SHA2, SHA1, MD5, and you have a lot more. So the main things that we want from an hash algorithm is that we want the probability to have two exact same ashes from two different inputs to be as low as possible. And ideally, we'd like these to be new, but that's almost impossible. We also wanted to make it impossible for a user to regenerate the input data from the hash. And the last thing we want is that if we do a tiny modification in the input stream, we want the output hash, the hash result to be as far as possible from the initial hash. The next thing we need when we're doing cryptography is the cipher element. So cipher is supposed to ensure confidentiality. It's basically using a private key or a key to encrypt and decrypt data. So you can have two types of ciphers. The swim cipher, which kind of operates on a random number of data. And the block ciphers, which are meant to be used on a fixed-size block. Then you also have the notion of symmetry in asymmetry. So symmetric ciphers are supposed to use the same key for both decryption and encryption, which means all the people which want to take part to communication have to share the exact same private key. Of course, that's not really secure, because if one of these people gets this key stolen, then that means the whole communication is insecure. So to address that, we also have asymmetric ciphers, which are using a pair of public and private keys. So the private key is kept secret and only the creator of the key keeps it. Then it can also, it can send the public key to anyone who wants to communicate with this person. And all the messages are actually encrypted with using the public key, and only the owner of the private key can decrypt the messages. So we tend to use asymmetric ciphers to enforce security when we don't know exactly who will communicate with afterwards. But it's also a lot more expensive than symmetric ciphers. So it's kind of a compromise here. A few examples. So for symmetric ciphers, we have AES. And for asymmetric ciphers, we have, for example, RSA. So I said that we have stream ciphers and block ciphers. Even when we use block ciphers, most of the time, we want to be able to use those block ciphers for a random number of blocks. And in order to do that in a secure way, we will have to choose a specific block cipher mode. And the block cipher mode is just something that describes all you can decrypt or encrypt several blocks of data. So for example, you have the ECB block cipher mode, which is pretty simple. It just takes a key, some input data, and then does some operation on it and provides the output data, which has been encrypted with the key. And you have more advanced cipher mode, which are getting the result of the previous encryption and using that as an initialization vector to encrypt the next block, which ensure that the data you're transmitting are actually obfuscated. So you cannot guess exactly what has been transmitted by observing the communication. Another thing we have in cryptography is what we call MAC, which stands for message authentication codes. This is actually used to authenticate the who actually sent the message. What it does is it takes a private key, then it does some transformation on the input data and generates some output data, which are put next to the data so that the receiver can then verify that the sender actually is the one who claims it is. So most of the time the MAC algorithm are based on HASH algorithm, and that's why we call them HASH MAC. And then we have the advanced block we use in cryptography, which is doing all of the things we've seen so far in a single step. So this means these kind of algorithms are taking some data, generating data to ensure data integrity, to ensure confidentiality, and to ensure authentication. And most of the time those are actually based on simple blocks like HMAC, CBC, and so on. So this was really a short introduction to those crypto concepts. If you want to know more about these things I'm talking about here, you should watch the talk from Gillard Benyosef, and I think he is giving a talk this week, so if you want to go see his presentation, I think it's a good one. Then I'm switched to what we are really interested in here. The Linux crypto framework. So let's see a bit how it works internally before seeing how to use it and how to develop a driver. So internally everything in the crypto framework is about transforming data in order to generate something else, and that's why you'll see a lot of places where we are talking about transformation. So there are two main objects. We have the transformation implementation which is the base class which is supposed to implement a specific algorithm, and then you have transformation objects which are the instance that are provided by a specific transformation implementation once someone asks to create such an instance. So if I had to make an analogy with an object-oriented language, I'd say that the transformation implementation is actually a factory and which is able to generate a transformation object, and then these are the objects the crypto user will use to do all kinds of transformation. So everything in the crypto framework actually inherits from those two interfaces, crypto arg and crypto tfm. The crypto framework supports Bernshoff algorithm, so you have a lot of Cyphers algorithm, Ash algorithm, AED algorithm, HMAC, and you also have one, I don't know exactly why it's here, but you also have compression algorithm which have nothing to do with crypto at all, but I think it was fitting well in the crypto framework and this is why they decided to implement it there. So these are the base class of crypto objects, and then based on that you will be able to generate complex objects which are combining different elements. So for example, you will be able to generate an Ash-MAC function which is using internally the SHA-1 protocol, or you will be able to use the AES block cipher using in CBC mode, or you will even be able to create an AED algorithm based on Ash-MAC SHA-1 and CBC AES. So as you can see, we always start from simple blocks and then build something more complicated from there. So how can you use the crypto framework? The first thing you'll start to do when you want to do some crypto operation is allocate an algorithm instance, what we call the TFM object. So this is done with a call to crypto arc, and then you pass the arc type suffix, so you have SK cipher for symmetric K cipher, AH arc for Ash algorithm, and so on. To this function, you will pass the algorithm names, we will see later what should be passed here. Then you will pass type, I'm still not sure what this type is about because obviously the type is already known in the function prefix, but still you have a type parameter, and then you have a mask which is saying the crypto engine, what kind of implementation you want to avoid. So for example, you want to avoid implementation which are doing things asynchronously because when you trigger a crypto operation, you want the result to be available when the function returns, and then that's the kind of thing you will be able to ask when you instantiate the TFM object. Once you have this TFM object, you will be able to create crypto requests, and this is done with the request analog functions. So again, always prefixed with the arc type, and with this request object, you will be able to assign a specific callback that will be called every time a crypto operation is complete. You will be able to pass a few slags, for example, whether you allow the crypto framework to request to the backlog if there are already too many requests inside the crypto queue, and all those things like that. So that's for the init part of the creation. Once you have that, you will want to set the context of your transformation object, and most of the time the context is about setting the private key or the public key or whatever you want to use to do this crypto operation. So here you'll use the crypto arc type set, and the context you want to set. So most of the time is crypto something set key. Once you have set up everything, you can start passing that to the crypto instance. So to do that, you will use the request set script, which you will pass the input buffer, output buffer, and the length of the buffer, and you will be able to trigger the crypto operation. So this time, it will be done using crypto, then arc type, then the name of the operation. So for example, for a cipher, it will be encrypt or decrypt. And you can do that many times, as many times as you want. Say that you have several blocks of data to encrypt, then you can repeat that over and over until you're done with encrypting or decrypting data. And once you're done, you can then free both the request and the crypto engine context. So that's how it's done. So let's see a real example of code to see how it interacts with the rest. Yeah, the code I'm going to show here is not really to be used in real setup. So this is just to show all the different steps you have to do, but that you shouldn't base your development on that if you really need to develop something that uses the crypto API. So let's look at the right of the screen. And we're looking at the encrypt function, which is the main encrypt part. So this function is supposed to encrypt some data. You will pass it the private key you want to use. You will pass it the data you want to encrypt. So this serves both of the input buffer and output buffer. And you will pass the size. The first thing you'll have to do is allocate the crypto context, then set up the request and so on. So we'll call the init function, which is doing, which is calling the crypto allocs SK safer. So allocating symmetric key cipher algorithm. We then use the request alloc to create a new request. Then we specify the callback we want to be called when the operation is complete. And finally, we initialize a completion element. Once we are done with that, we set up the key. So we use the crypto SK safer set key. And we set up also the data to pass to the crypto API. So after you pass it using an SG element, a scatter as a list, and then we just call request set script to say that this is my input buffer. This is my output buffer. And this is the length of the buffer. And once this is done, you just trigger the crypto request, calling crypto SK safer encrypts. So by design, the crypto API is asynchronous, which means when this function returns, you are not guaranteed that the operation is actually done. And this is why the crypto API can return in progress or busy errors. And in this case, you shouldn't consider that as a real error. You should just wait for the actual operation to be done. And this is simply done by calling wait for completion on the completion object you have initialized in the init function. So once this is done, you get back the error, clean up everything, and then return the return code. So this is a simple example of the different steps you'll have to follow to use the crypto API inside the channel. Of course, this was just a dummy example. If you want to look at real example, you just have to grab for crypto a lot of something, and you should find different elements which are using crypto. For example, we have DM Crypt, which is doing this encryption. We have various network protocols which are using crypto, file systems, device drivers, and I guess you can find more. So really, the crypto API is used all over the channel. Now we have a specific user. Some people want to use the crypto engines from user space. And so they pushed for a long time to have something inside the channel to expose those crypto features to user space. So we have currently two competing solutions. The crypto dev approach, which is not mainline. So that's not so good. And we have the AFR, which is a mainline. So let's see a bit how both solutions come together. The first solution to have emerged is crypto dev, and it's actually taken from the open BSD word. This solution is actually exposing a device under slash dev. And every time you want to do something from user space, you just use Ioc tools to set up the context, then send data, and so on. The main problem with this solution is that it's maintained as a net of three modules and will never be a mainline. Simply because we have something in mainline which exposes crypto features to the user space, and this is called AFR. Instead of exposing things through a dev slash dev slash something device, it's exposing things through a net like socket. And the main problem with AFR is that most user space crypto library or net using it. For example, open SSL as an out of three module for AFR, which is fully maintained. But in the other end, on the other end, it has a native support for crypto dev. So you'll have to make a choice whether you want to add an out of three module inside the channel, or whether you want to add support for AFR into open SSL compiling an out of three library. So before, actually I didn't try to understand how they work internally, but I tried to see what kind of performances they can provide, both of them can provide. There was an assumption that or at least it's written everywhere on the internet that crypto dev is performing better than AFR. So I wanted to make sure that with my crypto giant, the Marvel one, this was the case. And actually it's the case for 8K blocks on an AES CBC algorithm, then you see that the crypto dev algorithm is performing better. But you also see that for really small blocks, it's almost useless to use the internal implementation compared to the user space implementation. And then I decided to test the user space implementation, which is probably using the processor optimization assembly instructions. But still, it's worth looking at the results. So as you can see, even crypto dev is outperformed by the software implementation. So I decided to run the same test and launch a few threads in parallel because my engine is able to use things at the DMA level. And the more I have requests, the better it reacts, it scales. And actually I had to create 228 threads to get better results with the internal implementation. And interestingly, it was achieved with the AFR implementation and not with the crypto dev implementation. But still, when you are asking yourself whether you should use crypto dev of AFR, actually the first thing you should ask yourself is whether you want to use any of them. Because when you compare the results to the pure software implementation, then it's not so good. And I also had a look at the CPU and consumption because every time you use an external engine, one of the things you want is that you don't want to offload the CPU. And actually, even the version using the hardware engine is using quite a lot of CPU. So it's using around 60% of the CPU compared to 100% when you use the pure software implementation. So really, I don't think in most cases it makes sense to use your hardware engine from your space. The only case where it might be interesting is when you have a lot of requests which are coming in parallel. But other than that, you should think twice before trying to use those hardware engines from your space. So now let's have a look at how to develop a crypto engine driver. So from the crypto API point of view, a crypto engine is just an implementation of a specific algorithm. And the crypto API does not distinguish between pure software implementation and those which are using dedicated engines. So developing a crypto engine driver is just about implementing and registering a crypto arg interface. So most of the time you don't implement crypto arg directly, you implement something that inherits from crypto arg because as I said, crypto arg is the base class, the base interface and then you have to inherit from it. So you implement it, you register it using crypto register something and the something is the type of crypto algorithm. And so we will see a simple example with a CBC AES driver. We studied this one because it's quite simple. Now if you want to have a look at our hash algorithm or advance AED algorithm, then I recommend that you look at existing drivers to see how it's implemented. So the first thing you have to do when you implement a crypto algorithm or crypto engine support, the first thing you have to do is fill in the crypto arg structure. So the first name, the first field you'll have to pass is the crypto algorithm name. So this one is standardized and you always have to use the real name of the algorithm. So for example, this is CBC based on AES. So this is the name you'll have to pass. Then you will pass the driver name. So this time you don't use parentheses, you just use dash and then you prefix it with the driver name. So XXX is just the name of the driver. The next field you'll have to specify is the priority. The priority is supposed to be representing how well the engine is behaving compared to other implementation. So basically by convention we have this rule which is hardware engines always have higher priorities than arch-optimized implementation which have higher priorities than plain C. So normally we have hardware engines which have a priority of 300. Then you pass some flags which are specifying which kind of algorithm you are implementing the different things the algorithm supports. So for example, if your algorithm is behaving, is doing things asynchronously, then you have to pass the crypto async. Or if the crypto engine is not directly accessible to use space, you'll have to pass the crypto out-current driver only which allows the system to know when it should expose the algorithm to the use space interface. The next thing you'll have to do for the for block algorithm is to specify the block size which this algorithm is operating on. Then you'll have the context which is representing your driver specific context. So every time you have a new instance you will have a new context allocated and this context is actually allocated by the crypto framework. So the crypto framework needs to know how much data you need for your own private data. And this is why you have to specify the context size. And the last thing you'll have to specify is the descriptor and constructor methods which are called every time a new instance is created or destroyed. So let's have a look at the part of the crypto algorithm which is specific. So here the SK cipher algorithm is inheriting from the crypto org and you'll have to implement a few fields in this SK cipher algorithm. The first one we'll have to implement is the set key because this is a cipher algorithm. Then you have to implement two methods encrypts and decrypt and then some information about the the key size and the IV size if the algorithm needs an IV. Then inside your function you just do what has to be done to encrypt, decrypt or assign the key to to the context. So all those functions have to be driver specific because each engine is handling things differently. And once you have done that you just go the crypto register something and that's all you should be done and your driver should your crypto engine should be exposed. So when the framework exposed the crypto engine and someone wants to use this crypto engine it will either you ask the crypto API to allocate an instance based on the usual algorithm name so here cbc aes and depending on all the engines which are registered to the system and based on the priority then the crypto API will decide which one you should use. The higher priority the engine with the higher priority will be chosen over the other. If you want to really use one specific engine because you know this is the one you want to use then you can also pass directly the driver name when you request crypto instance. But usually most of the time the users don't want to have to specify a specific engine. They just pass the algorithm name. So that's all I have on the crypto framework part. Now I'd like to share a few things that have been complicated to deal with during the development of the driver. So first the framework is really complex and actually it's complex for a good reason. When you look at the number of algorithms which are supported in there and how easy it is to add a new algorithm to the framework then it explains why it became so complex. And also one of the good things is that even though it's really complex you have an extensive test suite. So every time you add a driver for a crypto engine then you can run the test suite and make sure that your driver is actually behaving correctly. Well the bad aspect is that it's so open that most of the time you have several ways to do the same thing. And one example is for example how you can implement crypto engine for an SK cipher algorithm. And you actually have two ways right now. So I think SK cipher is the right way to do it but we still have drivers which have not been converted yet. Also how to generate from a base class is not really clear. You have at least two ways to generate from it. Sometimes there is a union inside the base class with different, inside the union you have different interfaces and sometimes the child class is embedding directly the base class. So it's not clear what kind of inheritance you want to do here. Also it's hard to tell what are the good practices because when the framework evolves then the new drivers are switching to the new method but the old drivers are usually staying like they were. And the last thing is that there are some aspects that can be discovered the hard way. For example I didn't know at the beginning that the complete code back has to be called with the soft IRQs disabled. Which is actually logic because one of the big users of the crypto API is the network stack and the network stack almost everything is done in a soft IRQ context when it comes to handling packets. So it needs when you do a crypto operation it needs to be done in the soft IRQ context. But wow this is not the only subsystem where it's not completely consistent and I'm probably not the good person to complain about that because in the non-framework it's even worse. And that's not something we can address easily. So it drives cooperation from both the maintainer and all the driver developers and maintainers. So it takes a lot of time to migrate all drivers to new methods to do things. Another problem I had when developing the driver and testing it is that there is no way to use polling when you are under heavy load under heavy crypto load. Which means even though you have NAPI activated at the net level which allows the network stack to do things in a threat context and then pull for the and do that to all the packet handling in a threat context. Then you will have the crypto API which will generate a lot of interest which kind of defeats the world purpose of NAPI. So in this is our driver we address that manually by creating a threat IRQ and then doing a bit of polling after the last crypto request has been done to see if the next one can be handled after that. But still it's a bit hacky and I wonder if we should find a better solution like maybe add something to support NAPI like interface in the crypto API. So I'm not sure about that it's really a question to the audience. And the last one the last point we fought with was the load balancing issue. So in Marvelous OCs you usually have two crypto engines which are exactly the same and using the priority based selection of the engine you cannot use the second one. So every time this is the first one which is chosen to do things. Also if say you have in the same system different crypto engines which are not exactly the same but still can be used in parallel then actually only one of them will be able to end the request because only the one with the highest priority will be chosen when something needs to be done. So the question is should we introduce some kind of load balancing mechanism while it's not so simple to do because the framework is not designed to do that from the beginning. So if we need to do that we need to introduce a new concept which is crypto engine concept and each crypto engine is able to expose different algorithms. We also need to find a way to assign a load to each request because each request will be queued to a specific engine. So we can either find a way to calculate something which is rather complicated based on the request type, the request length and the engine it is queued to or we can just do something as simple as the load equal the length of the request. And of course we need to keep track of the total load of each crypto engine. And the last thing we need to handle is how to migrate requests from one engine to another because every time you want to switch to a different engine you need to allocate a new context which is driver specific and then under allocate a new request which is also driver specific. So this is just an idea how it would look like but really there is no proof of concept or nothing like that. But I think we can keep the upper layer unchanged meaning that the crypto user could still request the crypto API to allocate a specific instance based on the priority and then below that we could add some the notion of load balancer which you would gather all crypto engines which implement a specific algorithm and then at the load balancer level decide which one should be used depending on the current load on each engine. So yeah that's some ideas. That's all I have about the crypto API and the Linux stuff. So do you have any questions or suggestions or comments? Okay so you want to access the the question is it's a comment you want to directly access the hardware engine directly from user space so you're not using Linux. Yeah actually it should give good performances compared to the numbers I gave here because it's completely bypassing all the the kind of stuff and all the overhead you can have when you're switching to user mode and and so on. Yeah actually I'm not the one you should ask to but yeah you should talk to Herbert. Yeah yeah why not? I mean so anyway it would be a asynchronous crypto engine because you would queue some requests and then wait for the those requests to be complete. So it I think it will it would it would fit pretty well in the crypto API. I can tell. I think if you are using the FPGA to access to to provide things to the user space then you would have also poor performances because you still have all the the stack to to go through every time you want to do crypto requests and which is where the overhead is. No actually you just have to so the question is what has to be done to enable the crypto manager test self-test. Actually it's just an option to enable. By default all the tests are disabled just enable an option and it's done. Yeah absolutely not. Okay so the question is did I consider the poor consumption when doing my test and the answer is no and actually the comment is that some engines are consuming less than the CPU so even if the CPU is a bit more loaded in the end it would be interesting to use the crypto engine. Is that right? Yeah I don't know. I would have to do more tests to test that. Yeah okay I think we the the world crypto API is based on SG Scatterlist so it should already be ready for a DMA. I think what you want is to have everything consecutively allocated so I don't know if there's a solution to allocate the crypto request and and the contribution. Actually this is this is the crypto user which is allocating the data to be encrypted or decrypted or whatever. Yeah so you want to have an interface to ask the driver to allocate the data? Okay I don't know if it's planned but yeah that would be a solution if you want to use a pre-allocated pool in order to have things in a specific area of the the memory. Any questions? Any more questions? Yeah yeah so I didn't mention that it's Cortex A94 cores so basically when you have this test it's only using one core uh this one sorry it's only using one core and when you have the 128 threads it's using the four cores to do the operation. But still it's it's still performing better than the hardware engine. There is a fine slash proc something. Yeah I have no answer to that. Sorry sorry I don't hear you. Actually the OpenSSL test are only doing tests on maximum eight kilobytes so I didn't test on more than eight kilobytes. But I think it's since the engine is acting on on 2k blocks shouldn't change that much in our case. Sorry I don't hear you can you come closer? Yeah we could do that yeah it should. Okay yeah how does? Yeah um it's it's an algorithm which is uh arch optimized so it's using assembly specific instructions so it's basically implementing using an uh SKSF algorithm which is relying on specific instructions. Is that what you were asking? Yeah so yeah everything every implementation which are arch optimized are also exposed as uh crypto algorithm that's that's using the same interface. Yeah maybe I'll ask one okay yeah I think there is a way to uh use the Ocopy. I didn't dig into it okay but not the other way okay I don't know you should ask the uh crypto maintainer for that sorry thanks


A relationship isn't an invitation to change another person. You can't change another person. You can only be in a relationship with them. Through that relationship they may see themselves in a new way and be inspired to show up with more awareness. But they also may not. A relationship to total acceptance and appreciation of someone, not to their potential.


It's a great pleasure and honor to be at this conference and have a chance to present. I look forward to learning a lot today and tomorrow. Before I even get to this slide, let me start by saying that the presentation I'm about to give is a contrast. I hope a useful contrast from the keynote we just heard. Most of the way through Marcelo Neri's wonderful presentation, I was thinking to myself, we don't really need my paper, the Brazilians have figured it out. And then at the very end, when he said, well, maybe we should worry less about inequality because growth is slowing down and the tax burden is so high. And I kind of thought, okay, well, that's what my paper is about, so that's useful. And thank you for that. We take a big picture look at these issues in the sense that we step back and look at what the cross-country evidence has to say. You know, in my own work, I find that when I work on the cross-country evidence, I wish I could look at the details more closely because it's, you know, ultimately the big picture when you look closely, the pieces are blurry. On the other hand, sometimes when you look at the details, you do want to see how it fits together or what the broad patterns are, and that's the spirit that we've been doing this work. So this line of work started many years ago with my colleagues at the IMF, Jonathan Ostry and then Jeremy Zettelmeyer, when we were looking not at inequality, but at the sources of sustained growth. And it actually came very initially out of the idea that we might, we were thinking in terms of crisis prediction, being the IMF, and we thought maybe if we could predict when growth spells were going to end, we might have a handle on when certain sorts of crises would come. So we wrote a paper that came out a couple of years ago on sources of sustained growth, and in that project one of the surprises was the salience of income inequality as a predictor of weakness of growth spells, that's to say the hazard that growth spells would end. And then Jonathan Ostry and I drilled down on that, or really went, ran with that particular result in a 2011 paper where we talked about the role of inequality in sustained, or of equality really in sustaining growth spells. So that's part of a literature that has, a big literature obviously, that has talked about the role of inequality, the role of inequality in growth, and I'll review it briefly a little later. But that has come on and since the 2012 crisis, and since of course the rise and the discussion about the rise and inequality, especially in advanced countries this topic has come to the fore. Now, we would tend to say that there is a tentative consensus that inequality indeed is associated with slower and more durable growth, at least over the long horizons in a sort of cross-country sense. When we finished the last paper, our 2011 paper, it was very hard to write the conclusion. This was supposed to be a policy, it was a staff discussion note, it's a policy oriented note, and we were trying to draw policy conclusions, and we drew some policy conclusions, but there was a key problem with drawing conclusions, which is kind of precisely what we really heard about at the end with respect to Brazil, which is that it's not clear really what is, what's driving the relationship between inequality and growth, and in particular there's a theory, the fiscal, there's a theory that one of the reasons inequality may lead to lower growth is precisely that countries try and do something about it. So the story would be that Brazil's high inequality at a sort of longer horizon has led to low growth exactly because it led to a consensus in favor of redistribution, which indeed has a lower growth. Now, by no means making that claim about Brazil, I'm just using that example to illustrate the argument. And that's in the literature, and that sort of makes it very hard to draw any conclusions about the policy implications, or at least some of the policy implications, about the fact that high inequality may cause lower growth. And another way to put that is there's very deeply embedded in the economics profession this view about the trade off between equality and efficiency. There's a book by Arthur Oaken from I think 1978 that was Brookings' best-selling book ever, at least until a few years ago, called The Big Trade Off. And Thomas Sargent in his, the Nobel Prize winner in his speech to the graduates, listed 12 things economists know, or eight things economists know, but it wasn't a very big number. And one of them was that there's a trade off between equality and growth, or some such trade off. So for all these reasons we wanted to analyze simultaneously the relationship between inequality, redistribution, and growth. So one relatively narrow objective was to see if controlling for redistribution we still see the same effects of inequality on growth. And the other was to try and get a handle on sort of the Oaken trade off, and does it exist in the data. So we look at the effects, when I say growth we mean two different things. We look at the average rate of mean per capita real growth over five year periods. And I'm going to usually call those panel growth or growth regressions. And we look at the duration of growth spells, which is how many, if we define growth spells in a certain way, these are sort of episodes of reasonably high growth, and you can sort of define when they come to an end, and you can ask about the risks that they will come to end and the determinants of those risks. We use a, it says recently compiled, the paper was in 2009, it's recent in some sense. A recently compiled cross country data set by Professor Sold that's based on the WID data, mainly, that distinguishes between net and market inequality and allows therefore for the direct calculation of redistribution, which we define simply as the difference between the market and net genie in a country. So it's not redistribution defined in terms of spending or tax rates or any effort at redistribution. It's just what seems to show up in the data in this sense. And I'll talk about that obviously, the limitations of that in particular. Seeing Nora in the audience is always scary when I present this kind of thing because I know what she's thinking, I think. But anyway, I'll talk about that. One of our main conclusions is that lower net inequality does seem to drive both faster and more durable growth for a given level of redistribution. So we recover our old results and now we have done it also in a growth panel as opposed to just duration. And we find redistribution in general, we find little evidence of a negative effect of redistribution on growth. In extreme cases, which I will define, of course, there is some evidence that there can be a direct negative effect of redistribution, but the combined direct and indirect effects of redistribution are on average pro-growth. And by indirect effect, I mean the effect of redistribution on inequality and thereby growth. So this graph may help, or it may not, but it may help to define terms a little more carefully. Of course, I'm using Gini coefficients, which most of you know, but vary between, it says, 0 and 100 or 0 and 1, where 1 is completely unequal and 0 is complete equality. Market equality is inequality of factor incomes before taxes and before transfers. And then we have redistribution, well net inequality is inequality of income after taxes and transfers, again measured as a Gini coefficient. And the difference between market, am I able to point in some way? I guess I can use this. The difference between market and net, of course, is redistribution. So we're going to look at several of these channels in this paper, but not all of them. In fact, there's many arrows that we could have drawn that we haven't, and we don't look too much at those. But one reason we think it's important to look simultaneously at redistribution and inequality is that there's a body of evidence and thought that suggests that redistribution is a function of inequality. That's this line A. It's the so-called Meltzer-Richard effect, which is that more unequal countries tend to redistribute more, at least that's the claim of some people in the literature. And then there's the potential direct effect of redistribution on growth. This is kind of the Arthur Oaken effect, the fact that high tax burdens can lower incentives to invest and that there may be labor supply effects of redistribution and so on. And then there's the direct effect of inequality on growth. There's various channels. And then the indirect or the total effect of redistribution would be the effect of redistribution on inequality and thereby on growth. Now, maybe the most interesting lines in this chart are the ones I haven't drawn. For example, redistribution could affect market inequality. Now, when I talk about the regressions, for some purposes that's not a major problem for us in terms of running our regressions, but for interpretation of some of the results, it's just going to be a maintained hypothesis, which I will talk about. Another is from growth to either inequality or redistribution. And we make some effort to isolate causality in the direction of these arrows, D&E, but it's always a challenge in these kind of exercises and it's a caution. So let me briefly review the evidence. I don't know if this is redundant or it's just going to be contradicted in the next presentation, but we'll find out. But there's a number of reasons why inequality could promote growth. Of course, it provides incentives. And we know, in fact, well, we know that at some point too little inequality can't be pro-growth. I mean, and so some of these channels must exist and it's just a question of this relative strength. But anyway, there's many old stories about that. There's a Caldor kind of story that rich people save more and invest more and so inequality could promote savings and investment. Barrow has an argument that this obviously depends on how rich the country is, but in relatively poor countries a higher level of inequality allows more people past the hump where they would have enough income to start a business, basically to generate some capital and get a business to the minimum required scale. And then as far as the evidence goes, obviously the literature is divided. There is some evidence that inequality promotes higher growth. We tend to see that the way we read it is that if you look at the variation within relatively short time periods within countries, you can get positive effects, negative effects, or no effects or nonlinear effects. It's a bit of a mess. So we tend to think that you do have to look at longer horizons and cross-country differences to get... Anyway, this support of evidence is from the short horizon, typically. So then there's reasons why inequality itself could promote growth. Obviously, it helps support, stay healthy, and accumulate human capital education and so on, because you might, of loosely speaking or broadly speaking, capital market imperfections that we know exist. It can support political and economic stability that promotes growth, perhaps through higher investment and so on. Danny Roderick has an old paper about the 80s crisis arguing that if you look at the terms of trade shocks and the global shocks that took so many countries onto a lost decade in the late 70s, early 80s, the punishment was a lot worse than the crime in terms of the size of the shock. It was small relative to the lost GDP and that if you try to understand who suffered so much and who didn't, it was sort of the unequal countries that had trouble adjusting to the shock and lost their way. In fact, Jeff Sachs, while I was student with Jeff Sachs, we wrote a paper on the debt crisis arguing that that was sort of a way of understanding which countries got into the debt crisis most in the 80s, following that same idea. And there's substantial empirical evidence supporting the idea that the quality can support growth. Now, we don't focus as much on this last and this next channel in the paper, and I won't talk about it so much here, but the evidence on whether market inequality does lead through political channels, does lead to more redistribution is mixed, I would say, and I'll come to that when we talk about the data. So then on redistribution, whether it will help or hurt growth, in a way there's relatively little on this topic, it seems to me, depending on how you phrase the question, but at the aggregate kind of level, there's not that much about it. Of course, there's a million papers on, there's a lot of papers on the effects of, say, taxes and sort of micro papers on labor supply effects of different specific policies and this huge literature on labor supply effects of things, but putting it together is harder. After all, redistribution, anyway, so it's, but there's, of course, the Oaken idea. There's some papers arguing that redistributive policies could help growth themselves, but those papers, in a way, combine the effects of redistribution itself and the effects of redistribution on equality and on growth. They don't necessarily distinguish that so much. I mean, the main, I think in the Beninbu paper, there's an idea of social insurance associated with redistribution. If you know that you can take chances and your failures will be alleviated but that may encourage innovation, which is sort of a direct channel from redistribution to innovation and growth. Anyway, we conclude that it's an empirical question and that it could go, that we shouldn't be so sure, as Sergeant is, about what the overall aggregate effects are. So the data. Now, most papers in the growth equality literature have kind of not paid that much attention to redistribution or really to the definition of equality in terms of is it market equality, is it net inequality that's being measured? And that's partly because the data sets sometimes often kind of contain, like the WID contains that information, but it doesn't make it, it's a hard problem to deal with. Sometimes people make kind of crude efforts to make an adjustment factor for the difference between market and net inequality and so on to make them comparable. But it's, you know, there's definition, in this crowd I guess I don't need to go through this, but there's lots of different ways you can measure inequality and the surveys in the cross country data sets vary in all these dimensions. This makes it hard to interpret growth regressions in, should we think in terms of market equality, market inequality, net inequality, and where is redistribution in these coefficients? It's also very hard to measure redistribution directly in general. Measures of redistribution, like the size of subsidies and transfers in the budget or the size of the government or the size of the tax take, those things are kind of correlated with our measure, pretty highly correlated with our measure, but the correlation coefficient sort of varies from 0.5 to 0.7. And most papers that, and so when you put something like the tax rate or something like that on the right-hand side, it's hard to know how to interpret that as a redistributive, as a measure of redistribution. Bronko Milanovic has a paper in 2000 looking at the question of whether unequal countries redistribute more and he actually measures redistribution directly kind of like we do, or I should say the other way around, we do it kind of like he did. He uses data for, you know, the data is hard to find so he does it just for the OECD and he finds relatively strong evidence in favor of this effect, this effect that unequal countries do tend to redistribute more. He once he measures redistribution correctly or more accurately. So we use this Solt standardized World Income Inequality Database that came out in 2009, he's been updating it. And briefly he takes, you know, the best, he takes the survey data that's out there and he uses an essentially regression-based method to try and create, you know, he categorizes every survey into one of, I think, 21 categories in terms of unit of account, you know, is it household, is it individual, is it net, is it gross, is it disposable income, is it consumption. And then he looks for the statistical relationships between these 21 categories and tries to kind of boil it down into one net and one market inequality measure for each country. Now in doing so, he does make use of, you know, there's some imputation and there's using these regressions to infer how to compare these different surveys. But the result is we get a large sample in principle comparable across countries in time of net and market inequality, which is what we need because for our techniques we need a big sample. For our regression techniques we need a big sample. So we see it as not perfect but the best for our purposes. We do quite a lot of sensitivity to try and see how, you know, different sub-samples affect the results and so on. And I'll show you some of that. I'll show you some of that. So just some stylized facts that we'll spend a lot of time on. The left panel is for the whole sample then OECD and non-OECD and OECD. So global median net inequality has been very stable but it's been declining. Market inequality has been rising in the OECD and declining in the rest. And the gap, of course, one important fact is that the gap between net and market is much higher. That's to say between, for example, this line much higher in industrial countries than in developing countries as we know that developing countries have less scope to redistribute. We heard from Brazil that it can be done. So anyway, that's just some of the patterns in the data. This is just a picture. This picture shows the inequality of market income on the horizontal axis and of net income on the vertical. So if a country doesn't redistribute the point will be along this line. And you can see here for the OECD that there's actually a relatively weak relationship between market inequality and net inequality. In other words, most of the difference across countries in market inequality on average is undone by the taxes and transfers of the fiscal system. Now that's true. This is a snapshot. We know that of the increase in the last 10 or 20 years a smaller than sort of typical fraction has been undone by redistribution. But anyway, that's... And if you look statistically at these relationships they hold up... This holds up in the OECD. It holds up in the non-OECD although it's weaker but it's statistically significant. I don't think I'm going to show that but that's just a regression of that picture. So we're just looking at the raw data. Here I'm just graphing the genie of net income on the horizontal axis with growth over the subsequent 10 years. Mean real per capita GDP growth. And you can see a fairly strong negative relationship. Now I don't know if those of you who've looked at, say, Barrow's book, you know, he shows a lot of pictures like this you can look at this two ways.  But this is, as these things go, it's pretty good, it seems to me. You know, it's not as good as investment but some of the things we think about like good institutions or something don't necessarily do that great in these pictures either. And then for redistribution we see essentially no relationship or if anything a slightly positive relationship between redistribution in genie points and growth over the subsequent 10 years. Now this is for spells. I'll define spells later when I get to the results if I have time but we're looking at the net genie at the beginning of the spell on the horizontal axis and this is the length of the subsequent spell. And so they vary, you know, there's some that are 40, 50 years long and presumably get truncated at the end of the sample. Many of them do get truncated. Many have kept going. And you can see something of a negative relationship. For redistribution, here you do see a bit of a negative relationship but it seems to be driven by these high redistribution a small number of observations. So what do we do? Our basic, I said we have these two sets of results. One is kind of traditional growth, panel growth regressions where we put the five-year average mean per capita growth rate on the left. We put initial income on the right. So column one is our baseline. We put initial income on the right. We put net inequality contemporaneously and redistribution contemporaneously. And then we use system GMM which means essentially that we're using lagged variables as instruments. And I'll come back to that. And what is our basic result is that net inequality has a significant negative effect on growth and redistribution has sort of no effect. I mean, it looks, the sign is positive but it's highly insignificant. Now, what we do, we don't, we're not really interested in the definitive growth regression here which not that it exists but so we added progressively various variables just to see how these results hold up. So we added investment in population growth and then investment population growth in education to put in the basic factors and then we kind of threw in a bunch of other stuff. You know, debt, political institutions and so on. And for, for, for our purposes here the main point is that inequality really holds up strongly in this business and that redistribution is never significant. And in fact, the difference between those two is significant. We can estimate redistribution precisely enough that we can say that the coefficients are not equal. So that's our core, that's our, this is our core sort of test of the Okan hypothesis. We thought we would get a negative coefficient on redistribution because of, you know, redistribution being bad for growth a negative coefficient on inequality and we would see which one was more negative. That's kind of a test of the trade off. But in fact, we didn't find any negative coefficient really on redistribution, at least in these regressions. So there's no evidence of a trade off here. See how I'm doing on my list of conclusions. So I'm on to the fifth one. Yeah, so the results are just not consistent with the notion that there's this big trade off that's really salient in the data. I guess I'm done with this. Okay, so these are these results graphically. This is the effect of, the first column shows the effect of increasing the net genie from 37 which is like the U.S. to Morocco, which is like 40. We didn't pick these with any, except because they fit the numbers. And that reduces growth by 0.5 percentage points from 5 to 4.5 percent holding everything else constant. Five minutes, okay. And then the direct effect of redistribution is almost zero. And then this total effect combines the direct effect of redistribution with the resulting effect on inequality. Now, in terms of this issue I raised at the beginning about distinct, well, about causality, to estimate the direct effects, we don't really care what the relationship is between inequality and redistribution. Once we've got them both in the regression, we can estimate the direct effects. It's true that for this last column where we want to say what the effect is of redistribution, we are maintaining the hypothesis that market inequality is not affected by redistribution. Now, we know that can't be right. We can't be wrong about redistribution. I want to make one point, which is that redistribution in principle should, for example, lower the labor supply at the top and the bottom, because you tax the rich and give to the poor, you can reduce labor supply at both ends. What the effect is on the relative wages is not clear. It's kind of a second-order effect, so to speak. So it's not obvious anyway that redistribution as a general matter should have a big effect, but we have effects. I don't have time to talk too much about the GMM issue, how we really isolate causality and whether that works, but we do subject to a number of diagnoses and we find that our results, for example, are robust to weak instrumentation, you know, and I can maybe come back to that. We get the same results even if we assume that our instruments, our lagged instruments are not strongly related to the variables of distribution. So about the data. So there's various ways you can use this sold data. You can use every observation or you can apply some screens to try and get the highest quality data.  It also only keeps a redistribution measurement if there's actually an actual series on some net inequality concept and some gross inequality concept for that country in question, so that you're not just using other country information to infer redistribution. Now we have various restricted samples, including one, for example, in which we keep only the five-year only an observation, which is a five-year average, if there's a net and a gross a net and a market measurement in that five-year period for that country. So we lose almost half the observations doing that and then we also put some other restrictions from in terms of throwing out questionable countries. And our results hold, essentially. Sometimes we lose... The result that inequality is significant and negative, that redistribution is not significant, the difference is usually significant, those hold even in these restricted samples. Now I don't have much time, I guess, to talk about spells. I have two minutes. Spells... I'm not going to say how we define growth spells, but we basically there's some interesting results on nonlinearities. As I hinted at the beginning, it's obvious that there must be a nonlinear relationship in all these variables. At some level, if inequality is zero, then increasing inequality is very likely to be pro-growth, and you think about China in 1980, for example, or the transition countries. In those previous regressions, we explored nonlinearities, looking if it mattered whether you already had higher or low inequality, and we found nothing in the data. It must be there, but it wasn't in our... Within the range we observed in the data, it was not there. In this growth sample, we did find that once you redistributed more than 75% of the sample, you started to see negative effects on the duration of growth. And so we divide into redistribution in the top 25% of the distribution of redistribution, that's to say the countries that redistribute the most, it can be adverse to the duration of growth. In this table, the number should be understood as like an odds ratio. So 1.06 here means that if you have a higher genie by one point, there's a 6% higher risk that the spell will end in the next period.  More, there's a higher chance that the spell will end. So we... We find... Yes, for redistribution, there is evidence of a nonlinear relationship. So we find that for countries below the 75th percentile, there's no negative effect. For countries above the 75th percentile, there may be one. And it's about equal to the magnitude of the effect of inequality. So even if you're above the 75th percentile, if you redistribute more, you know, that may not help growth. It doesn't seem like it hurts growth. And, of course, it may have its own merits on its own. And this is just a picture showing who's above the 75th percentile. You can see the UK and Australia are above. Canada's just below and so on. Now, the spell's results are more sensitive to the sample sizes. You're just asking more of the data. These spells, you have to measure the beginning. You need more data to get any kind of results with spells. So let me just conclude. My main conclusions already gave. Let me talk about caveats for one minute. Clearly, we don't want to overinterpret these results. They're just regressions. They're cross-country regressions. I think we haven't had a chance to talk about it. I think we made good effort to isolate causality, but we can't claim that it's iron-clad. It's very hard to do, that's for sure. And also, these are not controlled experiments. So we don't, you know, one of my colleagues at the IMF pointed out that countries may sort of be doing the amount of redistribution that they appropriately can do. We're not saying that Benin should go redistribute like Denmark. They don't have the institutions to redistribute like Denmark. So, you know, obviously it's dependent on the capacities of the country. It's dependent on the specificities of the case. And there's a number of caveats on those lines. We're just saying that this kind of if there were really a strong effect that redistribution, that Oaken was right and we should be afraid about redistribution, and that should be sort of the dominant thing in the data, we should see it, and we don't. So on average and across countries in time, government's efforts to redistribute do not seem to have led to bad growth outcomes, except possibly when they were extra. And I'll stop there. Thank you.