It’s not possible to change the security level. It’s fixed at 128 bit of security. Possibly, in the future, we’ll allow to increase the security level (with like 192 or 256b) but already, 128b is a lot. About having smaller levels: not sure, it’s always dangerous, some inexperienced users may decrease the level “because it’s faster” without really understanding the consequences.
Why do you want to change the security level, by the way? LogisticRegression are really really fast (there is no PBS). Even XGB are quite fast (but here, there are PBS, and it depends on your ML hyper parameters)
yes, it is quite fast - my supervisor has suggested experimenting with security levels for my dissertation. I can do so in tenseal but not in concrete ml.
yes sorry, changing the security model will not be doable for the moment. Of course, reducing the security level would make things faster, but, you lose the security.
Is it now possible to set the security level yourself? I want to benchmark my approach against a previous baseline, but the previous baseline just achieves 80-bit of security. To make a fair comparison, I’m interested in also providing the performance results of my concrete implementation using just 80-bits of security.
In the documentation [1], it seems as if it should be possible to set the security level using an integer value (with the default being 128-bit security). But trying that results in an unexpected type error. From the source [2], it seems that at the moment there is only support for 128 and 132-bit security, but the 132-bit option is not exposed through the API?
There is also this self-contained commit that adds the 132-bit curves [3]. Is there anything against trying to add curves for 80-bit security and compiling Concrete myself?
Sure, I would be interested in benchmarking against these two papers [1, 2]. What do you think? Is it possible to add the 80-bit curves like in the aforementioned commit and compile Concrete myself?
Thank you for your fast response! It would be really useful to adapt the security level to compare concrete implementations to previous works. It seems to me that there are many previous works with != 128-bit security.
Sure, that’s clear, and of course, I am also interested in the results with 128-bit security.
Here, I am only interested in a performance comparison with previous work that only achieved 80-bit security and did not report performance results for 128-bit security. The goal is to assess the performance of a new approach compared to previous work.
What do you think? Are such comparisons not useful if previous works only achieve 80-bit security?
Thanks @hallojs. As said by @andrei-stoian-zama , we don’t support 80b security. I personally don’t see the point of being faster in 80b eg, since anyway, things are insecure. I understand however it doesn’t simplify comparison with earlier work. I would use benchmarks with 128b of security in my papers, and if ever you compare with a previous 80b work, I would have a big warning to say the security levels are really different.