On Mon, Apr 07, 2014 at 11:02:50PM -0700, Edwin Chu wrote:
I am not openssl expert and here is just my observation.
[...]
Thanks for this analysis.
Sadly, a variable-sized heartbeat payload was probably necessary, at
least for the DTLS case: for PMTU discovery.
Once more, a lack of an IDL,
On Tue, Apr 08, 2014 at 01:12:25PM -0400, Jonathan Thornburg wrote:
On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:
While everyone's madly rushing around to fix their bitsbobs, I'd
encouraged you all to be alert to any evidence of *damages* either
anecdotally or more firm. By
On Mon, Mar 31, 2014 at 12:45 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
The paper [2] also has more about exploiting dual-ec if you
know a backdoor that I've not yet read really.
[2] http://dualec.org/
That paper talks about servers. What is the prevalence of Dual_EC on
the
On Sat, Mar 22, 2014 at 12:59 AM, Stephan Neuhaus
stephan.neuh...@tik.ee.ethz.ch wrote:
On 2014-03-22, 04:28, Nico Williams wrote:
Insiders are always your biggest threat.
I'm always interested in empirical evidence for the things that we
believe to be true. Do you have any?
[The context
On Fri, Mar 21, 2014 at 7:01 AM, John Young j...@pipeline.com wrote:
Sys admins catch you hunting them and arrange compromises
to fit your demands so you can crow about how skilled you are.
Insiders are always your biggest threat.
Then you hire them after being duped as you duped to be hired.
On Fri, Jan 3, 2014 at 1:42 PM, coderman coder...@gmail.com wrote:
- are you relieved NSA has only a modest effort aimed at keeping an
eye on quantum cryptanalysis efforts in academia and other nations?
But clearly you must not be.
If you want to assume quantum cryptanalysis then you should
Power management is an issue. Therefore entropy collection cannot be
periodic, not with high frequency anyways.
Instead collection must happen as needed and/or opportunistically, and
as much entropy should be collected as possible without increasing
latency by too much. Opportunistic collection
On Mon, Nov 25, 2013 at 09:51:41PM +, Stephen Farrell wrote:
New work on improving hop-by-hop security for email and other
things is getting underway in the IETF. [1] Basically the idea
I see nothing in the proposed charter you linked to about hop-by-hop
security.
I could imagine something
On Wed, Nov 27, 2013 at 06:02:08PM +, Stephen Farrell wrote:
On 11/27/2013 05:42 PM, Nico Williams wrote:
On Mon, Nov 25, 2013 at 09:51:41PM +, Stephen Farrell wrote:
New work on improving hop-by-hop security for email and other
things is getting underway in the IETF. [1] Basically
On Wed, Nov 27, 2013 at 08:01:19PM +, Stephen Farrell wrote:
On 11/27/2013 06:58 PM, Nico Williams wrote:
[...]
I'm not sure detecting the path length in terms of ADMDs is so
easy, not so useful in terms of MTAs (with all the spam checking
Sure it is! Nowadays the path should
Viktor Dukhovni says that anything like DKIM/SPF is bound to fail.
One problem is confusables: users can't really distinguish them, and
some can be counted on just doing whatever it takes to give their money
to the phisher, no matter what. In other words, the problem with e-mail
is that
On Saturday, November 2, 2013, Roth Paxton wrote:
Check out www.cryptographyuniversal.com
The first few paragraphs are incomprehensible and defensive. A perfect
sign that reading further is a waste of time. If the author's paper was
rejected so and so then telling the world that they're just
On Fri, Oct 4, 2013 at 11:48 PM, Jeffrey Goldberg jeff...@goldmark.org wrote:
On 2013-10-04, at 10:46 PM, Patrick Pelletier c...@funwithsoftware.org
wrote:
On 10/4/13 3:19 PM, Nico Williams wrote:
b) algorithm agility is useless if you don't have algorithms to choose
from, or if the ones
On Fri, Oct 4, 2013 at 4:58 PM, Jeffrey Goldberg jeff...@goldmark.org wrote:
On 2013-10-04, at 4:24 AM, Alan Braggins alan.bragg...@gmail.com wrote:
Surely that's precisely because they (and SSL/TLS generally) _don't_
have a One True Suite, they have a pick a suite, any suite approach?
And
On Fri, Oct 4, 2013 at 6:55 PM, Jeffrey Goldberg jeff...@goldmark.org wrote:
b) algorithm agility is useless if you don't have algorithms to choose
from, or if the ones you have are all in the same family”.
Yep.
And even though that was the excuse for including Dual_EC_DRBG among the
other
I should add that the ability to distinguish public DH keys from
random is a big deal in some cases. For example, for EKE: there's a
passive off-line dictionary attack that can reject a large fraction of
possible passwords with each EKE iteration -- if that fraction is 1/2
then after about 20
On Tue, Sep 24, 2013 at 12:03:12AM +0200, Adam Back wrote:
[In response to the idea of using encrypted file hashes as part of the
key wrapping procedure...]
Thats not bad (make the decryption dependant on accessibility of the entire
file) nice as a design idea. But that could be expensive in
active attacks,
then you can get BTNS with minimal effort. This is quite true.
At least some times we need to care about active attacks.
On Thu, 12 Sep 2013, Nico Williams wrote:
Note: you don't just want BTNS, you also want RFC5660 -- IPsec
channels. You also want to define a channel binding
We have a purely (now mostly) all-symmetric key protocol: Needham-Schroeder
-- Kerberos. Guess what: it doesn't scale, not without a strong dose of PK
(and other things). Worse, its trusted third parties can do more than
MITM/impersonate you like PKI's: they get to see your session keys (unless
On Fri, Sep 6, 2013 at 7:27 PM, Jeffrey Walton noloa...@gmail.com wrote:
I've been thinking about running a fast inner stream cipher (Salsa20
without a MAC) and wrapping it in AES with an authenticated encryption
mode (or CBC mode with {HMAC|CMAC}).
My own very subjective opinion is that
On Fri, Sep 6, 2013 at 8:05 PM, Jeffrey Walton noloa...@gmail.com wrote:
I'm more worried about key exchange or agreement.
The list of things to get right is long. The hardest is getting the
implementation right -- don't do all that work just to succumb to a
remotely exploitable buffer
On Sat, Aug 17, 2013 at 12:50 PM, Jon Callas j...@callas.org wrote:
On Aug 17, 2013, at 12:49 AM, Bryan Bishop kanz...@gmail.com wrote:
Would providing (signed) build vm images solve the problem of distributing
your toolchain?
A more interesting approach would be to use a variety of
On Fri, Aug 16, 2013 at 2:11 PM, zooko zo...@zooko.com wrote:
On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote:
Nothing really gets anyone past the enormous supply of zero-day vulns in
their complete stacks. In the end I assume there's no technological PRISM
workarounds.
I
On Fri, Aug 16, 2013 at 7:24 PM, D. J. Bernstein d...@cr.yp.to wrote:
I'm not saying that /dev/urandom has a perfect API. [...]
It might be useful to think of what a good API would be. I've thought
before that the Unix everything-as-a-file philosophy makes for lame
entropy APIs, and yet it's
On Tue, Aug 13, 2013 at 12:02 PM, ianG i...@iang.org wrote:
Super! I think a commercial operator is an essential step forward.
A few points:
- if only you access your own files then there's much less interest
for a government in your files: they might contain evidence of crimes
and
On Tue, Aug 13, 2013 at 2:09 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
Although presumably there would be value in shutting down a
privacy-protecting service just so that people can't benefit from it any
longer. When the assumption is that everything must be public, any
service that
On Thu, Aug 1, 2013 at 12:57 PM, wasa bee wasabe...@gmail.com wrote:
in CT, how do you tell if a newly-generated cert is legitimate or not?
Say, I am a state-sponsored attacker and can get a cert signed by my
national CA for barclays. How do you tell this cert is not legitimate? It
could have
Two words: rainbow tables.
Salting makes it impossible to pre-compute rainbow tables for common
inputs (e.g., passwords).
Now, this HKDF is not intended for use as a PBKDF, so the salt
effectively adds no real value when the input key material is truly
random/unpredictable by attackers, which it
On Fri, Jul 19, 2013 at 4:52 PM, Lodewijk andré de la porte
l...@odewijk.nl wrote:
2013/7/19 Mahrud S dinovi...@gmail.com
Isn't the thermal noise a good enough entropy source? I mean, it's a $25
computer, you can't expect much of it.
See, sir, you shouldn't wonder why all your data isn't
On Wed, Jul 17, 2013 at 7:42 AM, ianG i...@iang.org wrote:
On 17/07/13 10:50 AM, William Allen Simpson wrote:
Thing is, you don't just need an encryption algorithm, you also need IV,
MAC, Padding concepts. (I agree that using a stream cipher obviates any
messing Padding needs and the 'mode'
Subject [cryptography] authentication protocol proposa
For authentication of what/whom, with what credentials, to what
target(s)? Ah, users with passwords to some node with a password
verifier.
On Wed, Jul 17, 2013 at 4:54 PM, Krisztián Pintér pinte...@gmail.com wrote:
hello,
some benefits:
[BTW, when responding to a message forwarded, do please fix the quote
attribution.]
On Fri, Jul 12, 2013 at 2:29 PM, ianG i...@iang.org wrote:
This thread has been seen before. On-chip RNGs are auditable but not
verifiable by the general public. So the audit can be done then bypassed.
Which
On Tue, Jul 2, 2013 at 10:07 AM, Adam Back a...@cypherspace.org wrote:
On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote:
On 2 July 2013 11:25, Adam Back a...@cypherspace.org wrote:
does it provide forward secrecy (via k' = H(k)?).
Resumed [SSL] sessions do not give forward
On Mon, Jul 1, 2013 at 3:37 AM, ianG i...@iang.org wrote:
Hmmm. Thanks, Ethan! Maybe I'm wrong? Maybe the NSA was always allowed to
pass criminal evidence across to the civilian police forces. It's a very
strange world.
No, the doctrine of the fruit of the poisoned tree makes it
On Mon, Jul 1, 2013 at 9:05 AM, Eugen Leitl eu...@leitl.org wrote:
On Mon, Jul 01, 2013 at 01:31:51PM +0200, Guido Witmond wrote:
The only answer is to take key management out of the users' hands. And
do it automatically as part of the work flow.
You need at least a Big Fat Warning when the
On Mon, Jul 1, 2013 at 4:57 PM, grarpamp grarp...@gmail.com wrote:
And when LEA
get caught doing this nothing terribly bad happens to LEA (no officers
go to prison, for example).
It is often in the interest/whim of the executive to decline to
prosecute its own,
even if only to save
On Tue, Jun 25, 2013 at 6:01 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
How would one fabricate a digital key?
They probably meant something that sounds close. E.g., minted a
certificate, or a ticket, or token, or whatever the thing is, by
subverting an issuing authority or its processes
On Mon, May 20, 2013 at 1:50 PM, Mark Seiden m...@seiden.com wrote:
On May 20, 2013, at 1:18 PM, Nico Williams n...@cryptonector.com wrote:
Corporations are privacy freaks. I've worked or consulted for a
number of corporations that were/are extremely concerned about data
exfiltration
On Fri, May 17, 2013 at 6:06 AM, Ben Laurie b...@links.org wrote:
On 17 May 2013 11:39, d...@geer.org wrote:
Trust but verify is dead.
Maybe for s/w, but not everything:
http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
Which requires s/w. Infinite loop detected.
:)
More
On Mon, May 20, 2013 at 12:08 PM, Mark Seiden m...@seiden.com wrote:
any mechanism to do this (that i could think of, anyway) presents a possible
risk to
those communicants who want no attributable state saved about their
communication.
either these are privacy freaks (not intended
On Mon, May 20, 2013 at 12:22 PM, Jeffrey Walton noloa...@gmail.com wrote:
The original Skype homepage (circa 2003/2004) claims the service is
secure: Skype calls have excellent sound quality and are highly
secure with end-to-end encryption.
On Wed, May 1, 2013 at 9:50 AM, Florian Weimer f...@deneb.enyo.de wrote:
I've recently been asked to comment on a key exchange protocol which
uses symmetric cryptography and a mutually trusted third party. The
obvious recommendation is to copy the Kerberos protocol (perhaps with
updated
To complete the thought I meant to... don't just copy Kerberos. Copy
the fixes, and fold them in better.
Regarding crypto primitives, as Jeff Altman points out, the Kerberos
ones have been separated out from Kerberos. See RFC 3961 and 3962.
Note that for AES in particular Kerberos relies on
On Fri, Apr 5, 2013 at 9:17 PM, NgPS n...@rulemaker.net wrote:
In the movies and presumably in real life, bad guys have smart crooked
lawyers advising them. Surely the bad guys have the resources to set up
bunch of servers a la iMessage/Whatsapp, and write/deploy their own apps on
their mobile
On Thu, Apr 4, 2013 at 3:51 PM, ianG i...@iang.org wrote:
On 4/04/13 21:43 PM, Jon Callas wrote:
This is great. It just drives home that usability is all.
Just to underline Jon's message for y'all, they should have waited for
iMessage:
Encryption used in Apple's iMessage chat service
On Thu, Mar 28, 2013 at 7:24 PM, Kevin W. Wall kevin.w.w...@gmail.com wrote:
On Thu, Mar 28, 2013 at 7:27 PM, Jon Callas j...@callas.org wrote:
[Rational response elided.]
All excellent, well articulated points. I guess that means that
RSA Security is an insane company then since that's
On Saturday, March 23, 2013, ianG wrote:
Someone on another list asked an interesting question:
Why did OTR succeed in IM systems, where OpenPGP and x.509 did not?
Because it turns out that starting with anonymous key exchange is good
enough in many cases. Leap of faith would have been
On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
There have been attacks on SSH based on the fact that portions of the packets
aren't authenticated, and as soon as the TLS folks stop bikeshedding and adopt
encrypt-then-MAC I'm going to propose the same thing for
On Mon, Feb 11, 2013 at 4:57 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Nico Williams n...@cryptonector.com writes:
On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann pgut...@cs.auckland.ac.nz
wrote:
There have been attacks on SSH based on the fact that portions of the
packets
aren't
On Mon, Feb 11, 2013 at 6:04 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Nico Williams n...@cryptonector.com writes:
I'd go further: this could be the start of the end of the cipher suite
cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key
exchange separately
On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
On 02/12/2013 12:04 AM, Peter Gutmann wrote:
The problem with the cipher-suite explosion is that people want to throw in
vast numbers of pointless vanity suites and algorithms that no-one will ever
use
On
On Mon, Feb 11, 2013 at 7:00 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
On 02/12/2013 12:42 AM, Nico Williams wrote:
On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
But I suspect that that was not the rationale way, way back when, back
when
On Tue, Jan 29, 2013 at 9:40 PM, Thor Lancelot Simon t...@panix.com wrote:
...despite all the attacks we've seen on compresion-before-encryption, and
all the timing
atatacks we've seen on encryption, [...]
..we haven't really seen any known-plaintext key recovery attacks facilitated
by
On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton noloa...@gmail.com wrote:
Would you consider adding a hook to git (assuming it include the ability).
Have the hook replace tabs with white space. This is necessary because
different editors render tabs in different widths. So white space
makes
On Tue, Jan 8, 2013 at 11:08 PM, Jeffrey Walton noloa...@gmail.com wrote:
On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams n...@cryptonector.com wrote:
On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton noloa...@gmail.com wrote:
Would you consider adding a hook to git (assuming it include the ability
And, of course, *all* the gate checkers need to be available to the
developer, so *they* can run them first. No trial and error please.
(One quickly learns to code in the target upstream's style and other
requirements.)
___
cryptography mailing list
On Sun, Nov 4, 2012 at 8:42 AM, Ben Laurie b...@links.org wrote:
On Sat, Nov 3, 2012 at 12:26 AM, James A. Donald jam...@echeque.com wrote:
On Oct 30, 2012 7:50 AM, Ben Laurie b...@links.org wrote:
The team has ruled out having the master at github.
What is wrong with github?
TBH, I
I strongly suggest you move to git ASAP. It's not hard, though some
history can be lost in the move using off-the-shelf conversion tools.
(MIT Kerberos recently moved from SVN to git, and before that, from
CVS to SVN, and they seem to have done a lot of manual cleanup to
avoid some losses of
On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton noloa...@gmail.com wrote:
I have a Secure Remote Password (SRP) implementation that went through
a pen test. The testers provided a critical finding - the email
address was sent in the plaintext. Noe that plaintext email addresses
are part of the
On Thu, Oct 18, 2012 at 8:36 PM, Nico Williams n...@cryptonector.com wrote:
On Thu, Oct 18, 2012 at 7:52 PM, Jeffrey Walton noloa...@gmail.com wrote:
I'm not really convinced that using an email address in the plaintext
for the SRP protocol is finding-worthy, considering email addresses
On Thu, Oct 18, 2012 at 9:40 PM, Jeffrey Walton noloa...@gmail.com wrote:
I think Hash(email) or a UID (rather than email address) is the best
course of action.
UID doesn't work: the user must then remember it, and you don't want
to burden them with that :(
Nico
--
On Wed, Oct 3, 2012 at 9:19 AM, Dr Adam Back a...@cypherspace.org wrote:
Incidentally a somewhat related problem with dedup (probably more in cloud
storage than local dedup of storage) is that the dedup function itself can
lead to the confirmation or even decryption of documents with
On Wed, Oct 3, 2012 at 7:41 AM, David McGrew (mcgrew) mcg...@cisco.com wrote:
Are the requirements for the security of ZFS and the use of cryptography
in that filesystem documented anywhere?
https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data mentions a
Merkle tree of checksums, where
On Tue, Sep 18, 2012 at 10:30 AM, Natanael natanae...@gmail.com wrote:
Does anybody here take quantum crypto seriously? Just wondering. I do not
see any benefit over classical methods. If one trusts the entire link and
knows it's not MitM'd in advance, what advantage if any does quantum key
On Thu, Jul 5, 2012 at 9:17 AM, Martin Paljak mar...@martinpaljak.net wrote:
On Tue, Jul 3, 2012 at 1:56 AM, Michael Nelson nelson_mi...@yahoo.com wrote:
It also does not matter whether you are using pkcs11 APIs, and whether you
are doing key wrap/unwrap, and whether the data is a key. Any
On Thu, Jun 7, 2012 at 4:14 PM, Steven Bellovin s...@cs.columbia.edu wrote:
There's another, completely different issue: does the attacker want a
particular password, or will any passwords from a large set suffice?
Given the availability of cheap cloud computing, botnets, GPUs, and botnets
On Thu, May 31, 2012 at 2:03 AM, Jon Callas j...@callas.org wrote:
On May 30, 2012, at 4:28 AM, Maarten Billemont wrote:
If I understand your point correctly, you're telling me that while scrypt
might delay brute-force attacks on a user's master password, it's not
terribly useful a defense
On Thu, May 31, 2012 at 10:43 AM, Adam Back a...@cypherspace.org wrote:
One quite generic argument I could suggest for being wary of scrypt would be
if someone said, hey here's my new hash function, use it instead of SHA1,
its better - you would and should very wary. A lot of public review
On Thu, May 31, 2012 at 2:03 PM, Marsh Ray ma...@extendedsubset.com wrote:
On 05/31/2012 11:28 AM, Nico Williams wrote:
Yes, but note that one could address that with some assumptions, and
with some techniques that one would reject when making a better hash
-- the point is to be slow
On Wed, May 30, 2012 at 2:32 AM, Jon Callas j...@callas.org wrote:
(1) You take the master password and run it through a 512-bit hash function,
producing master binary secret.
You pick scrypt for your hash function, because you think burning time and
space adds to security. I do not. This
On Wed, May 30, 2012 at 3:25 PM, Maarten Billemont lhun...@lyndir.com wrote:
I'm currently considering asking the user for their full name and using that
as a salt in the scrypt operation. Full names are often lengthy and there's
a good deal of them. Do you recon this might introduce enough
On Wed, May 2, 2012 at 8:00 PM, D. J. Bernstein d...@cr.yp.to wrote:
I should emphasize that an authenticated-cipher competition would be
much more than an AE mode competition. There are certainly people
working on new ways to use AES, but there are many more people working
on new
The idea of using fresh certs (not necessarily short-lived) came up in
the TLS WG list in the context of the OCSP multi-stapling proposal.
So far the most important objection to fresh-lived certs was that it
exacerbates clock synchronization issues, but I'm willing to live with
that. Short-lived
On Fri, Apr 27, 2012 at 9:15 AM, ianG i...@iang.org wrote:
Easy. Take the hash, then publish it. The data can be secret, the hash
need not be.
That works for git. In particular what's nice about it is that you
get copies of the hash stored all over.
A similar approach can work for
On Thu, Apr 26, 2012 at 4:04 AM, Darren J Moffat
darren.mof...@oracle.com wrote:
On 04/26/12 04:52, Nico Williams wrote:
You'd have to ask Darren, but IIRC the design he settled on allows for
unkeyed integrity verification and repair.
Yes it is. That was a fundamental requirement of adding
I think Tahoe-LAFS is the exception to any rule that one should use
AE, and really, the very rare exception. Not the only exception,
though this type of application might be the only exception we want.
A ZFS-like COW filesystem with Merkle hash trees should have
requirements similar to Tahoe's,
You'd have to ask Darren, but IIRC the design he settled on allows for
unkeyed integrity verification and repair. I too think that's a
critical feature to have even if having it were to mean leaking some
information, such as file length in blocks, and number of files, as I
look at this from an
On Wed, Apr 25, 2012 at 10:27 PM, Marsh Ray ma...@extendedsubset.com wrote:
On 04/25/2012 10:11 PM, Zooko Wilcox-O'Hearn wrote:
2. the verifier-oriented way: you make a secure hash of the chunk, and
make the resulting hash value known to the good guy(s) in an
authenticated way.
Is option 2
Also,
On Wed, Apr 25, 2012 at 10:11 PM, Zooko Wilcox-O'Hearn zo...@zooko.com wrote:
Hello Nico Williams. Nice to hear from you.
Yes, when David-Sarah Hopwood and I (both Tahoe-LAFS hackers)
participated on the zfs-crypto mailing list with you and others, I
learned about a lot of similarities
On Wed, Apr 11, 2012 at 11:06 AM, Marsh Ray ma...@extendedsubset.com wrote:
http://mosh.mit.edu/
http://mosh.mit.edu/mosh-paper-draft.pdf
Very interesting. It's basically a VNC/RDP-like protocol but for
terminal applications.
Hat's off to anyone brave enough to consider a correct and
On Fri, Mar 30, 2012 at 7:10 AM, StealthMonger
stealthmon...@nym.mixmin.net wrote:
Adam Back a...@cypherspace.org writes:
Not sure that we lost the crypto wars. US companies export full strength
crypto these days, and neither the US nor most other western counties have
mandatory GAK. Seems
On Sun, Mar 25, 2012 at 10:55 PM, Marsh Ray ma...@extendedsubset.com wrote:
On 03/25/2012 11:45 AM, Benjamin Kreuter wrote:
The US government still wants a
No, probably parts of it: the ones that don't have to think of the big
picture. The U.S. government is not monolythic. The NSA has shown
IOW, I doubt mailman is how they got Fricosu's password.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
On Mon, Feb 20, 2012 at 7:07 AM, Ben Laurie b...@links.org wrote:
In FreeBSD random (and hence urandom) blocks at startup, but never again.
So, not exactly a terribly wrong thing to do, eh? ;)
What OSes have parallelized rc script/whatever nowadays? Quite a few,
it seems (several Linux
On Sun, Feb 19, 2012 at 10:08 AM, Florian Weimer f...@deneb.enyo.de wrote:
* Saqib Ali:
Can somebody explain me how this so-called Homomorphic split-key
encryption works?
Isn't this just a protocal which performs a cryptographic primitive
using split key material, without actually
My guess is that since fully homomorphic systems will be very slow
that one could use it to guard just a tiny secret. But what's the
point? Who cares if you can protect the customer's keys, if you can't
protect the customer's plaintext data?
Nico
--
Note that there may be times when the application definitely should
initialize a PRNG (seeded from the OS' entropy system -- I still
maintain that the whole system needs to work well). For example, when
using cipher modes where IVs/confounders need to be random but also
not re-used. In that case
On Fri, Feb 17, 2012 at 2:39 PM, Thierry Moreau
thierry.mor...@connotech.com wrote:
If your /dev/urandom never blocks the requesting task irrespective of the
random bytes usage, then maybe your /dev/random is not as secure as it might
be (unless you have an high speed entropy source, but what
On Fri, Feb 17, 2012 at 2:51 PM, Jon Callas j...@callas.org wrote:
On Feb 17, 2012, at 12:41 PM, Nico Williams wrote:
On Fri, Feb 17, 2012 at 2:39 PM, Thierry Moreau
thierry.mor...@connotech.com wrote:
If your /dev/urandom never blocks the requesting task irrespective of the
random bytes
On Thu, Feb 16, 2012 at 12:28 PM, Jeffrey Schiller j...@qyv.net wrote:
Are you thinking this is because it causes the entropy estimate in the RNG
to be higher than it really is? Last time I checked OpenSSL it didn't block
requests for numbers in cases of low entropy estimates anyway, so line
On Thu, Feb 16, 2012 at 8:45 PM, 2...@gishpuppy.com wrote:
Nico Williams wrote:
Applications (in the Unix sense) should not be the ones seeding the
system's PRNG. The system should ensure that there is enough entropy
and seed its own PRNG (and mix in new entropy).
Exactly the opposite
On Wed, Feb 15, 2012 at 5:57 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Alexander Klimov alser...@inbox.ru writes:
While the RSA may be easier to break if the entropy during the key
*generation* is low, the DSA is easier to break if the entropy during the key
*use* is low. Obviously, if
On Sun, Feb 12, 2012 at 9:13 PM, Krassimir Tzvetanov
mailli...@krassi.biz wrote:
I agree, I'm just reflecting on the reality... :(
Reality is actually as I described, at least for some shops that I'm
familiar with.
___
cryptography mailing list
I'm sure the trend is currently the other way, yes, but with low-cost
high-bandwidth wireless becoming more common it doesn't really matter,
does it?
And it all depends on the organization and it's risk taking profile.
But to bring this back on topic: I'd rather see draconian corporate
network
On Wed, Feb 1, 2012 at 3:49 AM, Francois Grieu fgr...@gmail.com wrote:
The talk does not give much details, and I failed to locate any article
with a similar claim.
I would find that result truly remarkable, and it is against my intuition.
The video you posted does help me with the intuition
On Sat, Jan 28, 2012 at 5:45 PM, Noon Silk noonsli...@gmail.com wrote:
On Sun, Jan 29, 2012 at 4:22 AM, Nico Williams n...@cryptonector.com wrote:
I don't see how I could have been much more specific given the two
things you quoted from me.
As I said, you could point to specific products
On Fri, Jan 27, 2012 at 3:49 PM, Sven Moritz Hallberg pe...@khjk.org wrote:
On Fri, 27 Jan 2012 13:39:44 -0500, Warren Kumari war...@kumari.net wrote:
Surely I am missing something here? Or is that really the news?
I thought the same thing and skimmed (very incompletely) through the
paper.
On Mon, Jan 2, 2012 at 4:25 PM, Randall Webmail rv...@insightbb.com wrote:
My neighborhood Wal*Mart has pretty much eliminated cashiers in favor of
self-checkouts.
[...]
Wal*Mart is not stupid. They know full well that a certain percent of
shoppers will indeed walk out with a certain
On Mon, Jan 2, 2012 at 9:08 PM, John Levine jo...@iecc.com wrote:
[...]. One of the advantages of having a working legal system is so
that we can live reasonable lives with $20 locks in our doors, rather
than all having to spend thousands to armor all the doors and windows,
like they do in
I'm assuming that at password change new password policy evaluation
time you have both, the old and new passwords, in which case you can
use Optimal String Alignment Distance for at least that pair of
passwords. If you have only one password you can try a cookbook of
transformations that users
1 - 100 of 143 matches
Mail list logo
