RE: New result in predicate encryption: disjunction support

2008-05-05 Thread Scott Guthery
[Moderator's Note: Top posting is discouraged. --Perry] What I meant was that the crypogram decrypted with a correct f(I)=1 key yields the encrypted message "Meet you at Starbucks at noon 0" whereas decryption with a wrong, f(I)=0, key yields "Let's go down to Taco Bell at midnight".

RE: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Scott Guthery
>>> but also a proof that the source code one has is the source of the implementation. This is an unsolved problem for code in tamper-resistant devices. There are precious few procedures to, for example, determine that the CAC card that was issued to Pfc. Sally Green this morning bears any rela

Re: User interface, security, and "simplicity"

2008-05-05 Thread James A. Donald
Steven M. Bellovin wrote: > IPsec operates at layer 3, where there are (generally) > no user contexts. This makes it difficult to bind > IPsec credentials to a user, which means that it > inherently can't be as simple to configure as ssh. > > Put another way, when you tell an sshd whom you wish >

Re: User interface, security, and "simplicity"

2008-05-05 Thread Ed Gerck
Ian G wrote: (on Kerckhoffs's rules) = 6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe. = ... PS: A

Re: User interface, security, and "simplicity"

2008-05-05 Thread James A. Donald
Thor Lancelot Simon wrote: And, in fact, most VPN software of any type fails this test. My concern is that an excessive focus on "how hard is it to set this thing up?" can seriously obscure the important second half of the question "and if you set it up in the easiest possible way, is it safe?"

Re: User interface, security, and "simplicity"

2008-05-05 Thread Thor Lancelot Simon
On Mon, May 05, 2008 at 11:46:49AM +1000, James A. Donald wrote: > Thor Lancelot Simon wrote: > >And, in fact, most VPN software of any type fails this test. My concern > >is that an excessive focus on "how hard is it to set this thing up?" can > >seriously obscure the important second half of the

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread James A. Donald
Marcos el Ruptor wrote: > If you want a guarantee or a proof, better ask all the > reverse engineers you know to take a closer look at > the program and tell you if there is a backdoor, > anything malicious or anything sneaky or suspicious. If it was easy to find deliberate flaws, it would be eve

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Eric Rescorla
At Sun, 04 May 2008 20:14:42 -0400, Perry E. Metzger wrote: > > > Marcos el Ruptor <[EMAIL PROTECTED]> writes: > > All this open-source promotion is a huge waste of time. Us crackers > > know exactly how all the executables we care about (especially all > > the crypto and security related program

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Florian Weimer
* Perry E. Metzger: > Marcos el Ruptor <[EMAIL PROTECTED]> writes: >> Nonsense. Total nonsense. A half-decent reverse engineer does not >> need the source code and can easily determine the exact operation of >> all the security-related components from the compiled executables, >> extracted ROM/EP

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Ben Laurie
Perry E. Metzger wrote: Marcos el Ruptor <[EMAIL PROTECTED]> writes: To be sure that implementation does not contain back-doors, one needs not only some source code but also a proof that the source code one has is the source of the implementation. Nonsense. Total nonsense. A half-decent reverse

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Perry E. Metzger
Ben Laurie <[EMAIL PROTECTED]> writes: > I think that's blatantly untrue. For example, if I look at an AND > gate, I can be absolutely sure about its security properties. An AND gate isn't Turing Equivalent. > Rice's theorem says you can't _always_ solve this problem. It says > nothing about fig

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Perry E. Metzger
Florian Weimer <[EMAIL PROTECTED]> writes: > * Perry E. Metzger: > >> Marcos el Ruptor <[EMAIL PROTECTED]> writes: > >>> Nonsense. Total nonsense. A half-decent reverse engineer does not >>> need the source code and can easily determine the exact operation of >>> all the security-related component

Re: [mm] OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Ben Laurie
Perry E. Metzger wrote: Ben Laurie <[EMAIL PROTECTED]> writes: I think that's blatantly untrue. For example, if I look at an AND gate, I can be absolutely sure about its security properties. An AND gate isn't Turing Equivalent. Nor are most algorithms. Rice's theorem says you can't _always

Re: SSL and Malicious Hardware/Software

2008-05-05 Thread Peter Thoenen
For an unproxied site, I get a small green window with my own choice of text in it (e.g. "Gmail" if I'm visiting https://mail.google.com). If a proxy were to insert itself in the middle, that window would turn yellow, and the message would change to "(untrusted)". Assorted user studies suggest t

Comments on SP800-108

2008-05-05 Thread Jack Lloyd
Hi, As a standard, this is specification is a disaster. Just from a quick read, I see the following: "However, alternative orders for the input data fields may be used for a KDF." "with a length specified by the function, an algorithm, or a protocol which uses T as an input." "In feedback mode,

Re: New result in predicate encryption: disjunction support

2008-05-05 Thread Ariel Waissbein
[Moderator's note: Again, top posting is discouraged, and not editing quoted material is also discouraged. --Perry] Hi list, Interesting. Great work! I had been looking *generic* predicate encryption for some time. Encryption over specific predicates is much older. Malware (e.g., virus) and softw

Re: OpenSparc -- the open source chip (except for the crypto parts)

2008-05-05 Thread Matt Blaze
Nonsense. Total nonsense. A half-decent reverse engineer does not need the source code and can easily determine the exact operation of all the security-related components from the compiled executables, extracted ROM/EPROM code or reversed FPGA/ASIC layout I'm glad to know that you have managed t