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

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

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

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.

[sage-devel] Anyone used SBox.interpolation_polynomial?

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

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

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] Re: Accidentally merged and pushed other tickets branch

://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 bra

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

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.

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

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

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

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? > > Y

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

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 nee

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

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

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

+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] Re: How parallel should @parallel be?

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] Re: Method Resolution Order

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? >> >>

[sage-devel] Method Resolution Order

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

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

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

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

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])

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

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 s

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

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

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

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

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

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

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

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

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

t; > > 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 <htt

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

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

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

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" gro

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

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 w

[sage-devel] Re: About the patchbot queue

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

[sage-devel] Reviewing list of SBox instances

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] Reviewing 'Memory leak in algebraic_immunity of BooleanFunction class' #14549

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

[sage-devel] Re: Refactoring SBox Code

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 start

Re: [sage-devel] Refactoring SBox Code

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 fro

[sage-devel] Extend crypto module

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

[sage-devel] Refactoring SBox Code

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.