Re: anonymous DH MITM

2003-10-03 Thread Taral
On Fri, Oct 03, 2003 at 02:16:22PM -0400, Jerrold Leichter wrote:
 The Interlock Protocol doesn't provide this - it prevents the MITM from
 modifying the exchanged messages, but can't prevent him from reading them.
 It's not clear if it can be achieved at all.  But it does make sense as a
 security spec.

Hardly. Just perform DH exchange over the interlock protocol. By your
own admission, the MITM could not change the factors being exchanged,
and by DH, the MITM cannot then know what the resulting key data is.

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind. -- Dr. Seuss


signature.asc
Description: Digital signature


Re: anonymous DH MITM

2003-10-06 Thread Taral
On Mon, Oct 06, 2003 at 11:43:21AM -0400, Anton Stiglic wrote:
 You started by talking about anonymous communication, but ended up
 suggesting a scheme for pseudonymous communication.
 
 Anonymous != pseudonymous.
 
 Let us be clear on that!
 It is an important difference.

Yes it is. An anonymous system can be constructed from a pseudonymous
system by never reusing a pseudonym.

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind. -- Dr. Seuss


signature.asc
Description: Digital signature


Re: Your source code, for sale

2004-11-06 Thread Taral
On Thu, Nov 04, 2004 at 03:01:15PM -0800, Hal Finney wrote:
 Another idea along these lines is gradual payment for gradual release
 of the goods.  You pay 10% of the amount and they give you 10% of the
 source code.  You pay another 10% and you get the next 10% of the source,
 and so on.  (Or it could be nonlinear; maybe they give out half the code
 for free, but the final 10% requires a large payment.)  The idea is that
 you can sample and make sure they do appear to have the real thing with
 a fairly small investment.
 
 If there is some mechanism for the seller to have a reputation (like
 Advogato's perhaps, with some spoofing immunity) then the problem is
 easier; the seller won't want to screw buyers because it hurts his rep.
 In that case it may be reasonable to ask the buyer to pay in advance,
 perhaps using the partial payment system just discussed.

The mojonation file sharing system had an implementation like this
originally...

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpdoIJZJgFGT.pgp
Description: PGP signature


Re: Cryptography Research wants piracy speed bump on HD DVDs

2004-12-22 Thread Taral
On Wed, Dec 22, 2004 at 10:58:11AM -0600, Matt Crawford wrote:
 
 On Dec 15, 2004, at 11:54, Taral wrote:
 
 What stops someone using 3 players and majority voting on frame data
 bits?
 
 As I understand it, they use such a huge number of bits for marking, 
 that any reasonably-sized assembly of players will still coincide on 
 some marked bits.
 (However, I very much doubt whether they can blacklist all the players 
 in the assembly without blacklisting some innocent players as well!)

Is there really that much space for marking? Any substantial number of
marked bits will become obvious in the output stream, no?

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpCUKLbedBvo.pgp
Description: PGP signature


Re: entropy depletion (was: SSL/TLS passive sniffing)

2005-01-07 Thread Taral
On Thu, Jan 06, 2005 at 04:35:05PM +0800, Enzo Michelangeli wrote:
 By how much exactly? I'd say, _under the hypothesis that the one-way
 function can't be broken and other attacks fail_, exactly zero; in the
 real world, maybe a little more.

Unfortunately for your analysis, *entropy* assumes that there is
infinite compute capacity. From an information-theoretic point of view,
there is NO SUCH THING as a perfect one-way function.

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpRflyK9JPXi.pgp
Description: PGP signature


Re: entropy depletion (was: SSL/TLS passive sniffing)

2005-01-09 Thread Taral
On Sat, Jan 08, 2005 at 10:46:17AM +0800, Enzo Michelangeli wrote:
 But that was precisely my initial position: that the insight on the
 internal state (which I saw, by definition, as the loss of entropy by the
 generator) that we gain from one bit of output is much smaller than one
 full bit. 

I think this last bit is untrue. You will find that the expected number
of states of the PRNG after extracting one bit of randomness is half of
the number of states you had before, thus resulting in one bit of
entropy loss.

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpEGgoI4O221.pgp
Description: PGP signature


Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

2005-02-10 Thread Taral
On Wed, Feb 09, 2005 at 09:08:45PM +, Ian G wrote:
 The plugin is downloadable from a MozDev site,
 and presumably if enough attention warrants it,
 Amir can go to the extent of signing it with a
 cert in Mozilla's code signing regime.

That only authenticates that Amir wrote the code, not that the code is
safe.

 Also, as Amir is a relatively well known name in
 the world of crypto I suppose you could consider
 his incentives to be more aligned with delivering
 good code than code that would do you damage.

*This* is a reasonable argument, but I'd prefer a second-party review
before I install anything.

Then again, the only extension I have installed (FlashGot), I manually
checked myself.

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpeCkZRPZZzq.pgp
Description: PGP signature


Re: Encryption plugins for gaim

2005-03-15 Thread Taral
On Mon, Mar 14, 2005 at 01:19:04AM -0500, Adam Fields wrote:
 Given what may or may not be recent ToS changes to the AIM service,
 I've recently been looking into encryption plugins for gaim. 
 
 Specifically, I note gaim-otr, authored by Ian G, who's on this list.
 
 Ian - would you care to share some insights on this? Is it ready for
 prime time or just a proof-of-concept? Any known issues?

If you want encryption with authentication, there's the gaim-encryption
plugin. I get the feeling gaim-otr is for more specific circumstances.

-- 
Taral [EMAIL PROTECTED]
This message is digitally signed. Please PGP encrypt mail to me.
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


pgpfHgRbHTkPG.pgp
Description: PGP signature


Re: RSA signatures without padding

2005-06-20 Thread Taral
On 6/20/05, James Muir [EMAIL PROTECTED] wrote:
 The attack I am trying to recall is a chosen-message attack and its
 efficiency is related to the probability that a random 128-bit integer can
 be factorized over a small set of primes (ie. the prob that a uniformily
 selected 128-bit integer is B-smooth for a small integer B).  Basically,
 you pick a message for which you'd like to forge a signature, find a variant
 of the message that hashes to a B-smooth 128-bit integer, and then you
 construct the forgery after solving a linear system modulo e (the linear
 system incorporates the signatures on the chosen messages).

I think you're referring to the Desmedt-Odlyzko selective forgery attack.

See http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1014_Menezes.sigs.pdf

-- 
Taral [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Study shows how photonic decoys can foil hackers

2006-03-08 Thread Taral
On 3/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Does anyone have an idea of what this is about?  (From Computerworld):

 -- Jerry

I believe this is the same technology that Bruce Schneier commented on
in his security blog:

http://www.schneier.com/blog/archives/2006/02/quantum_computi.html

--
Taral [EMAIL PROTECTED]
Computer science is no more about computers than astronomy is about
telescopes.
-- Edsger Dijkstra

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: passphrases with more than 160 bits of entropy

2006-03-22 Thread Taral
On 3/21/06, Travis H. [EMAIL PROTECTED] wrote:
 Does anyone have a good idea on how to OWF passphrases without
 reducing them to lower entropy counts?

I've frequently seen constructs of this type:

H(P), H(0 || P), H(0 || 0 || P), ...

If entropy(P)  entropy(H), the entries will be independent, theoretically.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: is breaking RSA at least as hard as factoring or vice-versa?

2006-04-02 Thread Taral
On 4/2/06, Travis H. [EMAIL PROTECTED] wrote:
 So I'm reading up on unconditionally secure authentication in Simmon's
 Contemporary Cryptology, and he points out that with RSA, given d,
 you could calculate e (remember, this is authentication not
 encryption) if you could factor n, which relates the two.

This implication runs both ways. Given d and e (and pq), one can
compute p and q. Proving this is an exercise left to the reader.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Status of attacks on AES?

2006-05-11 Thread Taral

On 5/10/06, John R. Black [EMAIL PROTECTED] wrote:

I skimmed this.  The start of the article says that after 3 rounds AES
achieves perfect diffusion?!


No, it says their old ASD could not distinguish encrypted data from
random after 3 rounds.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Quantum RNG (was: Use of TPM chip for RNG)

2006-07-04 Thread Taral

On 7/4/06, Andrea Pasquinucci [EMAIL PROTECTED] wrote:

About RNG, does someone in the list have any comment, ideas on this

http://www.idquantique.com/products/quantis.htm


Why? Noise-based RNGs are just as random and just as quantum. :)

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A note on vendor reaction speed to the e=3 problem

2006-09-16 Thread Taral

On 9/15/06, David Shaw [EMAIL PROTECTED] wrote:

GPG was not vulnerable, so no fix was issued.  Incidentally, GPG does
not attempt to parse the PKCS/ASN.1 data at all.  Instead, it
generates a new structure during signature verification and compares
it to the original.


*That* is the Right Way To Do It. If there are variable parts (like
hash OID, perhaps), parse them out, then regenerate the signature data
and compare it byte-for-byte with the decrypted signature. Anything
you don't understand/control that might be variable (e.g. options) is
eliminated by this process.

I don't think there's anything inherently wrong with ASN.1 DER in
crypto applications.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: cellphones as room bugs

2006-12-04 Thread Taral

On 12/3/06, Thor Lancelot Simon [EMAIL PROTECTED] wrote:

It's been a while since I built ISDN equipment but I do not think this
is correct: can you show me how, exactly, one uses Q.931 to instruct the
other endpoint to go off-hook?


That's the same question I have. I don't remember seeing anything in
the GSM standard that would allow this either.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [Cryptocollectors] STU III 2500

2007-01-14 Thread Taral

On 1/13/07, Roy M. Silvernail [EMAIL PROTECTED] wrote:

This is the first auction I've looked at where eBay is anonymizing the
bidder list.  It's probably a general policy, but interesting that the
first one I saw was for crypto gear.


That's the eBay Private Listing option. Often used in auctions of
adult materials.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: padlocks with backdoors - TSA approved

2007-02-27 Thread Taral

On 2/26/07, Hadmut Danisch [EMAIL PROTECTED] wrote:

Each of these (three digit code) locks had a small keyhole for the
master key to open. Obviously there are different key types
(different size, shape, brand) as the locks had numbers like TSA005
tell the officer which key to use to open that lock.


I'm just waiting for someone with access to photograph said keys and
post it all over the internet.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ad hoc IPsec or similiar

2007-06-26 Thread Taral

On 6/26/07, Sandy Harris [EMAIL PROTECTED] wrote:

It is certainly a problem, but you can get around it partially even if your IP
address is dynamically assigned:

http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/quickstart.html#opp.client

You do need to use a dynamic DNS server to handle your keys, but there
are lots of those, and many do provide that service.

Also, this is limited to initiate-only IPsec; it does not handle incoming
connections. However, that may be enough for many client machines that live
in dynamic address space.


I don't get it. Why is it so limited? Reverse DNS is not significantly
more trustworthy than simply querying the remote host on a known port
if you don't have DNSSEC.

--
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
   -- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: improving ssh

2007-07-19 Thread Taral

On 7/14/07, Ed Gerck [EMAIL PROTECTED] wrote:

1. firewall port-knocking to block scanning and attacks


I would love to see a mode like freenet's silent bob, where connectors
must prove probable knowledge of the host key before the node will
talk.


5. block sending host key fingerprint for invalid or no username


This makes some sense...

1. Client may request proof of host private key.
2. Client must authenticate.
3. Client may request a copy of the host public key.

--
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
   -- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Scare tactic?

2007-09-20 Thread Taral
On 9/19/07, Nash Foster [EMAIL PROTECTED] wrote:
 http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/

 Any actual cryptographers care to comment on this? I don't feel
 qualified to judge.

It's a real (old) vulnerability in DH, but I don't think it applies
here. If you want to expose the cleartext of your IPsec traffic, you
can just send a copy to the observer.

It makes mitm easier on unauthenticated links, but that's not a new
exposure of any kind.

From the article:

There are a number of real-world scenarios where an unknown
key-share completely undermines the legitimacy of networking
infrastructure which is designed to provide high security.

Funny how they didn't provide any details.

-- 
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Intercepting Microsoft wireless keyboard communications

2007-12-13 Thread Taral
On 12/10/07, Steven M. Bellovin [EMAIL PROTECTED] wrote:
 Believe it or not, I thought of CFB...

What about PCFB to get around the block issue? I remember freenet
using it that way...

-- 
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PunchScan voting protocol

2007-12-14 Thread Taral
On 12/12/07, John Denker [EMAIL PROTECTED] wrote:
 Several important steps in the process must be carried out in
 secret, and if there is any leakage, there is unbounded potential
 for vote-buying and voter coercion.

I've done quite a bit of work with this protocol. The protocol assumes
the existence of an Election Authority. The Authority has the master
keys required to generate certain data sets, and these keys give the
Authority the ability to associate ballot numbers with votes. Note
that this doesn't necessarily give the Authority the ability to
associate people with votes.

There are no per-ballot keys, so there is no partial exposure risk.
It's all-or-nothing.

 1) It would be nice to see some serious cryptological protection
 of election processes and results.

 2b) In particular I don't think PunchScan really solves the
 whole problem.

What is the whole problem? Please provide an attack model.

-- 
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Fwd: Fwd: Fwd: PunchScan voting protocol

2007-12-18 Thread Taral
I've attached below Rick's reply to this thread. Rick Carback is a member of
the PunchScan team.

- Taral

-- Forwarded message --
From: Rick Carback
Date: Dec 16, 2007 12:01 PM
Subject: Re: Fwd: Fwd: PunchScan voting protocol

 I think there are some misconceptions/assumptions in play here about the
privacy available in current systems. Punchscan was designed to provide an
unconditional levels of integrity into the voting process, not to improve
privacy over the status quo. Election officials, ultimately, are still
responsible for protecting the privacy of voters. The cryptography is meant
as a tool to be used by election officials that prevents anyone from
arbitrarily changing vote totals without getting caught. I do not think that
Punchscan is noticeably worse than current systems in terms of privacy
protection and it is still unclear to me if there is any real difference at
all.

As for specific responses:

 Well, that's the right question.  That's the sort of question
the punchscan team should be asking themselves, and answering
in more detail that I have heretofore seen.  What threats does
punchscan claim to defend against?  What threats does it leave
to be mitigated by other (non-punchscan) means?

 We have talked about this stuff and published it -- we're still talking
about it, see:

http://punchscan.org/papers/ibs_carback.pdf
http://punchscan.org/papers/receipts_clark.pdf
http://punchscan.org/papers/patterns_popoveniuc
http://punchscan.org/papers/pip_essex.pdf

There will be more publications in the future. Also, you might want to check
out our VoComp submission:

http://punchscan.org/vocomp.php

Unlike any other team at the competition, we were more careful with our
claims and our analysis of our system. Part of that is the reason why we
won.

 As an example: Let's look at the plant where the ballots are
printed.  Suppose somebody attaches a tiny spy camera to
the frame of one of the printing presses, so as to obtain an
image of both parts of the two-part ballot (for some subset
of the ballots).

 In a traditional system, you can put the spy cameras in the polling place
so you can watch each voter vote. That will allow you to *directly* target
and identify each voter in a location where election authorities exert *less
* control over the surrounding environment. By contrast, attacking the
printer provides you with a decryption of the ballots but not who used them
-- you still have to go out and find each voter, and the only reliable way
to do that is to catch them in the act of voting, because they could have
got rid of the receipt or swapped it (Alternatively, receipts could be given
to third parties, e.g. LWV, this is what EPIC suggests). In that sense, this
example is unrealistic. This is especially true when you include machines in
polling places that know how voters vote (in punchscan, they don't), and the
myriad of ways a voter could expose their choices to a coercer. See:

http://punchscan.org/blog/?p=6
http://punchscan.org/blog/?p=7

The comment about partial exposure risk looks like a misunderstanding, so
I'll ignore it

 Ah yes, but what is being assumed about the /properties/ of
this Election Authority?  Is the EA omnipresent and omnipotent,
like the FSM, or does it have boundaries and limitations?
For example, does it ever need to rely on employees or
subcontractors?

 This information is in the original papers, but the EA is responsible for
generating the data, supervising the printing and packaging (which should
include tamper-evident protections), and coordinating the shipment of
ballots to polling places. Essentially, all the things a central authority
would be responsible for in a current optical scan system. It would also be
responsible for generating keys for the scanning equipment and controlling
authentication to the bulletin board, but that is all part of the bulletin
board component that could be generic to any E2E system.

I might post this to the blog, but I am sort of busy. I will let you know
when/if I do.

-R

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Fixing SSL (was Re: Dutch Transport Card Broken)

2008-02-09 Thread Taral
On 2/9/08, David Wagner [EMAIL PROTECTED] wrote:
 By the way, it seems like one thing that might help with client certs
 is if they were treated a bit like cookies.

I don't see how this helps with phishing. Phishers will just go after
the password or other secrets used to authenticate a new system or a
system that has lost its cert.

-- 
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: The perils of security tools

2008-05-27 Thread Taral
On 5/26/08, Simon Josefsson [EMAIL PROTECTED] wrote:
  For example, reading a lot of data from linux's /dev/urandom will
  deplete the entropy pool in the kernel, which effectively makes reads
  from /dev/random stall.  The two devices uses the same entropy pool.

That's a bug in the way the kernel hands out entropy to multiple
concurrent consumers. I don't think it's a semantic issue.

-- 
Taral [EMAIL PROTECTED]
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: UCE - a simpler approach using just digital signing?

2009-01-30 Thread Taral
On Fri, Jan 30, 2009 at 1:47 PM, Ray Dillinger b...@sonic.net wrote:
 This is basic digital signatures; it would work.

What's your transition plan? How do you deal with stolen trust
tokens? (Think trojans/worms.)

Also see: http://craphound.com/spamsolutions.txt

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk subversion standards released

2009-01-30 Thread Taral
On Fri, Jan 30, 2009 at 1:41 PM, Jonathan Thornburg
jth...@astro.indiana.edu wrote:
 For open-source software encryption (be it swap-space, file-system,
 and/or full-disk), the answer is yes:  I can assess the developers'
 reputations, I can read the source code, and/or I can take note of
 what other people say who've read the source code.

Really? What about hardware backdoors? I'm thinking something like the
old /bin/login backdoor that had compiler support, but in hardware.

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Fully Homomorphic Encryption Using Ideal Lattices

2009-05-01 Thread Taral
On Tue, Mar 17, 2009 at 5:06 PM, R.A. Hettinga r...@shipwright.com wrote:
 Title: Fully Homomorphic Encryption Using Ideal Lattices
 Speaker: Craig Gentry, Stanford University
 Time/Place: 11 am, 18 March, Wozniak Lounge
 [Ed. note: 4th floor, Soda Hall, UC Berkeley]

This looks fascinating, but isn't local to me. Does anyone know of a paper?

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Security of Mac Keychain, Filevault

2009-11-03 Thread Taral
On Mon, Nov 2, 2009 at 5:41 PM, Jerry Leichter leich...@lrw.com wrote:
 The trend is for this to get worse, with
 network-wide shared authentication via OpenID or whatever other standard
 catches on.

Not to derail this, but OpenID is flexible enough to permit
fine-grained authentication as well as non-password-based
authentication (e.g. smart card) and multi-factor authentication.

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Fw: Root Zone DNSSEC Deployment Technical Status Update

2010-07-16 Thread Taral
On Fri, Jul 16, 2010 at 7:47 AM, Perry E. Metzger pe...@piermont.com wrote:
 The root zone has been signed, and the root zone trust anchor has
 been published.

Neat, but not (yet) useful... only these TLDs have DS records:

bg. 172800  IN  DS  46846 5 1 
1D83F503CCED4A4B6F7F8DB1CF43D38F9133A3EA
bg. 172800  IN  DS  46846 5 2
26811E459C850F50A85D1EAF589E30DC14D09D1A6E6262E8D36B6BFF C605334C
br. 172800  IN  DS  41674 5 1 
EAA0978F38879DB70A53F9FF1ACF21D046A98B5C
cat.172800  IN  DS  33436 10 2
E1A0FC89B87F5E7F6B354D364CF704855A2E9A52B7F39BBE4E2BEA44 3B81B18E
cz. 172800  IN  DS  7978 5 1 
9B6C3898470914CDDA98D0CC001688CB32C17A09
cz. 172800  IN  DS  9988 5 1 
AA94DEC91A18ECAFB85797AEA1031703FC9A6E73
na. 172800  IN  DS  24484 5 1 
EFC19D4685751FF8E11F96142A083DCB9C708912
tm. 172800  IN  DS  28935 7 1 
C9660594EFA1DA1B6B7359262F2E11052403
tm. 172800  IN  DS  28935 7 2
0C30AA64DF5149B0237F0CAD8E6AB22825BDC8CADBD7CC108F6FFC74 AC428709
uk. 172800  IN  DS  15191 8 2
A057C8553B1DC6CF158A87CD2D0BAA2CDC9C6A14FA03DE02B19AB0DA 62AF279E

Several are using old SHA-1 hashes...

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
    -- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Fw: Root Zone DNSSEC Deployment Technical Status Update

2010-07-17 Thread Taral
On Sat, Jul 17, 2010 at 7:41 AM, Paul Wouters p...@xelerance.com wrote:
 Several are using old SHA-1 hashes...

 old ?

old in that they are explicitly not recommended by the latest specs
I was looking at.

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
    -- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: [Cryptography] IPv6 and IPSEC

2013-08-29 Thread Taral
On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote:
 Additional guidelines for IPv6

 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) 
 and it should match the IP obtained via the forward DNS resolution of the 
 hostname specified in the PTR record. Otherwise, mail will be marked as spam 
 or possibly rejected.

Because under ipv6 your prefix is supposed to be stable (customer
identifier) and the namespace delegated to you on request. Have you
asked your provider for an ipv6 namespace delegation?

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] IPv6 and IPSEC

2013-08-29 Thread Taral
Oh, wait. I misread the requirement. This is a pretty normal
requirement -- your reverse DNS has to be valid. So if you are
3ffe::2, and that reverses to abc.example.com, then abc.example.com
better resolve to 3ffe::2.

On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker hal...@gmail.com wrote:



 On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote:

 On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to
 wrote:
  Additional guidelines for IPv6
 
  The sending IP must have a PTR record (i.e., a reverse DNS of the
  sending IP) and it should match the IP obtained via the forward DNS
  resolution of the hostname specified in the PTR record. Otherwise, mail 
  will
  be marked as spam or possibly rejected.

 Because under ipv6 your prefix is supposed to be stable (customer
 identifier) and the namespace delegated to you on request. Have you
 asked your provider for an ipv6 namespace delegation?


 It is a stupid and incorrect requirement.

 The DNS has always allowed multiple A records to point to the same IP
 address. In the general case a mail server will support hundreds, possibly
 tens of thousands of receiving domains.

 A PTR record can only point to one domain.

 The reason that an MX record has a domain name as the target rather than an
 IP address is to facilitate administration. Forcing the PTR and  record
 to match means that there has to be a one to one mapping and thus defeats
 many commonly used load balancing strategies.

 Google is attempting to impose a criteria that is simply wrong.



 --
 Website: http://hallambaker.com/



-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] IPv6 and IPSEC

2013-09-04 Thread Taral
On Tue, Sep 3, 2013 at 8:54 PM, Lucky Green shamr...@cypherpunks.to wrote:
 In its cryptic explanation of the bounces, Google makes one thing clear: 
 whatever
 reason they have to bounce the email, that reason only applies to IPv6. I 
 believe
 this is wrong.

It only applies to IPv6 because applying it to IPv4 would break too
many people. Not enough people use IPv6, so they are insisting on good
hygiene there.

Why do you not have PTR records for your IPv6 address? The problem is
that, not Google's policy.

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] IPv6 and IPSEC

2013-09-04 Thread Taral
On Sep 4, 2013 12:14 AM, Lucky Green shamr...@cypherpunks.to wrote:
 I *have* PTR records for my IPv6 addresses. What I don't know is which
PTR records will make Gmail happy. SPF PTR records clearly do not do the
trick.

SPF uses TXT records, not PTR ones. Can you share your IPv6 address? I'll
take a look.

- JP
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan

2013-09-13 Thread Taral
On Thu, Sep 12, 2013 at 12:04 PM, Nico Williams n...@cryptonector.com wrote:
 Note: you don't just want BTNS, you also want RFC5660 -- IPsec
 channels.  You also want to define a channel binding for such channels
 (this is trivial).

I am not convinced. It's supposed to be *better than nothing*. Packets
that are encrypted between me and whatever gateway the endpoint elects
to use are strictly better than unencrypted packets, from a security
and privacy standpoint.

Insisting that BTNS should not be used without X, Y, and Z had
better come with a detailed explanation of why BTNS without X, Y, Z
makes me *less* secure than no BTNS at all.

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] RSA equivalent key length/strength

2013-09-30 Thread Taral
On Sun, Sep 29, 2013 at 9:15 PM, Viktor Dukhovni
cryptogra...@dukhovni.org wrote:
 On Mon, Sep 30, 2013 at 10:07:14AM +1000, James A. Donald wrote:
 Therefore, everyone should use Curve25519, which we have every
 reason to believe is unbreakable.

 Superceded by the improved Curve1174.

Hardly. Elligator 2 works fine on curve25519.

-- 
Taral tar...@gmail.com
Please let me know if there's any further trouble I can give you.
-- Unknown
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography