On Tue, Oct 01, 2013 at 12:47:56PM -0400, John Kelsey wrote:
The actual technical question is whether an across the board 128 bit
security level is sufficient for a hash function with a 256 bit output.
This weakens the proposed SHA3-256 relative to SHA256 in preimage
resistance, where SHA256
Some may remember Bleichenbacher found a random number generator bias in the
original DSA spec, that could leak the key after soem number of signatures
depending the circumstances.
Its described in this summary of DSA issues by Vaudenay Evaluation Report
on DSA
On Mon, Sep 30, 2013 at 06:35:24PM -0400, John Kelsey wrote:
Having read the mail you linked to, it doesn't say the curves weren't
generated according to the claimed procedure. Instead, it repeats Dan
Bernstein's comment that the seed looks random, and that this would have
allowed NSA to
On Tue, Oct 01, 2013 at 08:47:49AM -0700, Tony Arcieri wrote:
On Tue, Oct 1, 2013 at 3:08 AM, Adam Back [1]a...@cypherspace.org
wrote:
But I do think it is a very interesting and pressing research question
as to whether there are ways to plausibly deniably symmetrically
weaken
On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote:
On 30/09/13 11:02 AM, Adam Back wrote:
no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward
secret ciphersuites, no baked in key length limits [...] support
soft-hosting [...] Add TOFO for self-signed keys.
Personally
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
like the base SSL protocol; encrypt and then MAC only, no non-forward secret
ciphersuites, no baked in key length limits. I think I'd also vote for a
lot less modes and ciphers. And probably non-NIST curves while we're at
I am not sure if everyone is aware that there is also an unmoderated crypto
list, because I see old familiar names posting on the moderated crypto list
that I do not see posting on the unmoderated list. The unmoderated list has
been running continuously (new posts in every day with no gaps)
On Wed, Sep 25, 2013 at 11:59:50PM +1200, Peter Gutmann wrote:
Something that can sign a new RSA-2048 sub-certificate is called a CA. For
a browser, it'll have to be a trusted CA. What I was asking you to explain is
how the browsers are going to deal with over half a billion (source: Netcraft
On Sat, Sep 14, 2013 at 12:56:02PM -0400, Perry E. Metzger wrote:
http://tools.ietf.org/html/rfc3766
| requirement | Symmetric | RSA or DH| DSA subgroup |
| for attack | key size | modulus size | size |
+-+---+--+--+
|100
Seems people like bottom post around here.
On Tue, Mar 23, 2010 at 8:51 PM, Nicolas Williams
nicolas.willi...@sun.com wrote:
On Tue, Mar 23, 2010 at 10:42:38AM -0500, Nicolas Williams wrote:
On Tue, Mar 23, 2010 at 11:21:01AM -0400, Perry E. Metzger wrote:
Ekr has an interesting blog post up
In anon-ip (a zero-knowledge systems internal project) and cebolla [1]
we provided forward-secrecy (aka backward security) using symmetric
re-keying (key replaced by hash of previous key). (Backward and
forward security as defined by Ross Anderson in [2]).
But we did not try to do forward
I would have thought PBKDF2 would be the obvious, standardized (PKCS
#5 / RFC 2898) and designed for purpose method to derive a key from a
password. PBKDF2 would typically be based on HMAC-SHA1.
Should be straight-forward to use PBKDF2 with HMAC-SHA-256 instead for
larger key sizes, or for
credlib provides Brands' and Chaum credentials, both of which can be
used for ecash.
http://www.cypherspace.org/credlib/
Adam
On Mon, Sep 17, 2007 at 01:46:04PM -0400, Steven M. Bellovin wrote:
Are there any open source digital cash packages available? I need one
as part of another
I think you misread what I said about BIOS jumper required install.
Ie this is not a one click install from email. It is something one
user in 10,000 would even install at all! It would be more like
people who program and install custom BIOSes or something, people who
reverse-engineer security
I do not believe the mentioned conflict exists. The aim of these
calculator-like devices is to make sure that no malware, virus etc can
create unauthorized transactions. The user should still be able to
debug, and inspect the software in the calculator-like device, or
virtual software
I read some of the docs and ecache appears to be based on HMAC
tickets, plus mixes. The problem I see is that you have to trust the
mix. Now the documentation does mention that they anticipate 3rd
party mixes, but still you have to trust those mixes also.
And as we know from mixmaster etc.,
faced in
deploying this stuff. Cant deploy what people dont understand!
Adam
--
http://www.cypherspace.org/credlib/
On Fri, Feb 16, 2007 at 11:14:39AM -0500, Adam Back wrote:
Hi
I implemented Chaumian and Brands credentials in a credential library
(C code, using openSSL). I implemented some
Hi
I implemented Chaumian and Brands credentials in a credential library
(C code, using openSSL). I implemented some of the pre-computation
steps. Have not made any attempt so far to benchmark it. But thought
I could take this opportunity to make it public. I did not try to
optimize so far.
Related to this announcement, credentica.com (Stefan Brands' company)
has released U-Prove, their toolkit SDK for doing limited-show,
selective disclosure and other aspects of the Brands credentials.
http://www.credentica.com/uprove_sdk.html
(Also on Stefans blog
Anoymous wrote:
[criticizing FIPS CRNGs]
You can make a secure CRNG that you can obtain FIPS 140 certification
on using the FIPS 186-2 appendix 3.1 (one of my clients got FIPS 140
on an implementation of the FIPS 186-2 RNG that I implemented for
general key generation and such crypto use.)
You
has serious potential problems when most machine owners do not
understand security).
Does anyone know the current state of affairs on this issue within the
Trusted Computing Group (and the marketed products of its members)?
Adam Back wrote:
So the part about being able to detect viruses
So the part about being able to detect viruses, trojans and attest
them between client-server apps that the client and server have a
mutual interest to secure is fine and good.
The bad part is that the user is not given control to modify the hash
and attest as if it were the original so that he
What they're saying is if you change the password, create some new
data in the encrypted folder, then someone who knew the old password,
can decrypt your new data.
Why? Well because when you change the password they dont change the
symmetric key used to encrypt the data. The password is used to
On Mon, Aug 14, 2006 at 12:23:03PM +1000, mikeiscool wrote:
But you're imaging an attack with a distributed bot net DDoS'ing you,
correct? Couldn't they then also use their botnet to process the
messages faster then normally? They already have the computering
power. Just a minor addon to the
I think an encrypted file system with builtin integrity is somewhat
interesting however the threat model is a bit broken if you are going
to boot off a potentially tampered with disk.
I mean the attacker doesnt have to tamper with the proposed
encrypted+MACed data, he just tampers with the boot
On Sat, Apr 08, 2006 at 07:53:37PM +0100, Ben Laurie wrote:
Adam Back wrote:
[about Brands credentials]
I think they shows are linkable, but if you show more than allowed
times, all of the attributes are leaked, including the credential
secret key and potentially some identifying
On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote:
This illustrates a problem with multi-show credentials, that the holder
could share his credential freely, and in some cases even publish it,
and this would allow non-authorized parties to use it. To avoid this,
more complicated
On Sat, Apr 01, 2006 at 12:35:12PM +0100, Ben Laurie wrote:
However, anyone I show this proof to can then masquerade as a silver
member, using my signed nonce. So, it occurred to me that an easy
way to prevent this is to create a private/public key pair and
instead of the nonce use the hash of
How many suitable quasars are there? You'd be damn lucky if its a
cryptograhic strength number.
Now you might think there are limits to how many signals you can
listen to and that would be some protection, however you still have
brute force guess a signal, and probability of guessing the right
Don't forget Bleichenbacher's error channel attack on SSL
implementations, which focussed on the mac then encrypt design of
SSL... web servers gave different error for malformed padding vs
plaintext MAC failure. The lesson I drew from that is the
conservative choice is encrypt then MAC.
I dont
There are a number of differences in key management priorities between
(communication) signature and encryption keys.
For encryption keys:
- you want short lived keys
- you should wipe the keys after at first opportunity
- for archiving you should re-encrypt with storage keys
- you can't detect
On Tue, Jan 03, 2006 at 10:10:50PM +, Ben Laurie wrote:
Jack Lloyd wrote:
Some relevant and recent data: in some tests I ran this weekend
[gmp faster than openssl]
AFAIK blinding alone can protect against all (publicly known)
timing attacks; am I wrong about this?
Yes, you are -
I would think it would be safer to block the site, or provide a
warning dialog. (This is what I was expecting when I started reading
the head post; I was bit surprised at the interventionism to actually
go ahead and fix the site, maybe that would be a better default
behavior).
btw Regarding
OK summing up: I think e2e secure, and secure by default.
On Fri, Aug 26, 2005 at 04:17:32PM -0400, Steven M. Bellovin wrote:
On the contrary -- I did say that I support and use e2e security. I
simply said that user-to-server security solves a lot of many -- most?
-- people's security
On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Adam Back writes:
Thats broken, just like the WAP GAP ... for security you want
end2end security, not a secure channel to an UTP (untrusted third
party)!
What is security? What are you
Not to defend PKI, but what about delta-CRLs?
Maybe not available at time of the Navy deployment? But certainly
meaning that people can download just changes since last update.
Steven writes:
[alternatives] such as simply publishing the hash of revoked
certificates,
Well presumably you mean
Single picket fence -- doesn't work without a lot of explaining.
The one I usually have usually heard is the obvious and intuitive
locking the door when the window is open.
(ie fixating on quality of dead-bolt, etc on the front door when the
window beside it is _open_!)
Adam
On Sat, Aug 06,
I think in the UK check signatures are not verified below £30,000
(about US $53,000). I presume it is just economics ... cost of
infrastructure to verify vs value of verifying given the fraud rate.
Adam
On Fri, Jul 15, 2005 at 01:42:08PM +0100, Ben Laurie wrote:
My bank doesn't even bother to
I suppose I should also have note that the master key going into KDF2
would be derived with PBKDF2 from a password if this is a password
derived set of keys, to get the extra features of a salt and iterator
to slow down brute force.
Adam
On Tue, Jun 14, 2005 at 04:21:39AM -0400, Adam Back wrote
Yes but the other context from the related group of blog postings, is
Kim Cameron's (microsoft) laws of identity [1] that this comment is
made in the context of.
It is relatively hard to see how one could implement an identity
system meeting the stated laws without involving blind signatures of
On Fri, Mar 25, 2005 at 04:02:36PM -0600, Matt Crawford wrote:
There's an X.509v3 NameConstraints extension (which the higher CA would
include in the lower CA's cert) but I have the impression that ends
system software does not widely support it. And of course if you don't
flag it
So PGP are now running a pgp key server which attempts to consilidate
the inforamtion from the existing key servers, but screen it by
ability to receive email at the address.
So they send you an email with a link in it and you go there and it
displays your key userid, keyid, fingerprint and email
, 2004 at 11:21:13PM +, Ben Laurie wrote:
Adam Back wrote:
I thought the usual attack posited when one can find a collision on a
source checksum is to make the desired change to source, then tinker
with something less obvious and more malleable like lsbits of a UI
image file until you find
and change surrepticiously with C'.
Adam
On Wed, Dec 15, 2004 at 08:44:03AM +, Ben Laurie wrote:
Adam Back wrote:
Well the people doing the checking (a subset of the power users) may
say I checked the source and it has this checksum, and another user
may download that checksum
I thought the usual attack posited when one can find a collision on a
source checksum is to make the desired change to source, then tinker
with something less obvious and more malleable like lsbits of a UI
image file until you find your collision on two input source packages.
Adam
On Tue, Dec
Stefan Brands book on his credential / ecash technology is now
downloadable in pdf format from credentica's web site:
http://www.credentica.com/the_mit_pressbook.php
(previously it was only available in hardcopy, and only parts of the
content was described in academic papers).
Also the
Joe Touch [EMAIL PROTECTED] wrote:
The point has nothing to do with anonymity;
The last one, agreed. But the primary assumption is that we can avoid a
lot of infrastructure and impediment to deployment by treating an
ongoing conversation as a reason to trust an endpoint, rather than a
On Sat, Sep 11, 2004 at 11:38:00AM -0700, Joe Touch wrote:
Although anonymous access is not the primary goal, it is a feature
of the solution.
The access is _not_ anonymous. The originator's IP, ISP call traces,
phone access records will be all over it and associated audit logs.
And you
You would have to either:
- search for candidate collisions amongst public keys you know the
private key for (bit more expensive)
- factorize the public key after you found a collision
the 2nd one isn't as hard as it sounds because the public key would be
essentially random and have
It's like an online ecash system. Each recipient sends the RPOW back
to the mint that issued it to ask if it has been double spent before
accepting it as valid. If it's valid (not double spent) the RPOW
server sends back a new RPOW for the receiving server to reuse.
Very like Chaum's online
On Wed, Jul 28, 2004 at 10:00:01PM -0700, Aram Perez wrote:
As far as I know, there is nothing in any standard or good security
practice that says you can't multiple certificate for the same email
address. If I'm willing to pay each time, Verisign will gladly issue me a
certificate with my
The difference is if the CA does not generate private keys, there
should be only one certificate per email address, so if two are
discovered in the wild the user has a transferable proof that the CA
is up-to-no-good. Ie the difference is it is detectable and provable.
If the CA in normal
On Wed, Apr 28, 2004 at 07:54:50PM +, Jason Holt wrote:
Last I heard, Brands started a company called Credentica, which
seems to only have a placeholder page (although it does have an
info@ address).
I also heard that his credential system was never implemented,
It was implemented at
approach of Wagner's protocol. But I obviously am not a patent
lawyer, and have avoided reading and participating in the writing of
patents.
Adam
On Sun, May 09, 2004 at 05:08:09AM -0400, Adam Back wrote:
[...]
I looked at Camenisch protocol briefly a couple of years ago and it is
not based Brands
[copied to cpunks as cryptography seems to have a multi-week lag these
days].
OK, now having read:
http://isrl.cs.byu.edu/HiddenCredentials.html
http://isrl.cs.byu.edu/pubs/wpes03.pdf
and seeing that it is a completely different proposal essentially
being an application of IBE, and extension
On Mon, May 10, 2004 at 02:42:04AM +, Jason Holt wrote:
However can't one achieve the same thing with encryption: eg an SSL
connection and conventional authentication?
How would you use SSL to prove fulfillment without revealing how?
You could get the CA to issue you a patient or
On Mon, May 10, 2004 at 03:03:56AM +, Jason Holt wrote:
[...] Actually, now that you mention Chaum, I'll have to look into
blind signatures with the BF IBE (issuing is just a scalar*point
multiply on a curve).
I think you mean so that the CA/IBE server even though he learns
pseudonyms
But if I understand that is only half of the picture. The recipient's
IBE CA will still be able to decrypt, tho the sender's IBE CA may not
as he does not have ability to compute pseudonym private keys for the
other IBE CA.
If you make it PFS, then that changes to the recipient's IBE CA can
get
Here's a forward of parts of an email I sent to Richard with comments on
his and Ben's paper (sent me a pre-print off-list a couple of weeks ago):
One obvious comment is that the calculations do not take account of
the CAMRAM approach of charging for introductions only. You mention
this in the
FYI Richard amended the figures in the paper which makes things 10x
more favorable for hashcash in terms of being an ecomonic defense
against spammers.
Richard wrote on asrg:
| we're grateful (albeit a little embarrassed) for the consideration
| given to one of our figures by Ted Wobber (MS
://news.bbc.co.uk/2/hi/technology/3324883.stm
Adam Back is part of this team, I think.
Similar approach to Camram/hahscash. Memory-based approaches have been
discussed. Why hasn't Camram explored them?
steve
applications.
Adam
On Fri, Dec 26, 2003 at 09:37:18PM -0500, Adam Back wrote:
I did work at Microsoft for about a year after leaving ZKS, but I quit
a month or so ago (working for another startup again).
But for accuracy while I was at Microsoft I was not part of the
microsoft research/academic team
Yes this is a good idea, and some people thought of it before also.
Look for paper secure applications of low entropy keys or something
like that by Schnieir, Wagner et al. (on counterpane labs page I
think).
Also the PBKDF2 function defined in PKCS#5 used to convert the
password into a key
What conceivable trade-offs could you have to make to get acceptable
performance out of symmetric crypto encrypted+authenticated tunnel?
All ciphers you should be using are like 50MB/sec on a 1Ghz machine!!
If you look at eg cebolla (more anonymity than VPN, but it's a nested
forward-secret VPN
On Wed, Sep 24, 2003 at 05:40:38PM -0700, Ed Gerck wrote:
Yes, there is a good reason for CAs to charge so much for certs.
I hope this posting is able to set this clear once and for all.
[zero risk, zero cost, zero liability, zero regulatory burden]
9. Product Price: At Will.
There is no
explores this in the context of ZKS Freedom Network, and Pipenet
presenting attacks on the Freedom Network, Onion Network, Crowds and
Pipenet which affect privacy and availability.
Adam
Traffic Analysis Attacks and Trade-Offs in Anonymity Providing
Systems, IH 2001, Adam Back, Ulf Moeller, and Anton
I think he means higher level frameworks, web programming libraries,
toolkits, and web page builder stuff; not hooks into SSL sessions.
Not to say that a hook into an SSL session is not a good place to get
an application sessions identifier from -- it would be, presuming that
you can't trick a
67 matches
Mail list logo
