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 is
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"
http://www.ipa.go.jp/security/en
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
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 generat
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) since
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
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
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 Fri, Sep 13, 2013 at 04:55:05PM -0400, John Kelsey wrote:
The more I think about it, the more important it seems that any anonymous
email like communications system *not* include people who don't want to be
part of it, and have lots of defenses to prevent its anonymous
communications from beco
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
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 on the question of
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 securit
On Fri, Nov 02, 2007 at 06:23:30PM +0100, Ian G wrote:
> I was involved in one case where super-secret stuff was shared
> through hushmail, and was also dual encrypted with non-hushmail-PGP
> for added security. In the end, the lawyers came in and scarfed up
> the lot with subpoenas ... all the se
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 avoida
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 compartment
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., ther
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
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. O
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 http://www.idcorner.o
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
real
> information security ultimately depends (I might add that even this
> model 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
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 ca
On Sat, Sep 09, 2006 at 09:39:04PM +0100, Ben Laurie wrote:
> > There is some more detail here:
> >
> > http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st
>
> Interesting. In fact, Gligor et al appear to have proposed IGE rather
> later than this
Hi Ben, Travis
IGE if this description summarized by Travis is correct, appears to be
a re-invention of Anton Stiglic and my proposed FREE-MAC mode.
However the FREE-MAC mode (below described as IGE) was broken back in
Mar 2000 or maybe earlier by Gligor, Donescu and Iorga. I recommend
you do not
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 th
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 se
On Wed, Apr 19, 2006 at 11:53:18AM -0700, bear wrote:
> On Sat, 8 Apr 2006, Ben Laurie wrote:
> >Adam Back wrote:
> >> My suggestion was to use a large denomination ecash coin to have
> >> anonymous disincentives :) ie you get fined, but you are not
> >> iden
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 p
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 compl
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
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 ke
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 th
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 o
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, yo
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 un
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 nee
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
>
Thats broken, just like the "WAP GAP" ... for security you want
end2end security, not a secure channel to an UTP (untrusted third
party)!
Adam
On Thu, Aug 25, 2005 at 02:09:48PM -0700, Eric Rescorla wrote:
> Most chat protocols (and Jabber in particular) are server-oriented
> protocols. So, the S
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
The non-banking version of this is the KDF2 function in IEEE1363a.
Same deal:
void KDF2( const void* Z, int, const void* P, int, void* K, int );
Z = master-key, P = permuter, K = derived key
each is variable sized. (Sorry I implemented the source for someone
who has the copyright or you coul
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 criti
The URL John forwarded gives survey of prices for regular certs and
subdomain wildcard certs/super certs (ie *.mydomain.com all considered
valid with respect to a single cert).
Does anyone have info on the cost of sub-ordinate CA cert with a name
space constraint (limited to issue certs on domains
>From what I recall from reading the CR paper a while back they can
tolerate up to some threshold of colluding players. However if you go
over that threshold (and it's not too large) you can remove the mark.
I would think the simplest canonical counter-attack would be to make a
p2p app that compa
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
e C,
and then we can MITM and change surrepticiously with C'.
Adam
On Wed, Dec 15, 2004 at 08:44:03AM +0000, 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&qu
ue, Dec 14, 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 lsb
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 14,
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 c
shcash, so using hashcash in this scenario slows the number of mails
| the spammer can send by 350x.
Adam
On Mon, Sep 13, 2004 at 10:37:47AM -0400, Adam Shostack wrote:
> On Mon, Sep 13, 2004 at 01:18:32PM +0100, Ben Laurie wrote:
> | Adam Shostack wrote:
> |
> | >On Tue, Sep 07, 2004
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.
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
Hi
I proposed a related algorithm based on time-lock puzzles as a step
towards non-parallelizable, fixed-minting-cost stamps in section 6.1
of [1], also Dingledine et al observe the same in [2].
The non-parallelizable minting function is in fact the reverse: sender
encrypts (expensively) and the
On Tue, Sep 07, 2004 at 08:14:51AM -0700, bear wrote:
> I've turned down two job offers, though -- from software companies
> with "bulk mail products", looking for natural-language guys to
> build "paraphrase engines" to bypass spam filters [...] They're
> actually willing to hire engineers at spec
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 non-negligib
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 ecas
(This discussion from hashcash list is Cc'd to cryptography and
cypherpunks.)
Hashcash uses SHA1 and computes a partial pre-image of the all 0bit
string (0^160).
Following is a discussion of what the recent results from Joux, Wang
et al, and Biham et al on SHA0, MD5, SHA1 etc might imply for hash
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 m
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 operatio
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 Resear
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 f
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 a
On Mon, May 10, 2004 at 08:02:12PM +, Jason Holt wrote:
> Adam Back wrote:
> > [...] However the server could mark the encrypted values by encoding
> > different challenge response values in each of them, right?
>
> Yep, that'd be a problem in that case. In th
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 B&F 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
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
[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
MAC not a blind signature
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 coupl
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
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 re
c 26, 2003 at 09:13:23AM -0800, Steve Schear wrote:
> http://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 hav
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
On Wed, Oct 01, 2003 at 08:53:39AM -0700, Eric Rescorla wrote:
> > there's another rationale my clients often give for
> > wanting a new security system [existing protcools] too heavyweight for
> > some applications.
>
> I hear this a lot, but I think that Perry nailed it earlier. SSL, for
> insta
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 re
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
Saw this on theregister.co.uk: geotrust is undercutting veri$ign at
$159/cert vs $350/cert by verisign and $199 by Thawte (which as you
note is just a verisign brand at this point).
http://www.theregister.co.uk/content/67/33009.html
You'd have thought there would be plenty of scope for ce
You might also look at RC5-16. RC5 is defined on 64, 32, 16 and 8 bit
words with respectively 128, 64, 32 and 16 bit block sizes.
Using counter-mode as suggested by someone earlier in the thread would
be the obvious way to get a sequence with a period of 2^n.
The Yarrow RNG uses counter-mode as
On Thu, Aug 28, 2003 at 08:06:07AM -0400, John S. Denker wrote:
> A couple of people wrote in to say that my remarks
> about defending against traffic analysis are "not
> true". As 'proof' they cite [1]
>
> which proves nothing of the sort.
I agree it doesn't prove anything directly. However if
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,
I'm not that familiar with SFS, but httpsy sounds quite related to
Anderson, Matyas and Peticolas' "eternal resource locator" [1], and
the WAX system they describe in that paper. This scheme allows a
referer to embody in a URL they refer to authentciation information
about the contents of the text
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 brow
Ben dude wrote:
> The obvious answer is you always switch to a new session after login.
> Nothing cleverer is required, surely?
Well particularly the issue is your login URL should not accept an
existing session identifier supplied by the browser (what the author
of the session fixing paper calls
87 matches
Mail list logo