Re: [cryptography] Just how bad is OpenSSL ?
On Sat, Nov 3, 2012 at 12:26 AM, James A. Donald jam...@echeque.com wrote: On Oct 30, 2012 7:50 AM, Ben Laurie b...@links.org wrote: The team has ruled out having the master at github. What is wrong with github? TBH, I wouldn't mind much, but I think the concern is that its not under our control. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] cryptography: 576-bit ECC ....novel uses of key....Asymmetric....Symmetric group key....
Hello. I am still interested in the concept of using 576 bit keys; composed of 9 parts of 64-bit keys, and applied and mixed by SHA-256 or SHA-3. Comments? Message: 1 Date: Sun, 04 Nov 2012 15:03:56 +1300 From: Peter Gutmann pgut...@cs.auckland.ac.nz To: cryptography@randombit.net, j...@callas.org Subject: Re: [cryptography] Why using asymmetric crypto like symmetric crypto isn't secure Message-ID: e1tupz6-0002cu...@login01.fos.auckland.ac.nz Jon Callas j...@callas.org writes: Which immediately prompts the question of what if it's long or secret? [1] This attack doesn't work on that. The asymmetric-as-symmetric was proposed about a decade ago as a means of protecting against new factorisation attacks, and was deployed as a commercial product. I don't recall them keeping the exponent secret because there wasn't any need to... until now that is. So I think Taral's comment about not using crypto in novel ways is quite apropos here, the asymm-as-sym concept only protected you against the emergence of novel factorisation attacks (or the use of standard factorisation attacks on too-short keys) as long as no-one bothered trying to attack the public-key-hiding itself. If you believe that the only attack against RSA is factoring the modulus, then you can be seduced into thinking that hiding the modulus makes the attacker's job harder. Yup, and that was the flaw in the reasoning behind the keep-the-public-key- secret system. So this a nice textbook illustration of why not to use crypto in novel ways based purely on intuition. Peter. [1] Not my footnote. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Application Layer Encryption Protocols Tuned for Cellular?
ianG wrote: On 1/11/12 10:55 AM, Peter Gutmann wrote: Jeffrey Walton noloa...@gmail.com writes: Is anyone aware of of application layer encryption protocols with session management tuned for use on cellular networks? [...] From that description your problem isn't at the encryption-protocol level at all, you need a reliable transport mechanism for cellular networks, [...] Also, crypto tends to solve things that apply broadly across the layers, so if a design incorporates crypto right from the start, and uses those results broadly, benefits ensue I am very novice at Host Identity Protocol, I encountered it while making a quick survey of Internet protocols with a perspective similar to the original post. HIP addresses Host Identity *and* end-to-end security. The rendez-vous functionality (addressing the mobility use case) seems in the design right from the start. HIP also appears as a lightweight IPsec, but certainly others can offer more wisdom in this respect. Not a simple solution, but how could the original post requirements be adequately served by a simple solution? Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Why using asymmetric crypto like symmetric crypto isn't secure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2012, at 7:03 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Jon Callas j...@callas.org writes: Which immediately prompts the question of what if it's long or secret? [1] This attack doesn't work on that. The asymmetric-as-symmetric was proposed about a decade ago as a means of protecting against new factorisation attacks, and was deployed as a commercial product. I don't recall them keeping the exponent secret because there wasn't any need to... until now that is. So I think Taral's comment about not using crypto in novel ways is quite apropos here, the asymm-as-sym concept only protected you against the emergence of novel factorisation attacks (or the use of standard factorisation attacks on too-short keys) as long as no-one bothered trying to attack the public-key-hiding itself. Point taken. I'm being too grumpy. I think this is a brilliant result because it gives us a see, see reference to give to people. I'm big on sneering at proofs of security because they often do not relate to real security in the real world in ways that upset me (a guy whose degree is in mathematical logic) to my core. If you want the same sort of rigor that math has, security is useless. On the other hand, and Hal Finney drove this home to me many times, they do tell you what sort of things you can ignore. This one is great because of the way it slaps intuition around. If you believe that the only attack against RSA is factoring the modulus, then you can be seduced into thinking that hiding the modulus makes the attacker's job harder. Yup, and that was the flaw in the reasoning behind the keep-the-public-key- secret system. So this a nice textbook illustration of why not to use crypto in novel ways based purely on intuition. There are all sorts of things people do based on an intuition. Hell, I've done them. Sometimes they just present themselves. If I had a protocol that didn't expose public keys (suppose they're all wrapped in a secure transfer), I might point out that hey, this system has hidden RSA keys. But this points out that unless there is a lot of extra work you do, you didn't do squat. It also suggests that the conservative engineering approach, which is to say that unless you can characterize added security it's just fluff, has new backing in fact. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFQluTIsTedWZOD3gYRAvvGAKDAGkbALD3jqLq8kmG7VIXWtJ2sWACfWOwG DFFKn3LjBEqvpwv4lqHYn04= =G0xh -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Application Layer Encryption Protocols Tuned for Cellular?
On Sat, Nov 3, 2012 at 9:08 PM, d...@geer.org wrote: ... In practice, the 7 layer model was not an implementation recipe - TCP/IP in the broader Internet sense showed that engineering required working with the tech of the time, not the abstractions from some CS class or government contract sales team. TCP in the narrow sense shows it again - sticking TCP in layer 4 and stopping there doesn't work - it claims everything is a stream, when 'everything is a datagram' is closer to the truth, and a more useful assumption. TCP further assumes it can reliably deliver data, when actually it's only reliable enough if you care only enough to do the demo. ... I don't know what to think of the following, but it may be germane: http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf Somewhat off topic, but Day has another good presentation at http://csr.bu.edu/rina/KoreaHowtoCleanASlate100219.pdf. * Mobility is cumbersome and doesn’t scale - Excuse: What do you mean? It works. . . . . Sort of. - Actual: With only physical addresses, hard to do “re-locatable” addressing ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Sun, Nov 4, 2012 at 8:42 AM, Ben Laurie b...@links.org wrote: On Sat, Nov 3, 2012 at 12:26 AM, James A. Donald jam...@echeque.com wrote: On Oct 30, 2012 7:50 AM, Ben Laurie b...@links.org wrote: The team has ruled out having the master at github. What is wrong with github? TBH, I wouldn't mind much, but I think the concern is that its not under our control. It's just git, so keep multiple clone repos. You could use an internal one as the master and push updates to the github one if you don't trust github -- use github to serve outsiders. Really, what matters is that you have one master repo and all other official repos be read-only clones of it. As with any master/slave failover/takeover scheme you can always recover from the death of the master by promoting a clone to master status. So why not trust github? Because they've been hacked? But if you keep multiple clones and people keep private clones then you depend on git's use of SHA-1 Merkle hash trees for security. Or, if you want *private* repos, then you must either run your own git servers or pay a github or gitorious. Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Application Layer Encryption Protocols Tuned for Cellular?
On 5/11/12 09:45 AM, Jeffrey Walton wrote: On Sat, Nov 3, 2012 at 9:08 PM, d...@geer.org wrote: ... In practice, the 7 layer model was not an implementation recipe - TCP/IP in the broader Internet sense showed that engineering required working with the tech of the time, not the abstractions from some CS class or government contract sales team. TCP in the narrow sense shows it again - sticking TCP in layer 4 and stopping there doesn't work - it claims everything is a stream, when 'everything is a datagram' is closer to the truth, and a more useful assumption. TCP further assumes it can reliably deliver data, when actually it's only reliable enough if you care only enough to do the demo. ... I don't know what to think of the following, but it may be germane: http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf Somewhat off topic, but Day has another good presentation at http://csr.bu.edu/rina/KoreaHowtoCleanASlate100219.pdf. * Mobility is cumbersome and doesn’t scale - Excuse: What do you mean? It works. . . . . Sort of. - Actual: With only physical addresses, hard to do “re-locatable” addressing I think they (both) germane and on topic - but he's looking at it from a completely different perspective. We are talking about how to make the net work across phones, John Day is talking about what is wrong with net from fundamentals. IOW, we're assuming IP as the given, he's attacking IP TCP as a broken result of a muffed layer architecture, and moving to replace it with how it should be. Where we meet is that some of his conceptual (?) criticisms are exactly why the net does not work well across mobile. E.g., slide 40, talking about connection v. connectionless: == Resolving the CO/CL Problem • Lets look at this very carefully • What makes connection-oriented so brittle to failure? • When a failure occurs, no one knows what to do. • Have to go back to the edge to find out how to recover. • What makes connectionless so resilient to failure? • Everyone knows how to route everything! • Just a minute! That means! • Yes, connectionless isn’t minimal state, but maximal state. • The dumb network ain’t so dumb. • Where did we go wrong? • We were focusing on the data transfer and ignoring the rest: 11/01/06 slide 40 © John Day, 2010 All Rights Reserved == iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
