Re: [sage-devel] Re: Anyone used SBox.interpolation_polynomial?

[Friedrich Wiemer]

I discussed this again with my colleagues and maybe its just not so sure 
what the correct way to do is?

Is it actually clear what the "correct" ordering of finite field elements 
is? The canonical ordering is 0, 1, a^1, a^2, ..., - but then this 
representation and ordering depends on the representation of the actual 
instance, so which polynomial is picked. If instead the elements are 
ordered after the representing polynomial is chosen, we get 0, 1, a, a+1, 
... - but for example list(GF(2^3)) is differently ordered, depending on 
the chosen implementation. pari and ntl results in 0, 1, a, a+1, ... while 
givaro gives 0, a, a+1, ..., 1.

Regarding this, it might be ok to work with the output of 
`sorted(GF(...))`, as its done currently. Nevertheless, there remains the 
problem with different polynomials for representing the finite field and 
thus the resulting S-box might be different. Here is an example of what I 
mean:

sage: F1 = GF(2^3, name='a', modulus=PolynomialRing(GF(2), 'a')('a^3 + a + 
1'))
: F2 = GF(2^3, name='a', modulus=PolynomialRing(GF(2), 'a')('a^3 + a^2 
+ 1'))
: R1 = PolynomialRing(F1, 'x')
: R2 = PolynomialRing(F2, 'x')
: inv1 = R1.gen()**(2**3-2)
: inv2 = R2.gen()**(2**3-2)
: S1 = SBox([inv1(v) for v in sorted(F1)])
: S2 = SBox([inv2(v) for v in sorted(F2)])
: S1, S2
(0, 1, 5, 6, 7, 2, 3, 4),
(0, 1, 6, 4, 3, 7, 2, 5)

OK, so not so sure if this all makes sense in the context of the above 
question, but this behaviour should at least be mentioned in the docs, I 
think.
Regarding the above discussed point, I still think that the current 
behaviour is 'wrong' in the way that one would expect a different result.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Second opinion for first-time-reviewed ticket?

[Friedrich Wiemer]

One of my ticktes was reviewed by Lukas Stennes, who's first Sage review 
this is: https://trac.sagemath.org/ticket/26009
Does anyone wants to have an additional look over his review and my patch?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Anyone used SBox.interpolation_polynomial?

[Friedrich Wiemer]

Is there anyone who used the SBox.interpolation_polynomial?
Travis and I found a wird behaviour of the  SBox.__call__ regarding finitie 
field elements as inputs and think that this is a bug.This is fixed in 
#25633 but it would be nice if someone who used this input (e.g. indirectly 
with the `interpolation_polynomial` method) could review this change and 
check if this brakes something?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Accidentally merged and pushed other tickets branch

[Friedrich Wiemer]

Thanks to all for the quick help!

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Accidentally merged and pushed other tickets branch

[Friedrich Wiemer]

If I see this correctly, the commit history should be like this:
1b724d6 - worked on Jeroens comments
e8cd46b - Merge branch 'develop' into 
t/25742/change_c_variables_to_64bit_in_booleanfunction_cython_code

so the merge commit
2d7915a - Merge branch 'u/asante/sbox_boomerang_uniformity' of 
git://trac.sagemath.org/sage into 
t/25742/change_c_variables_to_64bit_in_booleanfunction_cython_code
needs to be undone.

Am Samstag, 24. November 2018 12:41:36 UTC+1 schrieb Friedrich Wiemer:
>
> In https://trac.sagemath.org/ticket/25742#comment:13 I accidentally 
> merged the ticket branch forom #25766 
> <https://trac.sagemath.org/ticket/25766>.
> Can someone help and tell me how to undo this? :/
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Accidentally merged and pushed other tickets branch

[Friedrich Wiemer]

In https://trac.sagemath.org/ticket/25742#comment:13 I accidentally merged 
the ticket branch forom #25766 .
Can someone help and tell me how to undo this? :/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] A Sage interface for FGb (Gröbner bases)

[Friedrich Wiemer]

Cool Markus, thanks a lot for sharing this! :)


Am Donnerstag, 22. November 2018 10:11:39 UTC+1 schrieb Thierry 
(sage-googlesucks@xxx):

> Unfortunately, the fact that is is neither free-software nor open-source 
> made it lower on my todo list. I wonder whether it could be possible to 
> kindly ask J.C. Faugere to free his code, especially since his work on 
> this is founded by the (french) public service. 
>

That would be really nice! 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] When the reviewer modifies some parts of the patch...?

[Friedrich Wiemer]

Thanks for the quick answer and also the answer on the ticket Jeroen.

Am Montag, 6. August 2018 10:09:41 UTC+2 schrieb Jeroen Demeyer:
>
> On 2018-08-06 10:06, Friedrich Wiemer wrote: 
> > is it ok, if I (as the original author), review this 
> > small change? 
>
> Yes. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: When the reviewer modifies some parts of the patch...?

[Friedrich Wiemer]

the clickable ticket link is https://trac.sagemath.org/ticket/25765

Am Montag, 6. August 2018 10:06:32 UTC+2 schrieb Friedrich Wiemer:
>
> In #25765 we have the situation that the reviewer changed some part of the 
> patch and the question now is, how to review this? Do we need a third 
> reviewer, or is it ok, if I (as the original author), review this small 
> change?
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] When the reviewer modifies some parts of the patch...?

[Friedrich Wiemer]

In #25765 we have the situation that the reviewer changed some part of the 
patch and the question now is, how to review this? Do we need a third 
reviewer, or is it ok, if I (as the original author), review this small 
change?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Poll about adopting matplotlib2 style for Sage graphics

[Friedrich Wiemer]

+1 for me.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: How parallel should @parallel be?

[Friedrich Wiemer]

I would also expect it to run as many threads as my laptop has cores (+ 
hyperthreading if available).

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Method Resolution Order

[Friedrich Wiemer]

Ahh, thanks!

Am Freitag, 6. Juli 2018 19:48:29 UTC+2 schrieb Nils Bruin:
>
> On Friday, July 6, 2018 at 9:40:16 AM UTC-7, Friedrich Wiemer wrote:
>>
>> So why is the _repr_() method from the matrix class called and not from 
>> LinearLayerGeneric?
>>
>> It is not. The special python method is __repr__. In various places in 
> sage, __repr__ delegates to _repr_, but that is a sage-local convention as 
> far as I can tell. You can check that the __repr__ you're inheriting is 
> sage.matrix.matrix0.Matrix.__repr__. It does not delegate to _repr_.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Method Resolution Order

[Friedrich Wiemer]

With this code (follow up of 
https://groups.google.com/forum/#!topic/sage-devel/4uxI1XVtoDs):
from sage.matrix.matrix_mod2_dense import Matrix_mod2_dense
from sage.matrix.matrix_gf2e_dense import Matrix_gf2e_dense


class LinearLayerGeneric:
def _repr_(self):
return "LinearLayer of dimension %d x %d represented by\n%s" \
% (self.dimensions() + (self.parent(self),))


def LinearLayer(L):
parent = L.parent()
return type("LinearLayerGF2", (LinearLayerGeneric, Matrix_mod2_dense), 
{})(parent, L)


ll = LinearLayer(matrix(GF(2), 2, 2, [1, 0, 0, 1]))

I would expect to see
sage: ll
LinearLayer of dimension 2 x 2 represented by
[1 0]
[0 1]

But what I instead get, is this
sage: ascii_art(ll, "  vs  ", ll._repr_())
   LinearLayer of dimension 2 x 2 represented by
[1 0]  [1 0]
[0 1]  vs  [0 1]

So why is the _repr_() method from the matrix class called and not from 
LinearLayerGeneric?

The LinearLayer class is also listed first in the __mro__:
sage: ll.__class__.__mro__
(,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 )

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Representation of LinearLayers in the crypto module

[Friedrich Wiemer]

Well, this seems to be due to another part of the file, I got a MWE to 
work, so I guess I will figure it out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Representation of LinearLayers in the crypto module

[Friedrich Wiemer]

Ah, this looks good!

Interestingly, while this works in the sage notebook, changing it in the 
module results in an
sage: from sage.crypto.linearlayer import LinearLayerFactory
sage: LinearLayerFactory(GF(2))(MatrixSpace(GF(2), 2, 2), [1,0,0,1])
---
TypeError Traceback (most recent call last)
 in ()
> 1 LinearLayerFactory(GF(Integer(2)))(MatrixSpace(GF(Integer(2)), 
Integer(2), Integer(2)), [Integer(1),Integer(0),Integer(0),Integer(1)])

/home/asante/werkstatt/werkbank/sage/local/lib/python2.7/site-packages/sage/
crypto/linearlayer.pyc in LinearLayerFactory(K)
 53 def LinearLayerFactory(K):
 54 if K.characteristic() == 2 and K.degree() == 1:
---> 55 return type("LinearLayerGF2", (LinearLayer, 
Matrix_mod2_dense), {})
 56 if K.characteristic() == 2 and K.degree() >= 1:
 57 return type("LinearLayerGF2E", (LinearLayer, 
Matrix_gf2e_dense), {})

TypeError: metaclass conflict: the metaclass of a derived class must be a (
non-strict) subclass of the metaclasses of all its bases

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Representation of LinearLayers in the crypto module

[Friedrich Wiemer]

Am Freitag, 6. Juli 2018 12:57:39 UTC+2 schrieb Friedrich Wiemer: 

> LinearLayer(test_m.parent(), test_m)
> test1._m.__class__.__mro__
>

this should of course be
test1 = LinearLayer(test_m.parent(), test_m)
test1._m.__class__.__mro__

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Representation of LinearLayers in the crypto module

[Friedrich Wiemer]

Hi,

I worked on an implementation of linear layers (basically a matrix over 
GF(2) or GF(2^n) with some special methods) in the crypto module during the 
sage days 94 and came up with this: #25735.

Martin commented that it might make sense to just inherit from an 
appropriate matrix class, to avoid another layer of indirection. Seems a 
totally valid point for me, so I'm now trying to find out, what would be 
the appropriate inheritance. As we only need matrices over GF(2) or 
GF(2^n), I assume the correct super class would be their common super class 
Matrix_dense. But when I implement it, e.g. like this:

%%cython
cimport sage.matrix.matrix_dense as matrix_dense
from sage.matrix.constructor import matrix

cdef class LinearLayer(matrix_dense.Matrix_dense):
cdef public object _m

def __init__(self, parent, entries=None):
m = matrix(parent, entries)
self._m = m

the matrix self._m "forgets" that it was a Matrix_mod2_dense or 
Matrix_gf2e_dense before:

test_m = random_matrix(GF(2**4), 4, 4)
test_m.__class__.__mro__
(,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 )

LinearLayer(test_m.parent(), test_m)
test1._m.__class__.__mro__
(,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 ,
 )


Thus operations which are specialised in Matrix_mod2_dense or Matrix_gf2e_dense 
are not available anymore.
Am I misunderstanding some concept here?

Thanks in advance for your help,
Friedrich

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Crypto] S-box Linear Approximation Matrix scaling

[Friedrich Wiemer]

I opened a ticket for this: #24819 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] [Crypto] S-box Linear Approximation Matrix scaling

[Friedrich Wiemer]

Ah, thats a very good idea!
Then I would suggest to extend this scaled argument to the following:

"bias" - return actual biases that is in [-0.5, 0.5]
"correlation" - return correlations, so in [-1, 1]
"absolute bias" - return biases*2^n (default)
"fourier coefficient" - return fourier coefficients, in [-2^n, 2^n]

With this, I guess, the doc-string can also be improved to make the default 
behavior clearer.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] [Crypto] S-box Linear Approximation Matrix scaling

[Friedrich Wiemer]

I recently stumbled across the fact that the implementation of 
SBox().linear_approximation_matrix() returns *scaled* Fourier coefficients.
While the documentation says exactly this, i.e., "[the matrix] encodes the 
bias[es]", my personal intuition is that this matrix should contain the 
actual Fourier coefficients.
In fact, the matrix is computed using the Fourier-Walsh transform for each 
component function and then scales the resulting matrix accordingly. On the 
other side, this scaling is then for other methods reversed (e.g. in the 
`nonlinearity` and `linearity` method).

Of course, my argument is basically only personal taste, but my feeling is 
that containing the *unscaled* Fourier coefficients is, what one would 
assume when only looking at the API and not at the documentation.
So, I propose to change this, but would like to hear your opinions on this?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Why doesn't #23931 get merged?

[Friedrich Wiemer]

OK, so its basically because lack of time?
Is this something a newbie contributer like me can help with?


Am Donnerstag, 7. Dezember 2017 16:02:56 UTC+1 schrieb Frédéric Chapoton:
>
> We have currently 115 such positive-reviewed tickets waiting for 
> inclusion, see
>
>
> https://trac.sagemath.org/query?status=positive_review=!sage-duplicate%2Finvalid%2Fwontfix=milestone=id=summary=type=component=changetime=author=reviewer=dependencies=40=1=changetime
>
> Le jeudi 7 décembre 2017 15:39:07 UTC+1, Friedrich Wiemer a écrit :
>>
>> The ticket #23931 <https://trac.sagemath.org/ticket/23931>has a positive 
>> review for quite some time and I'm not aware of any changes left for it, so 
>> my humble question is: Is there a reason this ticket isn't merged yet?
>> <https://trac.sagemath.org/ticket/23931>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Why doesn't #23931 get merged?

[Friedrich Wiemer]

The ticket #23931 has a positive 
review for quite some time and I'm not aware of any changes left for it, so 
my humble question is: Is there a reason this ticket isn't merged yet?


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Reviewing 'Memory leak in algebraic_immunity of BooleanFunction class' #14549

[Friedrich Wiemer]

And here, too: may I ask again for a review of this ticket?
Does anyone has an opinion on the discussion, where to fix the memory leak?

Should I provide more info in this posts here, or is the discussion 
supposed to take place in the comments of the tickets?

Am Mittwoch, 7. Juni 2017 10:55:21 UTC+2 schrieb Friedrich Wiemer:
>
> Hi
>
> Does someone has time to review my commit on issue #14549?
> https://trac.sagemath.org/ticket/14549#comment:10
>
> Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Reviewing list of SBox instances

[Friedrich Wiemer]

May I ask again for someone to review this ticket? Roed offere to do so, 
but I'm not sure what the "official" way to ask for this reviews again, is.

Am Mittwoch, 7. Juni 2017 14:58:43 UTC+2 schrieb Friedrich Wiemer:
>
> Hi
>
> Does someone has time to review my work on #22988?
> https://trac.sagemath.org/ticket/22988
>
> Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: About the patchbot queue

[Friedrich Wiemer]

Nice idea! I thought about the same, to set a patchbot up on some of our 
institutes idle servers, but did not succeed yet.
I'll tackle this again, when I have a bit more spare time.

Am Freitag, 7. Juli 2017 10:56:53 UTC+2 schrieb Eric Gourgoulhon:
>
> Thanks for your answer. 
> The author is not trusted probably because it is his first ticket in Sage. 
> What is the policy about this? Does an author become trusted after a first 
> ticket by him has been accepted? 
> I understand we are short of patchbots and I am considering setting up one 
> in my institute. 
> Best wishes,
> Eric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Reviewing list of SBox instances

[Friedrich Wiemer]

Hi

Does someone has time to review my work on #22988?
https://trac.sagemath.org/ticket/22988

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Reviewing 'Memory leak in algebraic_immunity of BooleanFunction class' #14549

[Friedrich Wiemer]

Hi

Does someone has time to review my commit on issue #14549?
https://trac.sagemath.org/ticket/14549#comment:10

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Refactoring SBox Code

[Friedrich Wiemer]

Martin Albrecht reviewed the code 
(https://trac.sagemath.org/ticket/22986#comment:5) and asked whether the 
SBox class should be available in the global namespace.
I don't have a opinion here, so I can just remove that import, or does 
someone think it should be available?


Am Mittwoch, 10. Mai 2017 15:19:20 UTC+2 schrieb Friedrich Wiemer:
>
> Martin Albrecht commented on issue 20336 (
> https://trac.sagemath.org/ticket/20336#comment:10) that the SBox code 
> should be moved from crypto.mq.SBox to some other place. I think that this 
> is a simple enough issue to get started contributing to the sage 
> development, so I'd like to work on this. Do you have any opinion, where 
> the code should go to? My suggestion would be crypto.sbox.
>
> Another nice thing would be, to have common sboxes available in this 
> module, like the AES sbox etc. I have a list of SBoxes from a colleague 
> that I could add. But again, I have no idea, what the best structure would 
> be. Maybe a dictionary of the form:
> sboxes['AES'] = SBox([...])
> sboxes['PRESENT'] = SBox([...])
> sboxes['Skinny'] = SBox([...])
> ?
>
> Thanks for your answers in advance, cheers
> Friedrich
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Refactoring SBox Code

[Friedrich Wiemer]

Am Mittwoch, 10. Mai 2017 15:32:17 UTC+2 schrieb Rusydi H. Makarim:
>
> Hi Friedrich,
>
> On 10-05-17 15:04, Friedrich Wiemer wrote:
>
> Martin Albrecht commented on issue 20336 (
> https://trac.sagemath.org/ticket/20336#comment:10) that the SBox code 
> should be moved from crypto.mq.SBox to some other place. I think that this 
> is a simple enough issue to get started contributing to the sage 
> development, so I'd like to work on this. Do you have any opinion, where 
> the code should go to? My suggestion would be crypto.sbox.
>
>
> Agree, crypto.sbox makes the most sense to me. A change would also be 
> required for other modules that depend mq.SBox, such as mq.SR in mq/sr.py 
> (This is the only module that I am aware of). Could you please open a 
> ticket for this issue ?
>

I opened https://trac.sagemath.org/ticket/22986 and commited the 
corresponding changes. There were also some changes in miniaes and sdes and 
in the documentation necessary.
If I build it correctly on my system, all doctests are passing (I'm not 
100% sure, as my system wide sage installation interfered a bit with the 
developing version, but that seems to be fine now). 

> Another nice thing would be, to have common sboxes available in this 
> module, like the AES sbox etc. I have a list of SBoxes from a colleague 
> that I could add. But again, I have no idea, what the best structure would 
> be. Maybe a dictionary of the form:
> sboxes['AES'] = SBox([...])
> sboxes['PRESENT'] = SBox([...])
> sboxes['Skinny'] = SBox([...])
> ?
>
>
> There will be a long list of S-Boxes in this case. My suggestion is to put 
> them in a separate module, say crypto.sboxes, and then create instance of 
> SBox for each sbox, e.g.
>
> AES = SBox([...])
> PRESENT = SBox([...])
>
>
OK that sounds like a reasonable design. I'll take a look at this.

Cheers,
Friedrich 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Extend crypto module

[Friedrich Wiemer]

Today I stumbled across https://trac.sagemath.org/ticket/11565 in where the 
design of the crypto module is briefly discussed and if there should be 
implementations of RSA and other stuff and if that could be helpful.
I thought a bit about this and discussed it with a friend and here are our 
ideas:

1) While RSA might be not the best cipher to point out the following, this 
certainly holds for block ciphers or other crypto primitives. During my 
research work I often implement some cipher scheme in python from scratch, 
because I want to tinker with it, maybe exchange some parts of it, etc. 
Having these things in sage with a highly modularized design would really 
ease this kind of work.

2) Having all the heavy mathematic stuff in sage, we can easily provide 
implementations of, say, AES that are in fact their mathematical 
descriptions. I think Rusydi H. Makarim already started working on this. In 
my opinion, this has at least two advantages: First it is a great 
educational tool for students to see, how this math "works in real" and 
helps them in getting a better understanding whats actually going on. 
Second it would allow to have a collection of reference implementations, 
which (because of the above modularized approach) allow to easily generate 
also intermediate test vectors. For me, this last point is really a big 
plus, because often you only get "coarse-grained" testvectors from cipher 
specifications like input/output of the whole encryption (sometimes also 
intermediate results after a single round or so) - but I have never seen a 
specification, which also provides intermediate results after the inner 
parts of a round function or so. If you want to implement some optimized 
version, you might be very happy, to have such test possibilities at hand.

3) So, from the end of point 2: It would also be nice, to have a lot of 
test vectors for crypto schemes - maybe its already enough to have these in 
the doctests, at least this would be a nice starting point.

4) This last point is somewhat of an abstraction above point 2, combined 
with 1. Going a level up, to the crypto-protocol level, it would be quite 
easy to implement protocols like TLS when all the basic crypto stuff is 
readily available. I was told that there is no free TLS implementation in 
python available, where you are actually able to exchange parts of the 
protocol (this again might be interesting if you are doing research on such 
a protocol). Regarding this point, I'm not sure if sage is the right place 
to have such a protocol level implementation, because its main aim seem to 
be a mathematical CAS.

What are your opinions regarding this?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Refactoring SBox Code

[Friedrich Wiemer]

Martin Albrecht commented on issue 20336 
(https://trac.sagemath.org/ticket/20336#comment:10) that the SBox code 
should be moved from crypto.mq.SBox to some other place. I think that this 
is a simple enough issue to get started contributing to the sage 
development, so I'd like to work on this. Do you have any opinion, where 
the code should go to? My suggestion would be crypto.sbox.

Another nice thing would be, to have common sboxes available in this 
module, like the AES sbox etc. I have a list of SBoxes from a colleague 
that I could add. But again, I have no idea, what the best structure would 
be. Maybe a dictionary of the form:
sboxes['AES'] = SBox([...])
sboxes['PRESENT'] = SBox([...])
sboxes['Skinny'] = SBox([...])
?

Thanks for your answers in advance, cheers
Friedrich

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.