On Wed, Aug 05, 2015 at 09:33:02PM +0200, Kurt Roeckx wrote:
> On Wed, Aug 05, 2015 at 04:54:57PM +0000, mancha wrote:
> >
> > I interpret the comment to mean that, because OpenSSL lists modify
> > messages (see below), they should strip DKIM headers (see above)
> > bef
gt; dkim=fail (1024-bit key) reason="fail (message has been altered)"
> > header.d=zimbra.com
>
> You really should consider moving to at least a 2048 bit key.
Good suggestion though orthogonal to the issue.
--mancha (https://twitter.com/mancha140)
pgpGuFx7MTUHU.pgp
Desc
ercent of the
> currently acceptable keys, won't take much time to run, and would
> defeat cyber attempts to create a key with a significant common factor
> within it.
>
> Thanks
>
> Paul Cheffers
Given the low costs, one would be hard-pressed to find an intelligent
obje
d(p^2-1, q^2-1) < 10^6.
That's an interesting formulation. What's the importance of 10^6?
Thanks.
--mancha (https://twitter.com/mancha140)
>
> Hilarie
pgppgOu9zL1ue.pgp
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Sat, Aug 01, 2015 at 01:50:00PM +, Ben Laurie wrote:
> On Sat, 1 Aug 2015 at 14:22 mancha wrote:
>
> > On Fri, Jul 31, 2015 at 06:46:22PM +, Viktor Dukhovni wrote:
> > > On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote:
> > >
> > > >
On Fri, Jul 31, 2015 at 06:46:22PM +, Viktor Dukhovni wrote:
> On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote:
>
> > Cool observation. From running a bit of Python code, it looks like
> > the probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at
> > least for random numbe
On Fri, Jul 31, 2015 at 11:31:08PM +, p...@securecottage.com wrote:
> Hi Mancha,
>
> Since p*q-1==(p-1)*(q-1)+(p-1)+q-1) any prime that divides (p-1) and
> (q-1) will divide all 4 of the terms in the definition of p*q-1. Thus
> it will be a common factor in the totient.
Hi Pa
he end of the week and the neurons need respite so please let
me know if I'm missing something.
--mancha
--
https://twitter.com/mancha140
pgpuPoMiAQmxY.pgp
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
n_There_Are_Common_Factors_Between_.28P-1.29_and_.28Q-1.29
[SNIP]
Hi. How are you finding a common factor f such that f|(p-1) and f|(q-1)?
Thanks.
--mancha
-- https://twitter.com/mancha140
pgpAx_elyqxEZ.pgp
Description: PGP signature
___
openssl
Hi.
Vulnerability tester for CVE-2015-1793 (alternative chains certificate
forgery) based on Matt Caswell's test now available:
https://twitter.com/mancha140/status/619316033241923585
--mancha
pgp5yz3YFF0V2.pgp
Description: PGP signature
___
op
Dan McDonald -- OmniOS Engineering
Hi Dan. Many thanks for your report. I've checked and the issue you've
identified potentially affects OpenSSH 4.7 through 6.5, inclusive.
OpenSSH 6.6 replaces the OpenSSL HMAC with its own implementation making
the ABI change a NOP for OpenSSH 6.6 onwards.
b.com/mancha1/openssl/commit/a59f22520bb5.patch), remove
the first hunk (to CHANGES), and apply it.
--mancha
pgpgKICc2PbF4.pgp
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Thu, May 21, 2015 at 03:29:23AM +, mancha wrote:
> On Wed, May 20, 2015 at 11:31:00PM +0200, Kurt Roeckx wrote:
> > On Wed, May 20, 2015 at 08:58:54PM +0000, mancha wrote:
> > > On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote:
> > > > On Wed, Ma
On Wed, May 20, 2015 at 11:31:00PM +0200, Kurt Roeckx wrote:
> On Wed, May 20, 2015 at 08:58:54PM +0000, mancha wrote:
> > On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote:
> > > On Wed, May 20, 2015 at 07:11:42AM +, mancha wrote:
> > > > Hello.
>
On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote:
> On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote:
> > Hello.
> >
> > Given Adrien et al. recent paper [1] together with their
> > proof-of-concept attacks against 512-bit DH groups [2], it might be
>
demo.cmrg.net:443 < /dev/null
--mancha
PS My understanding is Google Chrome will soon be rejecting all DH
groups smaller than 1024 bits.
pgpY4hEOloNIZ.pgp
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mail
< /dev/null
--mancha
PS My understanding is Google Chrome will soon be rejecting all DH
groups smaller than 1024 bits.
pgp_TrBuHeXcL.pgp
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/open
ull
--mancha
PS My understanding is Google Chrome will soon be rejecting all DH
groups smaller than 1024 bits.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
terion:
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
Has there been significant cryptanalysis done on ChaCha20-Poly1305? My
quick scan reveals a dearth of peer-reviewed literature.
--mancha
pgpda3AvPyuW3.pgp
Description: PGP signature
__
Emails sent to an RT issue are automatically forwarded by the system to
the openssl-dev ML. There's no need to explicitly cc: openssl-dev as
you're doing - all that does is clutter the ML with duplicates.
--mancha
pgpZ4yK6BYk8V.pgp
Description: PGP signature
Emails sent to an RT issue are automatically forwarded by the system to
the openssl-dev ML. There's no need to explicitly cc: openssl-dev as
you're doing - all that does is clutter the ML with duplicates.
--mancha
pgpEIPrzJdpDY.pgp
Description: PGP signature
;m=141387182603109&w=2).
I long ago trained myself to read base64 while building up an immunity
to iocaine powder but others might have trouble.
--mancha
pgp9aQHfUMjfz.pgp
Description: PGP signature
I
presume is why there are no MITRE CVE designations for the behavior per
se). However, one can make a strong case protocol fallback
implementations that are MITM-triggerable deserve CVE designations.
TLS_FALLBACK_SCSV could then be accurately described as partially
mitigating those CVEs.
ks for the OOB patch that I just saw commited to git.
Any reason for the s_client -fallback_scsv option check to be within an
#ifndef OPENSSL_NO_DTLS1 block?
Thanks.
--mancha
pgpQP0dloJSeZ.pgp
Description: PGP signature
ou allude to. Can you
provide a link?
--mancha
pgpB_rbIzvfJz.pgp
Description: PGP signature
xed this defect until you sent the above link.
Matt:
Now you have more to go on. The OpenBSD commit predates Kurt's report in
RT by about 11 days. Given this new information, you should pro-actively
request that Kurt explain the particulars and make sure attribution is
corrected,
On Tue, May 27, 2014 at 08:23:29AM +0200, Otto Moerbeek wrote:
> On Tue, May 27, 2014 at 05:23:45AM +0000, mancha wrote:
>
> > On Mon, May 26, 2014 at 09:01:53PM +, mancha wrote:
> > > On Mon, May 26, 2014 at 08:49:03PM +, Viktor Dukhovni wrote:
> > > > O
On Mon, May 26, 2014 at 09:01:53PM +, mancha wrote:
> On Mon, May 26, 2014 at 08:49:03PM +, Viktor Dukhovni wrote:
> > On Mon, May 26, 2014 at 08:20:43PM +0000, mancha wrote:
> >
> > > For our purposes, the operative question is whether the
> > > distribut
On Mon, May 26, 2014 at 08:49:03PM +, Viktor Dukhovni wrote:
> On Mon, May 26, 2014 at 08:20:43PM +0000, mancha wrote:
>
> > For our purposes, the operative question is whether the distribution
> > bias created can be leveraged in any way to attack factoring (RSA)
> >
posites.
For our purposes, the operative question is whether the distribution
bias created can be leveraged in any way to attack factoring (RSA) or
dlog (DH).
--mancha
pgp8Sh6nO8iDZ.pgp
Description: PGP signature
n assigned CVE-2014-0198. Any news on an
OpenSSL fix?
Thanks.
--mancha
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.or
do in this case ?
>
> Regards,
> Lokesh
Hello.
You are more likely to receive help through Amazon support or
openssl-users. The development list is concerned primarily with
development.
Thank you.
--mancha
pgpNjHFuwB9X9.pgp
Description: PGP signature
related to *what* should be
protected not on the effectiveness of *how* it is protected. The *how*
also merits close review. One immediate observation I have on that
front is that secure_malloc_init() is never called.
--mancha
[1] https://tools.ietf.org/html/rfc3447
akamai.pl
Description: Perl program
pgp4KhDIjk_fD.pgp
Description: PGP signature
ouse improvements, consider reciprocating by making your
enhancements available to the community. No need to wait until the next
disaster.
--mancha
PS I cleaned the patch up a bit (i.e. swapped in the correct cmm_init)
and include it here. It applies cleanly to 1.0.1g which then builds fine
on Linux with -pth
rsion: 1.0.1g
>
>Github Issue (for tracking):
>https://github.com/openssl/openssl/issues/57
I prepared these a while back to deal with the stricter pod2man syntax
in perl 5.18+ (note: the 1.0.1f patch applies fine to 1.0.1g).
http://sf.net/projects/mancha/files/misc/openssl-0.9.8y-perl-5.
rsion: 1.0.1g
>
>Github Issue (for tracking):
>https://github.com/openssl/openssl/issues/57
I prepared these a while back to deal with the stricter pod2man syntax
in perl 5.18+ (note: the 1.0.1f patch applies fine to 1.0.1g).
http://sf.net/projects/mancha/files/misc/openssl-0.9.8y-perl-5.
the security implications,
ambiguities in specifications, variability in client implementations,
etc. Maybe that's a topic best suited for the uta wg.
--mancha
__
OpenSSL Project http://www
alert handling
(see http://marc.info/?t=13676007772&r=1&w=2 for details).
--mancha
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-de
ot;
(i.e. GF(2^m)).
>It doesn't appear that the fix has been applied to the
>OpenSSL_0_9_8-stable branch yet though. I suppose it might need a
>few tweaks to apply there cleanly...
The tweaks are minimal and I've placed a backport here:
http://sf.net/projects/mancha/files/sec
he command below
>
>x509 -req -in server.csr -signkey server.key -out server.crt
Hello.
Sign with -sha256:
openssl x509 -req -sha256 -in server.csr -signkey server.key -out
server.crt
--mancha
PS openssl-users is probably better suited for this type of
question. This list
/github.com/openssl/openssl/commit
/59b1129e0a50fdf7e4e58d7c355783a7bfc1f44c
--mancha
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Aut
mancha hush.com> writes:
> Yet another bug report I came upon by accident (not an Ubuntu user):
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1144408
>
> From the report I gather this issue affects all users of Ubuntu's
> "Lucid" version.
>
mancha hush.com> writes:
>
> Hello.
>
> I never received a reply to this patch submission but wanted
> to follow up because I am receiving update requests from affected
> users (e.g. http://sourceforge.net/p/curl/bugs/1037/?page=3).
>
> I imagine 0.9.8 is in featu
d:warning:unrecognized name
> SSL3 alert write:warning:close notify
>
> Patch applies cleanly to OpenSSL_0_9_8-stable (HEAD a44c9b9c)
> and makes behavior consistent with OpenSSL 1.0.1e. Also, it
> adds support for new alerts (RFC 6066 and RFC 4279).
>
> Please consider it
for those who might find this useful.
Cheers.
--mancha
openssl-0.9.8y-s_client-proxy.patch
Description: Binary data
openssl-1.0.1e-s_client-proxy.patch
Description: Binary data
pport for new alerts (RFC 6066 and RFC 4279).
Please consider its inclusion after appropriate code review.
--mancha
Note: A higher-level discussion is whether non-fatal
unrecognized_name alerts should be sent at all. Per RFC 6066,
"If a server name is provided but not recognized, th
with 0.9.x.
The attached patch modifies crl.c and crl.pod and applies cleanly
to 1.0.1c.
Please consider its inclusion.
Best,
mancha
Add a flag to crl to generate legacy hashes as used by OpenSSL pre-1.0.
-mancha
===
--- a/apps/crl.c 2012-07-16
+++ b/apps/crl.c 2012-07-16
@@
47 matches
Mail list logo
