Re: [Cryptography] RSA recommends against use of its own products.

[John Lowry]

BBN has created three ASN.1 code generators over time and even released a 
couple. (ASN.1 to C, C++, and Java). I believe that DER to support typical 
X.509 management is the easiest subset.  I can check on status for release to 
open source if there is interest. It has been available as part of Certificate 
Management systems we've released to open source but obviously this is a very 
small COI indeed.

I can read hex dumps of ASN.1 and choose not to develop similar skills for XML 
and other types.   I'm getting too old for that kind of skill acquisition to be 
fun. But to forward reference in this chain (with apologies), I too would 
prefer a standard that that has Postel's principles as a touchstone. 

John Lowry





Sent from my iPhone

On Sep 30, 2013, at 0:28, "James A. Donald"  wrote:

> On 2013-09-29 23:13, Jerry Leichter wrote:
>> BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is 
>> another story.  For a comparison, look at the encodings Knuth came up with 
>> in the TeX world.  Both dvi and pk files are extremely compact binary 
>> representations - but correct encoders and decoders for them are plentiful.
> 
> 
> DER is unintelligble and incomprehensible.  There is, however, an open source 
> complier for ASN.1
> 
> Does it not produce correct encoders and decoders for DER?  (I have never 
> used it)
> ___
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography


smime.p7s
Description: S/MIME cryptographic signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: Quantum Key Distribution: the bad idea that won't die...

[John Lowry]

On Apr 20, 2010, at 11:31 AM, Perry E. Metzger wrote:

> 
> Via /., I saw the following article on ever higher speed QKD:
> 
> http://www.wired.co.uk/news/archive/2010-04/19/super-secure-data-encryption-gets-faster.aspx
> 
> Very interesting physics, but quite useless in the real world.
> 
> I wonder why it is that, in spite of almost universal disinterest in the
> security community, quantum key distribution continues to be a subject
> of active technological development.
> 
> Perry
> -- 
> Perry E. Metzger  pe...@piermont.com
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com


There have been many misattributions in the technological world
to include remarks supposedly made about 640K of memory, the number
of computers required for global processing needs, and the number of routers
that would eventually be required for internetworking.  

Perry's claim has the property of actually having been said, so I will archive 
it.

My own speculation is that the security community and its interests are
perhaps a bit broader than than some members wish it were.

If you want to see some interesting physics that represents unexpected
results relevant to communications (and comes from entangled QKD research) 
then take a look at: http://pra.aps.org/abstract/PRA/v81/i2/e023835

There is a human-readable summary at: http://focus.aps.org/story/v25/st7

John




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

History, context, QKD and the Internet

[John Lowry]

I'm old enough to remember hearing (I've worked at BBN for a long  
time now)
that connecting computers on a large scale just isn't going to work,  
that

I would never need more than 4MB of main memory, etc.  Any reader can
fill out the rest without my risking being pedantic.

I do remember before public key when symmetric keys were delivered
by an extended workforce and no-one believed there would be a need
for "consumer" crypto.  I also remember lots of questions about PK,
its validity and management - some of which are still being asked.
Is there a hash algorithm that _everyone_ is satisfied with ?
Authentication before PK was possession of the secret key.

The world of computing and communication sure looks different 40+  
years later.


So I encourage you to look at QKD in context.  I know everything is  
moving

in "internet time" but remember just how recently QKD has been dragged
off of the physics optics bench by some engineers to see what can be  
done
with it.  Also, a small revolution has been taking place while  
discussion (on this list anyway)

has focused on 1st generation QKD.  Several very high speed (up to
nominal line speed) systems have been proposed.  Long-haul all- 
optical networks
are being researched, and some will be built.  The problem of  
authentication

is well understood, even it it hasn't been solved.

Of course, you have to keep up with the literature and not remain
stuck in the '80s with BB84.

We live in "internet time".

John

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

Re: The best riddle you wil hear today...

[John Lowry]

My favorite ...
http://www.geogreeting.com/view.html?zl1erV5i+mReSdx7+nTAh$$M+ohilV14 
+xq_G



On May 2, 2007, at 2:09 PM, Udhay Shankar N wrote:


At 10:27 AM 5/2/2007, Aram Perez wrote:





From another list:


This was one of my faves bits of html from last night















Makes a nice flag..fly it


--
((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com))

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


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

Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

[John Lowry]

Non-repudiation is really very simple in concept.

"The ability to prove to a third party that you (or someone else) was party
to a transaction".

There are a lot of problems regarding who the third party must be, what
constitutes "proof", etc., etc.

In the English common-law system, this is applied in various ways and times.
It all comes down to concepts of "reasonableness", "intent", "care" and so
on.

Can you say "convince the judge or jury of your peers" ?

The same is true for authentication.

John



On 1/7/04 15:06, "Anton Stiglic" <[EMAIL PROTECTED]> wrote:

> 
> - Original Message -
> From: "Jerrold Leichter" <[EMAIL PROTECTED]>
> Cc: "Cryptography" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 07, 2004 7:14 AM
> Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
> 
> 
>> Now that we've trashed non-repudiation ... just how is it different from
>> authentication?
> 
> I don't think the word "authentication" has the same problem as
> "non-repudiation",
> but you do need to be careful how you define it.
> 
> So here we are talking about entity authentication (as opposed to data
> authentication,
> the latter really has a unambiguous definition, at least I hope it does!).
> 
> The way you should define entity authentication
> is by stating that it is a process of verifying that an entity possesses the
> authentication
> credentials associated to a user that entity claims to be.  This entity
> might be the rightful
> user, or it might be someone who stole the credentials from the rightful
> user.   If someone
> stole my ATM card and my PIN, he/she can successfully authenticate
> him/herself to an
> ATM and withdraw money.  The word "authenticate" is appropriate in this last
> phrase.
> 
> But I see that most definitions that have been collected here:
> http://www.garlic.com/~lynn/secgloss.htm#t523
> are not careful about this.
> 
> The thing about non-repudiation is that it is something that even most laws
> do not
> permit.  See for example:
> http://www.firstmonday.dk/issues/issue5_8/mccullagh/
> 
> Non-repudiation applied to digital signatures implies that the definition
> states that
> only one person possibly had possession of the private signing key and was
> conscious
> about the fact that it was used to sign something.
> 
> In most jurisdictions a person has the right to repudiate a signature
> (had-written
> or electronic), and thus non-repudiation does not work.  People have the
> right to
> repudiate signatures since it might be the result of a forgery, fraud, the
> signer might have
> been drunk or something at the time of signing or forced to sign (like with
> a gun to his
> head).Repudiation is possible but non-repudiation is not.
> 
> I know some people who use the term "accountability" instead of
> "non-repudiation"
> to express the property needed in certain systems (commercial
> infrastructures where
> users login and need to be accountable for their acts).  This seems like a
> better term
> to be used in certain contexts, but I'm still thinking about it...
> 
> --Anton
> 
> 
> 
> 
> 
> 
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

Re: Quantum Crypto

[John Lowry]

Perry is absolutely right.
There is no point in pursuing this.
It might even be analogous to what we now know about computers.
We were warned that there would never be a need for more than
A half-dozen - after all, they were extremely expensive just to get
A few more digits in the logarithm table ...  Thank goodness that we stopped
those wasteful government research efforts and put money into improving
analog mechanical desktop calculators - which is all anyone ever needed
anyway.  ;-)

Perry,
I seem to remember paying excessive amounts for my first installations
of 1822, X.25, token-ring, ethernet - in fact all new devices.  Even the
ones that weren't needed ... Initial cost is a poor metric and you of all
people should know it.  However, I sincerely applaud your effort to present
a snapshot of the state of the art - and the effort to qualify the QKD folks
who are prematurely entering the market.  Please try to include a view the
long term potential and imagine how it might be used when you write your
report.  After all, who would have thought that computers _would_ be linked
together to create communication networks ... And that my 75-year old mother
could not only afford one but actually enjoy using it.  (Ok, its a Macintosh
...)
Please don't dismiss what is really a very new research area with unknown
potential - just leaving the physicist's lab bench for the engineering lab
bench - because a few folks are entering the market too soon and claiming
that they have "product".  There is a baby in that bath water !

Season's Greetings !

John


On 12/16/03 10:14, "Perry E.Metzger" <[EMAIL PROTECTED]> wrote:

> 
> There have been more press releases about quantum crypto products
> lately.
> 
> I will summarize my opinion simply -- even if they can do what is
> advertised, they aren't very useful. They only provide link security,
> and at extremely high cost. You can easily just run AES+HMAC on all
> the bits crossing a line and get what is for all practical purposes
> similar security, at a fraction of the price.
> 
> The problem in security is not that we don't have crypto technologies
> that are good enough -- our algorithms are fine. Our real problem is
> in much more practical things like getting our software to high enough
> assurance levels, architectural flaws in our systems, etc.
> 
> Thus, Quantum Crypto ends up being a very high priced way to solve
> problems that we don't have.
> 
> 
> Perry
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

Re: Protocol implementation errors

[John Lowry]

I agree with Peter.  If we're concerned about security implications of a
particular SW technique then obviously we should ban the C language and all
the string libraries first  ;-)

John
On 10/4/03 1:58, "Peter Gutmann" <[EMAIL PROTECTED]> wrote:

> Bill Frantz <[EMAIL PROTECTED]> writes:
> 
>> This is the second significant problem I have seen in applications that use
>> ASN.1 data formats.  (The first was in a widely deployed implementation of
>> SNMP.)  Given that good, security conscience programmers have difficultly
>> getting ASN.1 parsing right, we should favor protocols that use easier to
>> parse data formats.
>> 
>> I think this leaves us with SSH.  Are there others?
> 
> I would say the exact opposite: ASN.1 data, because of its TLV encoding, is
> self-describing (c.f. RPC with XDR), which means that it can be submitted to a
> static checker that will guarantee that the ASN.1 is well-formed.  In other
> words it's possible to employ a simple firewall for ASN.1 that isn't possible
> for many other formats (PGP, SSL, ssh, etc etc).  This is exactly what
> cryptlib does, I'd be extremely surprised if anything could get past that.
> Conversely, of all the PDU-parsing code I've written, the stuff that I worry
> about most is that which handles the ad-hoc (a byte here, a unit32 there, a
> string there, ...) formats of PGP, SSH, and SSL.  We've already seen half the
> SSH implementations in existence taken out by the SSH malformed-packet
> vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP
> analysis tool) with malformed PGP packets (I've also crashed quite a number of
> SSH clients with malformed packets while fiddling with my SSH server code),
> and I'm just waiting for someone to do the same thing with SSL packets.  In
> terms of safe PDU formats, ASN.1 is the best one to work with in terms of
> spotting problems.
> 
> Peter.
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

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

Re: quantum hype

[John Lowry]

QC is currently a one-time pad distribution mechanism - or at lower rates a
key establishment mechanism most suitable for symmetric algorithms.

You are correct that authentication is not inherent.  Then again, this is
also true for "classical" symmetric and PKI schemes.  To be usable, all
crypto requires some kind of authentication mechanism or scheme.

The QC community is well aware of this problem and is working on it.
Please don't give up yet !  In the mean time, manual establishment of an
authentication secret works as do physical means e.g., optical viewing of a
satellite from a ground station.

Please remember that it's early days yet; the problems are real and hard.
Come join the fun.

And watch out for snake oil from early attempts at commercialization  ;-)

John
PS: a small nit.  The quantum channel is tamper _detectable_.  There is no
claim to being "untamperable".  You can always detect tampering (and throw
away those bits) regardless of who you are talking to.  Multiple "reads" of
a photon (several approaches have been considered) is either equivalent to
tampering or yields no information.  Physics is fun !


On 9/16/03 16:03, "Hadmut Danisch" <[EMAIL PROTECTED]> wrote:

> On Sat, Sep 13, 2003 at 09:06:56PM +, David Wagner wrote:
>> 
>> You're absolutely right.  Quantum cryptography *assumes* that you
>> have an authentic, untamperable channel between sender and receiver.
> 
> So as a result, Quantum cryptography depends on the known
> methods to provide authenticity and integrity. Thus it can not
> be any stronger than the known methods. Since the known methods
> are basically the same a for confidentiality (DLP, Factoring),
> and authentic channels can be turned into confidential channels
> by the same methods (e.g. DH), Quantum cryptography can not be
> stronger than known methods, I guess.
> 
> On the other hand, quantum cryptography is based on several
> assumptions. Is there any proof that the polarisation of a
> photon can be read only once and only if you know how to turn
> your detector? 
> 
> AFAIK quantum cryptography completey lacks the binding to
> an identity of the receiver. Even if it is true that just a single
> receiver can read the information, it is still unknown, _who_
> it is. All you know is that you send information which can be read
> by a single receiver only. And you hope that this receiver was the
> good guy.
> 
> Hadmut
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


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