On Fri, Oct 08, 2010 at 11:21:16AM -0400, Perry E. Metzger wrote:
My question: if someone plants something in your car, isn't it your
property afterwards?
If you left a wallet in someone's car, isn't it still yours? And isn't
that so even if you left it there on purpose (e.g., to test a
On Fri, Oct 08, 2010 at 05:45:16PM -0400, Perry E. Metzger wrote:
On Fri, 8 Oct 2010 16:13:13 -0500 Nicolas Williams
nicolas.willi...@oracle.com wrote:
On Fri, Oct 08, 2010 at 11:21:16AM -0400, Perry E. Metzger wrote:
My question: if someone plants something in your car, isn't it
your
On Thu, Oct 07, 2010 at 01:10:12PM -0400, Bernie Cosell wrote:
I think you're not getting the trick here: with truecrypt's plausible
deniability hack you *CAN* give them the password and they *CAN* decrypt
the file [or filesystem]. BUT: it is a double encryption setup. If you
use one
On Tue, Sep 14, 2010 at 03:16:18PM -0500, Marsh Ray wrote:
On 09/14/2010 09:13 AM, Ben Laurie wrote:
Of some interest to me is the approach I saw recently (confusingly named
WebID) of a pure Javascript implementation (yes, TLS in JS, apparently),
allowing UI to be completely controlled by the
On Thu, Aug 26, 2010 at 12:40:04PM +1000, James A. Donald wrote:
On 2010-08-25 11:04 PM, Richard Salz wrote:
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site
A really knowledgeable net-head told me the other day
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote:
There are some possibilities, my co-workers and I have discussed. For
purely internal systems TLS-PSK (RFC 4279) provides symmetric
encryption through pre-shared keys which provides us with whitelisting
as well as
On Mon, Aug 02, 2010 at 12:32:23PM -0400, Perry E. Metzger wrote:
Looking forward, the there should be one mode, and it should be
secure philosophy would claim that there should be no insecure
mode for a protocol. Of course, virtually all protocols we use right
now had their origins in the
On Mon, Aug 02, 2010 at 01:05:53PM -0400, Paul Wouters wrote:
On Mon, 2 Aug 2010, Perry E. Metzger wrote:
For example, in the internet space, we have http, smtp, imap and other
protocols in both plain and ssl flavors. (IPSec was originally
intended to mitigate this by providing a common
On Thu, Jul 29, 2010 at 10:50:10AM +0200, Alexandre Dulaunoy wrote:
On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams
nicolas.willi...@oracle.com wrote:
This is a rather astounding misunderstanding of the protocol. [...]
I agree on this and but the implementation of OCSP has to deal
On Thu, Jul 29, 2010 at 03:47:01PM -0400, Richard Salz wrote:
At shutdown, a process copies /dev/random to /var/random-seed which is
used on reboots.
Is this a good, bad, or shrug, whatever idea?
If the entropy pool has other, reasonable/fast sources of entropy at
boot time, then seeding the
On Tue, Jul 27, 2010 at 10:10:54PM -0600, Paul Tiemann wrote:
I like the idea of SSL pinning, but could it be improved if statistics
were kept long-term (how many times I've visited this site and how
many times it's had certificate X, but today it has certificate Y from
a different issuer and
On Wed, Jul 28, 2010 at 01:21:33PM +0100, Ben Laurie wrote:
On 28/07/2010 13:18, Peter Gutmann wrote:
Ben Laurie b...@links.org writes:
I find your response strange. You ask how we might fix the problems, then
you
respond that since the world doesn't work that way right now, the
On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote:
PKI was invented by Loren Kohnfelder for his bachelor's degree thesis
at MIT. It was certainly a fine undergraduate paper, but I think we
should forget about it, the way we forget about most undergraduate
papers.
PKI alone is
On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote:
Maybe it doesn't, but no revocation mechanism at all makes me nervous.
I don't know Kerberos well enough to comment.
DNSSEC doesn't have revocation but replaces it with very short
signature lifetimes (i.e. you don't revoke, you
On Wed, Jul 28, 2010 at 10:42:43AM -0400, Anne Lynn Wheeler wrote:
On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
long ago and far away ... one
On Wed, Jul 28, 2010 at 11:13:36AM -0400, Perry E. Metzger wrote:
On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams
nicolas.willi...@oracle.com wrote:
I have no objections to infrastructure -- bridges, the Internet,
and electrical transmission lines all seem like good ideas. However,
lets
On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
Nicolas Williams nicolas.willi...@oracle.com writes:
Sorry, but this is wrong. The OCSP protocol itself really is an online
certificate status protocol.
It's not an online certificate status protocol because it can provide
On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
Again, I understand that in a technological sense, in an ideal world,
they would be equivalent. However, the big difference, again, is that
you can't run Kerberos with no KDC, but you can run a PKI without an
OCSP server. The
On Wed, Jul 28, 2010 at 01:25:21PM -0400, Perry E. Metzger wrote:
My mother relies on many certificates. Can she make a decision on
whether or not her browser uses OCSP for all its transactions?
I mention this only because your language here is quite sticky.
Saying it is up to the relying
On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote:
On the other edge of the spectrum, many people now use quite secure
protocols (though I won't claim the full systems are secure --
implementation bugs are ubiquitous) for handling things like remote
login and file transfer,
On Tue, Jul 27, 2010 at 09:54:51PM +0100, Ben Laurie wrote:
On 27/07/2010 15:11, Peter Gutmann wrote:
The intent with posting it to the list was to get input from a collection of
crypto-savvy people on what could be done. The issue had previously been
discussed on a (very small) private
On Tue, Jul 27, 2010 at 06:30:51PM -0600, Paul Tiemann wrote:
** But talking about TLS/SNI to SSL suppliers is like talking about the
lifeboats on the Titanic ... we don't need it because SSL is unsinkable.
Apache support for this came out 12 months ago. Does any one know of
statistics
On Thu, Jul 22, 2010 at 05:59:50PM -0700, John Gilmore wrote:
It's pretty outrageous that anyone would try to patent rolling barcoded
dice to generate random numbers.
If you have children at home you could just point a webcam at their
gameroom, or, depending on how obsessive compulsive their
On Mon, Jul 12, 2010 at 01:13:10PM -0400, Jack Lloyd wrote:
I think it's important to make the distinction between trusting Intel
not to have made it actively malicious, and trusting them to have
gotten it perfectly correct in such a way that it cannot fail.
Fortunately, the second problem,
On Fri, Mar 26, 2010 at 10:22:06AM -0400, Peter Gutmann wrote:
I missed that in his blog post as well. An equally big one is the SSHv2
rekeying fiasco, where for a long time an attempt to rekey across two
different implementations typically meant drop the connection, and it still
does for the
On Sat, Mar 27, 2010 at 12:31:45PM +1300, Peter Gutmann (alt) wrote:
Nicolas Williams nicolas.willi...@sun.com writes:
I made much the same point, but just so we're clear, SSHv2 re-keying has been
interoperating widely since 2005. (I was at Connectathon, and while the
details of Cthon
On Thu, Mar 25, 2010 at 01:24:16PM +, Ben Laurie wrote:
Note, however, that one of the reasons the TLS renegotiation attack was
so bad in combination with HTTP was that reauthentication did not result
in use of the new channel to re-send the command that had resulted in a
need for
On Tue, Mar 23, 2010 at 11:21:01AM -0400, Perry E. Metzger wrote:
Ekr has an interesting blog post up on the question of whether protocol
support for periodic rekeying is a good or a bad thing:
http://www.educatedguesswork.org/2010/03/against_rekeying.html
I'd be interested in hearing what
On Tue, Mar 23, 2010 at 10:42:38AM -0500, Nicolas Williams wrote:
On Tue, Mar 23, 2010 at 11:21:01AM -0400, Perry E. Metzger wrote:
Ekr has an interesting blog post up on the question of whether protocol
support for periodic rekeying is a good or a bad thing:
http
On Wed, Mar 10, 2010 at 09:27:06PM +0530, Udhay Shankar N wrote:
Anyone know more?
http://news.techworld.com/security/3214360/rsa-1024-bit-private-key-encryption-cracked/
My initial reaction from reading only the abstract and parts of the
introduction is that the authors are talking about
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:
Anyone care to give a layman's explanation of the attack? The
explanations I have seen assume a detailed knowledge of the way TLS/SSL
handle re-negotiation, which is not something that is easy to come by
without reading the RFC.
On Sun, Nov 01, 2009 at 10:33:34PM -0700, Zooko Wilcox-O'Hearn wrote:
I don't understand why you need a MAC when you already have the hash
of the ciphertext. Does it have something to do with the fact that
the checksum is non-cryptographic by default (http://docs.sun.com/app/
On Sun, Sep 27, 2009 at 02:23:16PM -0700, Fuzzy Hoodie-Monster wrote:
As usual, I tend to agree with Peter. Consider the time scale and
severity of problems with cryptographic algorithms vs. the time scale
of protocol development vs. the time scale of bug creation
attributable to complex
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote:
Steven Bellovin s...@cs.columbia.edu writes:
This returns us to the previously-unsolved UI problem: how -- with today's
users, and with something more or less like today's browsers since that's
what today's users know -- can a
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything needed for pluggability beyond versioning?
It seems to me protocol designers get all excited about this because
they want to design
On Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
mhey...@gmail.com mhey...@gmail.com writes:
2) If you throw TCP processing in there, unless you are consistantly going to
have packets on the order of at least 1000 bytes, your crypto algorithm is
almost _irrelevant_.
[...]
for a
On Wed, Jul 22, 2009 at 06:49:34AM +0200, Dan Kaminsky wrote:
Operationally, HMAC-SHA-256 is the gold standard. There's wonky stuff all
over the place -- Bernstein's polyaes work appeals to me -- but I wouldn't
really ship anything but HMAC-SHA-256 at present time.
Oh, I agree in general. As
I've an application that is performance sensitive, which can re-key very
often (say, every 15 minutes, or more often still), and where no MAC is
accepted after 2 key changes. In one case the entity generating a MAC
is also the only entity validating the MAC (but the MAC does go on the
wire). I'm
On Tue, Jul 14, 2009 at 11:09:41PM +0200, Weger, B.M.M. de wrote:
Suppose this happens in a production environment of some CA
(root or not), how big a problem is this? I can see two issues:
- they have to build a new CA and distribute its certificate
to all users, which is annoying and maybe
On Wed, Jul 01, 2009 at 12:32:40PM -0400, Perry E. Metzger wrote:
I think he's pointing out a more general problem.
Indeed. IIRC, the Mac keychain uses your login password as its passphrase
by default, which means that to keep your keychain unlocked requires
either keeping the password around
I should add that a hardware token/smartcard, would be even better, but
the same issue arises: keep it logged in, or prompt for the PIN every
time it's needed? If you keep it logged in then an attacker who
compromises the system will get to use the token, which I bet in
practice is only
On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote:
This would be great if LoginWindow.app didn't store your unencrypted
login and password in memory for your entire session (including screen
lock, suspend to ram and hibernate).
I keep hearing that Apple will close my bug about
On Tue, Feb 03, 2009 at 04:54:48PM -0500, Steven M. Bellovin wrote:
Under what legal theory might a certificate -- or a key! -- be
considered property? There wouldn't seem to be enough creativity in
a certificate, let alone a key, to qualify for copyright protection.
Private and secret keys
On Fri, Jan 30, 2009 at 03:37:22PM -0800, Taral wrote:
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
On Wed, Jan 28, 2009 at 04:35:50PM -0500, Jerry Leichter wrote:
[Proposals to use reversible computation, which in principle consume
no energy, elided.]
There's a contradiction here between the computer science and economic
parts of the problem being discussed. What gives a digital coin
On Mon, Jan 26, 2009 at 04:18:39PM -0500, Jerry Leichter wrote:
An email system for the White
House has the additional complication of the Presidential Records
Act: Phone conversations don't have to be recorded, but mail messages
do (and have to
On Mon, Jan 19, 2009 at 01:38:02PM +, Darren J Moffat wrote:
I don't think it depends at all on who you trust but on what algorithms
are available in the protocols you need to use to run your business or
use the apps important to you for some other reason. It also very much
depends on
On Thu, Dec 18, 2008 at 01:06:37PM +1000, James A. Donald wrote:
Peter Gutmann wrote:
... to a statistically irrelevant bunch of geeks.
Watch Skype deploy a not- terribly-anonymous (to the
people running the Skype servers) communications
system.
Actually that is pretty anonymous.
On Wed, Dec 17, 2008 at 03:02:54PM -0500, Perry E. Metzger wrote:
The longer I'm in this field, the more the phrase use with extreme
caution seems to mean don't use to me. More and more, I think that
if you don't have a really good way to test and get assurance about a
component of your
On Tue, Dec 16, 2008 at 03:06:04AM +, StealthMonger wrote:
Alec Muffett alec.muff...@sun.com writes:
In the world of e-mail the problem is that the end-user inherits a
blob of data which was encrypted in order to defend the message as it
passes hop by hop over the store-and-forward
[I'm guessing that nobody here wants yet another quatum crypto is snake
oil, no it's not, yes it is, though it has a bright future, no it's not,
... thread.]
On Fri, Dec 05, 2008 at 02:16:09PM +0100, Eugen Leitl wrote:
In the last couple of years, we've seen a number of quantum key
On Fri, Nov 14, 2008 at 11:04:21PM -0800, Ray Dillinger wrote:
On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:
If someone double spends, then the transaction record
can be unblinded revealing the identity of the cheater.
Identities are not used, and there's no reliance on
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote:
The major obstacle is that the government would want a strong binding
between sim cards and true names, which is no more practical than a
strong binding between physical keys and true names.
I've a hard time believing that this
On Wed, Sep 10, 2008 at 01:29:32PM -0400, William Allen Simpson wrote:
I agree. I'm sure this is a world-wide problem, and head-in-the-sand
cyber-libertarianism has long prevented better solutions. The market
doesn't work for this, as there is a competitive *disadvantage* to
providing
On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
The kerberos style of having credentials expire very quickly is one
(somewhat less imperfect) way to deal with such things, but it is far
from perfect and it could not be done for the ad-hoc certificate
system https: depends on
On Fri, Aug 08, 2008 at 11:20:15AM -0700, Eric Rescorla wrote:
At Fri, 08 Aug 2008 10:43:53 -0700,
Dan Kaminsky wrote:
Funnily enough I was just working on this -- and found that we'd end up
adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am
curious about the
On Fri, Aug 08, 2008 at 12:35:43PM -0700, Paul Hoffman wrote:
At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:
On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
The kerberos style of having credentials expire very quickly is one
(somewhat less imperfect) way to deal
On Wed, Jul 23, 2008 at 05:32:02PM -0500, Thierry Moreau wrote:
The document I published on my web site today is focused on fielding
certificateless public operations with the TLS protocol which does not
support client public keys without certificates - hence the meaningless
security
On Fri, Jul 11, 2008 at 05:08:39PM +0100, Dave Korn wrote:
It does sound a lot like SSL/TLS without certs, ie. SSL/TLSweakened to
make it vulnerable to MitM. Then again, if no Joe Punter ever knows the
difference between a real and spoofed cert, we're pretty much in the same
situation
On Thu, Jul 10, 2008 at 06:10:27PM +0200, Eugen Leitl wrote:
In case somebody missed it,
http://www.tfr.org/wiki/index.php?title=Technical_Proposal_(IPETEE)
I did miss it. Thanks for the link. I don't think in-band key exchange
is desirable here, but, you never know what will triumph in
On Mon, Jun 30, 2008 at 07:16:17AM -0700, Allen wrote:
Given this, the real question is, /Quis custodiet ipsos custodes?/
Putting aside the fact that cryptographers aren't custodians of
anything, it's all about social institutions.
There are well-attended conferences, papers published online
On Mon, Jun 30, 2008 at 11:47:54AM -0700, Allen wrote:
Nicolas Williams wrote:
On Mon, Jun 30, 2008 at 07:16:17AM -0700, Allen wrote:
Given this, the real question is, /Quis custodiet ipsos custodes?/
Putting aside the fact that cryptographers aren't custodians of
anything, it's all about
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
Experiment part two: implement remote login (or remote IMAP, or remote
Web with per-user privileges, etc.) under similar conditions. Recall
that being able to do this was a goal of the IPsec working group.
I think that part
On Tue, Apr 01, 2008 at 12:47:45AM +1300, Peter Gutmann wrote:
Ben Laurie [EMAIL PROTECTED] writes:
And so we end up at the position that we have ended up at so many times
before: the GTCYM has to have a decent processor, a keyboard and a screen,
and must be portable and secure.
One day
On Sun, Feb 03, 2008 at 09:24:48PM +1000, James A. Donald wrote:
Nicolas Williams wrote:
What, specifically, are you proposing?
I am still writing it up.
Running the web over UDP?
In a sense.
That should have been done from the beginning, even before security
became a problem
On Tue, Feb 05, 2008 at 08:17:32AM +1000, James A. Donald wrote:
Nicolas Williams wrote:
Sounds a bit like SCTP, with crypto thrown in.
SCTP is what we should have done http over, though of
course SCTP did not exist back then. Perhaps, like
quite a few other standards, it still does
On Thu, Jan 31, 2008 at 11:12:45PM -0500, Victor Duchovni wrote:
On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote:
If anyone's interested, I did an analysis of this sort of thing in an
unpublished draft Performance Characteristics of Application-level Security
Protocols,
On Wed, Jan 30, 2008 at 02:47:46PM -0500, Victor Duchovni wrote:
If someone has a faster than 3-way handshake connection establishment
protocol that SSL could leverage instead of TCP, please explain the
design.
I don't have one that exists today and is practical. But we can
certainly imagine
On Fri, Feb 01, 2008 at 09:24:10AM -0500, Perry E. Metzger wrote:
Does tinc do something that IPsec cannot?
I use a VPN system other than IPSec on a regular basis. The reason is
simple: it is easy to configure for my application and my OS native
IPsec tools are very difficult to configure.
On Fri, Feb 01, 2008 at 07:58:16PM +, Steven M. Bellovin wrote:
On Fri, 01 Feb 2008 13:29:52 +1300
[EMAIL PROTECTED] (Peter Gutmann) wrote:
(Anyone have any clout with Firefox or MS? Without significant
browser support it's hard to get any traction, but the browser
vendors are too
On Tue, Jan 29, 2008 at 06:34:29PM +, The Fungi wrote:
On Mon, Jan 28, 2008 at 03:56:11PM -0700, John Denker wrote:
So now I throw it open for discussion. Is there any significant
value in two-person login? That is, can you identify any threat
that is alleviated by two-person login,
On Thu, Nov 08, 2007 at 01:49:30PM -0600, [EMAIL PROTECTED] wrote:
PREVIOUS WORK:
Three messages is the proven minimum for mutual authentication. Last
two messages all depend on the previous message, so minimum handshake
time is 1.5 RTTs.
Kerberos V manages in one round-trip. And it could
Doesn't this belong on the old SSHv2 WG's mailing list?
On Sat, Jul 14, 2007 at 11:43:53AM -0700, Ed Gerck wrote:
SSH (OpenSSH) is routinely used in secure access for remote server
maintenance. However, as I see it, SSH has a number of security issues
that have not been addressed (as far I
On Tue, Jun 26, 2007 at 02:03:29PM -0700, Jon Callas wrote:
On Jun 26, 2007, at 10:10 AM, Nicolas Williams wrote:
This too is a *fundamental* difference between QKD and classical
cryptography.
What does this classical word mean? Is it the Quantum way to say
real? I know we're in violent
On Fri, Jun 22, 2007 at 08:21:25PM -0400, Leichter, Jerry wrote:
BTW, on the quantum subway tokens business: In more modern terms,
what this was providing was unlinkable, untraceable e-coins which
could be spent exactly once, with *no* central database to check
against and none of this well,
On Mon, Jun 25, 2007 at 08:23:14PM -0400, Greg Troxel wrote:
Victor Duchovni [EMAIL PROTECTED] writes:
Secure in what sense? Did I miss reading about the part of QKD that
addresses MITM (just as plausible IMHO with fixed circuits as passive
eavesdropping)?
It would be good to read the
On Fri, Jun 22, 2007 at 10:43:16AM -0700, Paul Hoffman wrote:
Note that that RFC is Informational only. There were a bunch of
perceived issues with it, although I think they were more purity
disagreements than anything.
FWIW, if you do *not* care about man-in-the-middle attacks (called
On Tue, Jun 26, 2007 at 01:20:41PM -0700, Paul Hoffman wrote:
For all the other aspects of BTNS (IPsec connection latching [and
channel binding], IPsec APIs, leap-of-faith IPsec) agreeing on a
globally shared secret does not come close to being sufficient.
Fully agree. BTNS will definitely
On Mon, Jun 11, 2007 at 11:28:37AM -0400, Richard Salz wrote:
Many protocols use some form of self describing data format, for example
ASN.1, XML, S expressions, and bencoding.
I'm not sure what you're getting at. All XML and S expressions really get
you is that you know how to skip past
On Fri, Jun 01, 2007 at 08:59:55PM +1000, James A. Donald wrote:
Many protocols use some form of self describing data format, for example
ASN.1, XML, S expressions, and bencoding.
ASN.1 is not an encoding, and not all its encodings are self-describing.
Specifically, PER is a compact encoding
But the main motivation (imho) is that it's trendy. And once anyone
proposes a heavyweight standard encoding, anyone who opposes it is
labeled a Luddite.
Maybe. But there's quite a lot to be said for standards which lead to
widespread availability of tools implementing them, both, open source
On Mon, Jun 11, 2007 at 09:28:02AM -0400, Bowness, Piers wrote:
But what is does help is allowing a protocol to be expanded and enhanced
while maintaining backward compatibility for both client and server.
Nonsense. ASN.1's PER encoding does not prevent extensibility.
On Mon, May 14, 2007 at 11:06:47AM -0600, [EMAIL PROTECTED] wrote:
Ian G wrote:
* Being dependent on PKI style certificates for signing,
...
The most important motivation at the time was to avoid the risk of Java being
export-controlled as crypto. The theory within Sun was that crypto
On Tue, May 15, 2007 at 11:37:56AM +0200, Ian G wrote:
Nicolas Williams wrote:
The requirement for having providers signed by a vendor's key certified
by Sun was to make sure that only providers from suppliers not from,
say, North Korea etc., can be loaded by the pluggable frameworks.
OK
On Wed, May 09, 2007 at 06:04:20PM -0400, Leichter, Jerry wrote:
| Frankly, for SSH this isn't a very plausible attack, since it's not
| clear how you could force chosen plaintext into an SSH session between
| messages. A later paper suggested that SSL is more vulnerable:
| A browser
Subject: Re: no surprise - Sun fails to open source the crypto part of Java
Were you not surprised because you knew that said source is encumbered,
or because you think Sun has some nefarious motive to not open source
that code?
If the latter then keep in mind that you can find plenty of crypto
On Thu, May 03, 2007 at 10:25:34AM -0700, Steve Schear wrote:
At 03:52 PM 5/2/2007, Ian G wrote:
This seems to assume that when a crack is announced, all revenue
stops. This would appear to be false. When cracks are announced in such
systems, normally revenues aren't strongly effected.
On Wed, Apr 25, 2007 at 10:58:01PM -0500, Travis H. wrote:
On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote:
A confounder is an extra block of random plaintext that is prepended to
a message prior to encryption with a block cipher in CBC (or CTS) mode;
the resulting extra
On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
What the RFC seems to be suggesting is that the first block of every
message be SSH_MSG_IGNORE. Since the first block in any message is now
fixed, there's no way for the attacker to choose it. Since the attacker
SSH_MSG_IGNORE
On Wed, Apr 25, 2007 at 03:24:06PM -0300, Mads Rasmussen wrote:
Jee Hea An, Yevgeniy Dodis and Tal Rabin claims that the order doesn't
matter [2]. Encrypt-then-sign or sign-then-encrypt is equally secure.
Is this really true? My feeling was that the principle from Krawczyk's
paper should
On Wed, Apr 25, 2007 at 05:20:30PM +0300, Hagai Bar-El wrote:
On 25/04/07 02:18, Nicolas Williams wrote:
But be careful. Simply chaining the IV from message to message will
create problems (see SSH).
What problem does this (chaining IV from message to message) introduce
in our case?
See
On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows:
[...]
3) Data needing confidentiality is encrypted with the SK in the mode
selected in step 1. The
On Mon, Apr 23, 2007 at 11:23:54AM -0700, Aram Perez wrote:
On Apr 23, 2007, at 8:11 AM, Nicolas Williams wrote:
On Sun, Apr 22, 2007 at 05:59:54PM -0700, Aram Perez wrote:
No, there will be message integrity. For those of you asking, here's
a high level overview of the protocol is as follows
On Fri, Apr 20, 2007 at 08:56:32AM +1200, Sidney Markowitz wrote:
Aram Perez wrote, On 19/4/07 6:29 PM:
Is there any danger in using AES128-CBC with a fixed IV of all zeros?
Here is some discussion about doing this, in the context of PGP doing
just that and why PGP inserts random characters
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote:
At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote:
On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote:
Control: The root signing key only controls the contents of the root,
not any level below the root.
That is, of
On Thu, Feb 15, 2007 at 11:36:35AM -0500, Victor Duchovni wrote:
On Thu, Feb 15, 2007 at 10:10:21AM -0500, Leichter, Jerry wrote:
Meanwhile, the next generation of users is growing up on the immediacy
of IM and text messaging. Mail is ... so 20th century.
Well, you certainly don't want to
On Fri, Feb 09, 2007 at 01:22:06PM +1000, James A. Donald wrote:
Nicolas Williams wrote:
The text you quote doesn't answer the question; the
rest of the wiki frontpage says little more. It tends
to make me think that if an application wants to do
something that I've not enabled it to do
On Thu, Feb 08, 2007 at 06:32:44PM +1000, James A. Donald wrote:
For many tasks, they have to call upon a small amount of
trusted code. For example the normal way an editor
opens a file is that one gives the editor a file name,
and the editor, having full user authority to read or
change any
On Thu, Feb 08, 2007 at 12:23:40PM -0800, Ivan Krstić wrote:
Hi Nico,
Nicolas Williams wrote:
If this means pop-up dialogs for every little thing an application wants
to do then the result may well be further training users to click 'OK'.
It really does help to read at least
On Mon, Feb 05, 2007 at 09:08:07PM -0600, Travis H. wrote:
IIRC, it turned out that Egyptian heiroglyphs were actually syllabic,
like Mesopotamian, so no fun there. Mayan, on the other hand, remains
an enigma. I read not long ago that they also had a way of recording
stories on bundles of
100 matches
Mail list logo
