Re: Your source code, for sale
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
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)
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)
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...)
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
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
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
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
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?
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?
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)
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: cellphones as room bugs
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
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
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
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
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?
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
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
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
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)
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
