On 17/10/17 20:36, Nick Lamb via dev-security-policy wrote:
The bitmasks are effectively lists of expected remainders for each small prime,
if your modulus has an expected remainder for all the 20+ small primes that
distinguish Infineon, there's a very high chance it was generated using their
On 2017-11-22 21:10, Rob Stradling via dev-security-policy wrote:
> On 22/11/17 11:45, marcan via dev-security-policy wrote:
>> On 22/11/17 20:41, Tom via dev-security-policy wrote:
Although not listed in the Action plan in #1311824, it is noteworthy
that Richard Wang has apparently not
On 2018-01-13 12:38, josh--- via dev-security-policy wrote:
> Another update, the main thing being that we have deployed patches to our CA
> that allow TLS-SNI for both renewal and whitelisted accounts, as we said we
> would in our previous update:
>
>
On 2018-03-02 02:56, Hector Martin 'marcan' via dev-security-policy wrote:
> On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
>> Hi,
>>
>> On twitter there are currently some people poking Trustico's web
>> interface and found trivial script injections:
>
On 2018-03-02 15:24, Todd Johnson wrote:
> Did *anyone* capture this information in a way that can be proven?
>
> While I personally would not trust any content from either hostname, the
> Twitter post referenced earlier is not sufficient proof of key compromise.
Unfortunately, the server
On 2018-03-02 13:32, grandamp--- via dev-security-policy wrote:
> The web site is back up, with the same certificate being used. That said, it
> *is* possible that the certificate was managed by their load balancing
> solution, and the private key for (trustico.com) was not exposed.
>
>
On 2018-03-02 00:28, Hanno Böck via dev-security-policy wrote:
> Hi,
>
> On twitter there are currently some people poking Trustico's web
> interface and found trivial script injections:
> https://twitter.com/svblxyz/status/969220402768736258
>
> Which seem to run as root:
>
On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> Is this new from the past discussion?
I think what's new is someone actually tried this, and found 5 CAs that
are vulnerable and for which this attack works in practice.
>
On 19/12/2018 20:09, Rob Stradling via dev-security-policy wrote:
I'm wondering how I might add a pwnedkeys check to crt.sh. I think I'd
prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB.
Yes, I think the right approach for an upstream source is to provide a
big list of
On 16/03/2019 10:25, Jan Schaumann via dev-security-policy wrote:
someapp.example.com, over which I have control is a CNAME, so I can't
set a CAA record there. Let's say the CNAME points to
ghs.googlehosted.com.
Your suggestion is to contact Google and ask them to please add a CAA
record to
On 19/03/2019 02.17, Rob Stradling via dev-security-policy wrote:
> On 18/03/2019 17:05, Kurt Roeckx wrote:
>> On Mon, Mar 18, 2019 at 03:30:37PM +, Rob Stradling via
>> dev-security-policy wrote:
>>>
>>> When a value in column E is 100%, this is pretty solid evidence of
>>> noncompliance
On 18/03/2019 16:42, Corey Bonnell wrote:
Perhaps not very elegant, but you can encode an “allow all issuers” CAA
RRSet by specifying a single iodef CAA record without any
issue/issuewild records in the RRSet, which will probably be treated as
permission to issue for CAs. I say “probably”
On 15/03/2019 07:13, Jaime Hablutzel via dev-security-policy wrote:
64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a
CSPRNG with at least one bit in the highest byte set to 1
is, strictly speaking, not true. The best possible implementation for
GetRandom64Bits(), as
On 15/03/2019 13:26, Peter Gutmann via dev-security-policy wrote:
I actually thought it was from "Chosen-prefix collisions for MD5 and
applications" or its companion papers ("Short chosen-prefix collisions for MD5
and the creation of a rogue CA certificate", "Chosen-Prefix Collisions for MD5
and
On 12/03/2019 07:54, Ryan Sleevi via dev-security-policy wrote:
On Mon, Mar 11, 2019 at 5:35 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Since choice 1 is a logical consequence of "containing 64 bits of random
data", I was always under the
On 12/03/2019 21.10, Mike Kushner via dev-security-policy wrote:
>>> There are no, and has never been any, 63 bit serial numbers created by
>>> EJBCA.
>>
>> ... lead me to significantly reduce my trust in those making them, and
>> their ability to correctly interpret security-critical standards
On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> Note that even 7 bytes or less may still be valid - for example, if the
> randomly generated integer was 4 [1], you might only have a one-byte serial
> in encoded form ( '04'H ), and that would still be compliant. The general
>
On 06/04/2019 03.01, Lijun Liao via dev-security-policy wrote:
> 5. Related to how the MD5 attacks you might be right. But theoretically,
> and also in practice, if you have enough bits to play and the hash
> algorithm is not cryptographically secure, you can find a collision with
> less
18 matches
Mail list logo
