It's not mentioned in the manual, but I can see people discussing
LibreSSL related patches and such...
Could you please comment on pyca/cryptography's support for LibreSSL
as a backend?
Thanks, Frank.
___
Cryptography-dev mailing list
Cryptography-dev@p
Issue 57: Adopt jwcrypto as a jose/jwk/jwe/jws hazmat module
https://github.com/pyca/cryptography/issues/3050
On Wed, Jul 20, 2016 at 2:02 AM, Simo Sorce wrote:
> On Mon, 2016-07-18 at 13:12 -0700, Frank Siebenlist wrote:
>> Did this discussion about jwcrypto integration in pyca/cry
change the license as we start working on it for
> real.
>
> Simo.
>
> On Tue, 2016-06-14 at 09:19 -0700, Frank Siebenlist wrote:
>> Hi Simo - if you could accommodate the jwcrypto-license to match
>> pyca/cryptography's... that would be fantastic and generous!!! -
>
it
simply returns, and there is only the overhead of the function call.
Unless I misunderstand the inner workings...
Regards, Frank.
On Thu, Jul 14, 2016 at 6:57 AM, lvh <_...@lvh.io> wrote:
> Hi Frank,
>
>> On Jul 14, 2016, at 12:23 AM, Frank Siebenlist
>> wrote:
>
is my last update on this observation.
Conclusion is "so be it", and using bigger chunks for hashing gives
(much) better performance.
-Frank.
On Tue, Jul 12, 2016 at 10:49 AM, Frank Siebenlist
wrote:
> After I sent my message yesterday evening, I was also wondering about
> that 512
ificantly more CPU cycles... hard
to phantom that you would see much slower performance when you pass a
single byte at the time in C...
On Tue, Jul 12, 2016 at 8:07 AM, lvh <_...@lvh.io> wrote:
> Hi,
>
>> On Jul 11, 2016, at 10:42 PM, Frank Siebenlist
>> wrote:
>
>
I ran in some unexpected timing issues while using pyca/cryptography’s
hash.SHA256,
and I’m wondering if there is something wrong with the timing discrepancy I see
between two different hashing approaches.
When I hash a single byte-string of 10million bytes, it seems to take 2-3
orders of magni
a good experience
>> learning about Curve/Ed25519 and the nacl/libsodium code though - also
>> trying to keep all data structures as immutable as possible was a good
>> exercise.
>
> It definitely has. I’m working on a blog post (series of blog posts) on
> crypto API design, p
:52 PM, Frank Siebenlist
wrote:
> Hi Laurens,
>
> I'm afraid that I have not been very good in explaining my use case, because
> the questions you ask point at more complicated solutions than I thought were
> necessary.
>
> The aim is to find the most convenient symmetric
016 at 3:53 PM, lvh <_...@lvh.io> wrote:
>
>> On Jul 1, 2016, at 12:54 PM, Frank Siebenlist
>> wrote:
>>
>> Hi lvh,
>>
>> Guess you're the "lvh" who is responsible for "lvh/caesium" ;-).
>
> Yup. I’m also a founding membe
ment it, implement it, use it!
Groetjes, Frank.
On Fri, Jul 1, 2016 at 9:51 AM, lvh <_...@lvh.io> wrote:
> Hi Frank,
>
>> On Jul 1, 2016, at 11:11 AM, Frank Siebenlist
>> wrote:
>>
>> snip snip key identifiers
>
> This is why some key derivation functio
Many times you will have two parties with a shared symmetric key that
they will use to communicate authenticated and private messages to
each other. If you have multiple keys, then you somehow have to match
the key to the received message based on the context, the sender, or
some key identifier tha
ust those implementations are not enough,
and that support for migration to different algos and work-factors are
very important.
Too many imperfect solutions... it's like real life ;-)
Could use some more advise or suggestions...
Thanks, Frank.
On Wed, Jun 15, 2016 at 11:12 AM, Frank Siebenlist
wrot
Hi Daniel - Thanks for the pointer! - Didn't know about this passlib
effort and it looks very comprehensive - I'll take a closer look -
Regards, Frank.
On Wed, Jun 15, 2016 at 9:09 AM, Daniel Neuhäuser
wrote:
> You should take a look at Passlib[1]. It provides support for all algorithms
> worth
Right - forgot about that effort... and forgot to "complain" that it
was not integrated with pyca/cryptography ;-)
On Tue, Jun 14, 2016 at 11:02 AM, Todd Knarr wrote:
> On 06/14/2016 10:25 AM, Frank Siebenlist wrote:
>>
>> Any good libraries available?
>> Ide
Hi pyca/cryptography community,
In my company, we're currently confronted with all the bcrypt vs pbkd2
vs scrypt vs argon discussions and choices. For each there are further
choices to be made about salts-sizes, hash-counts, hash-algos...
Currently pyca/cryptography only has a PBKDF2HMAC module i
Hi Simo - if you could accommodate the jwcrypto-license to match
pyca/cryptography's... that would be fantastic and generous!!! -
Thanks, Frank.
On Mon, Jun 13, 2016 at 6:06 AM, Simo Sorce wrote:
> On Sun, 2016-06-12 at 23:51 -0400, Paul Kehrer wrote:
>> In general I'm in favor of pulling jwcrypt
> ...snip...
> Questions for the pyca/cryptography community:
>
> * Any others who share the need/dream for such a high-level, simple
> Fernet-style library based on jose/jwt?
>
> There has been some conversation along these lines in
> https://github.com/pyca/cryptography/issues/2900 and continuing
Hi pyca/cryptography community,
We're looking to migrate away from pycrypto - most probably to
pyca/cryptography.
Pretty sure there will be no objections to that choice on this mailing list. ;-)
We also have internally developed libraries for symmetric-key message
encryption and such, which we’
19 matches
Mail list logo
