This thread is amazing. I've known just a fractions/hints of the practices
described here. Few comments/questions inline/below.
On 12/04/11 07:37, Lucky Green wrote:
Concur. The standard sub-CA contracts contain a right to audit the
number of certs issued, like any enterprise-wide software
On 12/04/11 13:08, Peter Gutmann wrote:
Ondrej Mikle ondrej.mi...@nic.cz writes:
How do MitM boxes react when they MitM connection to a server with self-
signed cert (or cert issued by an obsure CA not trusted by MitM box)?
For one example, see
http://wikileaks.org/spyfiles/docs/bluecoat
On 12/05/2011 04:21 AM, Lucky Green wrote:
On 2011-12-04 12:09, Ondrej Mikle wrote:
[...]
I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason,
about month after Peter Eckersley did. Result was the same (counting trusted
CAs). Plus few others (some seemed to be internal
Hi,
what are the known attacks when pin is created to a CA certificate by
SubjectPublicKeyInfo (SPKI) compared to pinning by full certificate (or
hash of full certificate)?
Some I could think of:
1. Extending certificate chain
Let's have server-cert SC1 that directly chains to CA-cert I1
On 02/22/2012 10:55 PM, Marsh Ray wrote:
I'm putting myself in the position of an engineer who's designing the
logic and writing some low-level firmware for the next consumer grade
$50 blue box home router/wifi/firewall appliance:
=== [cue dream sequence wavy blur effect]
I'm an EE
On 02/24/2012 12:00 AM, Michael Nelson wrote:
Ondrej Mikle wrote:
I took some first 80 results from crunching the moduli
and mapped them back to certificates. In EFF's SSL
Observatory there were 3912
unique certs sharing those
factorized moduli (all embedded devices), couple
extra
Hi,
here is an attempt to summarize view of crypto from engineers' point of view.
It's based on discussing the points raised in the Duplicate primes... thread
with couple of HW/SW engineers and past experience with colleagues.
Sorry for the length, this post grew quite a bit.
Hopefully I caught
On 02/26/2012 04:47 AM, Kevin W. Wall wrote:
On Sat, Feb 25, 2012 at 2:22 PM, Ondrej Mikle ondrej.mi...@nic.cz wrote:
Estimating RSA key size: it's more an educated guess/magic given how the
sizes
are derived than anything else. And if you base your estimate for given time
window
On 05/25/2012 08:19 PM, Jon Callas wrote:
My money would be on a combination of traffic analysis and targeted malware.
We know that the Germans have been pioneering using targeted malware against
Skype. Once you've done that, you can pick apart anything else. Just a simple
matter of coding.
Following work offers interesting followup on reverse-engineering how the Flame
MD5 collision attack was done:
http://www.illc.uva.nl/Research/Reports/MoL-2013-23.text.pdf
According to the author, the attack was similar to Stevens et al.'s
chosen-prefix attack, but employs a bit more brute-force
Hi,
the table listing security properties at [1] notes that secp256k1 curve fails in
these two categories, among others:
a) Ladders
Does this mean that an implementation of secp256k1 is likely to have timing
side-channel attacks? Is there some suitable analogy of RSA blinding that could
be used
On 01/12/2014 03:26 PM, Krisztián Pintér wrote:
as a side note: for any readers thinking but this is nitpicking,
besides it is not, there are other, worse problems with NIST curves.
Could you elaborate what you mean by other, worse problems with NIST curves?
I've tried looking for a rather
Hi,
I have an embedded Linux (openwrt) device here, that might suffer from the known
entropy hole that caused predictable keys to be generated in past. Fortunately,
the device has HW RNG (ATSHA204 to be precise).
The plan is to seed /dev/urandom from the HW RNG upon boot, by feeding 512 bytes
Could anyone give an example what flaws a secp256k1 implementation needs to have
in order to succumb to the fault attack described in this tweet:
https://twitter.com/pbarreto/status/392415079934615552 ?
It mentions that an implementation is susceptible unless the implementation
checks everything,
On 06/30/2014 05:49 PM, Billy Brumley wrote:
What cryptosystems, and furthermore protocols, you can attack and how
you carry out the attack very much depend on the nature of the
fault/defect and the details of the protocol.
Shameless self promotion: https://eprint.iacr.org/2011/633
Thanks,
On 10/13/2014 06:14 PM, Tony Arcieri wrote:
On Mon, Oct 13, 2014 at 7:51 AM, Derek Miller dreemkil...@gmail.com
mailto:dreemkil...@gmail.com wrote:
If the NIST curves are weak in a way that we don't understand, this
means that ECC has properties that we don't understand.
While
On 06/16/2015 05:53 PM, John R. Levine wrote:
Are there any password managers that let the user specify where to
store a remote copy of the passwords (FTP server, scp, Dropbox,
whatever) while keeping the crypto and the master password on the end
devices?
KeePass 2 claims to have
On 06/16/2015 06:20 PM, Tim wrote:
Are there any password managers that let the user specify where to
store a remote copy of the passwords (FTP server, scp, Dropbox,
whatever) while keeping the crypto and the master password on the end
devices?
Take a look at
On 11/19/2015 10:20 PM, Jan Suhr wrote:
> Nitrokey Storage is a USB device which operates as a “digital latchkey”
> to protect your data and user accounts.
Can you compare it to Yubikey Neo/Yubikey 4?
As far as I can see, Nitrokey has only the file encryption on top of
Yubikey. Both Yubikey and
19 matches
Mail list logo
