else. Rather chalk & cheese, you can't just wind up the RSA
key size by setting a param in config, more's the pity.
iang
If you really want to go for 128 bit, you need to have the RSA
keys of at least something in the order of 3072 bit. If 2048
is fine, 3DES is fine.
Kurt
Coming back to public key choice, it is now an open question: Do we
recommend just RSA for now and wait until the new curves come on line?
Or stick with ECC as it is now available, because fears are overblown?
I don't know the answer to that one, but framing the question is often
half
Hi Julian,
On 4/01/14 00:04 AM, Julien Vehent wrote:
On 2014-01-03 12:58, ianG wrote:
Right, Windows XP. Which is end of life.
Microsoft killing support for a product isn't the same thing as people
throwing away their computers.
Or, are you implying that because microsoft is endin
On 3/01/14 19:24 PM, Julien Vehent wrote:
On 2014-01-02 18:59, ianG wrote:
On 3/01/14 01:06 AM, Julien Vehent wrote:
3DES isn't broken.
No, but it is end of life. 112bit security for the 2key variant, and
an 8 byte block makes it just old. If you've got AES there, use it.
Who
rgument seems not to survive in
the practical world. But that's something that is contrarian, although
it is becoming more mainstream.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
rome's handling of this is so superior, I didn't even notice there is
no option to continue to the site ...
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Apple just talked about their iOS designs:
http://www.infoworld.com/print/198759
I hope to make it easier for Intel by doing things in the opposite way,
establishing a SW implementation that is designed for HW execution.
Anders
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozill
tends to vary and isn't really a universally
answerable question.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
E and that funny '='
method. All of these are real-life problems in working with documents,
and any signature has to survive the assault of "programs that know
better..."
Out of this are two popular directions:
sophistication - UTF, MIME, XML, etc.
simplification - asci
.
My public key has a unique hash that could (easily) be used to track a
user. I dont want that either.
:)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
the anglo world; it isn't
reliable to ignore the difference by saying "we won't do that, then."
Check out QCs, do they not have addresses? How then can legal
obligations be fulfilled in certain countries?
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ou accept that? Warning means Phishing.
If you do ... then we can ask several questions.
How much value are you protecting? Are smart cards the right tool?
And, is Mozilla interested in exposing all smart cards to phishing?
Difficult questions :)
iang
--
dev-tech-crypto mailing list
pick it up.
You are assuming that just because the browser happens to talk to a
smart card, the browser's security model is what you think it is. No
such luck.
One word: compromise.
That word describes Firefox's smart card model, as well as your own
position ;) It also describes why others (banks, EU, etc) have not
seemed to get this working.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
short order.
Mind you, we don't know how valuable or valueless your application is.
Perhaps you could tell us what the key pair or signature is used for?
Maybe, this discussion should be on private to avoid spamming
dev-tech-crypto list...?
Well, others will chime in and say their bored if they're bored :)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
led smart cards rather than as
security-balanced tools, and the result was that they were broken on two
counts not just one.)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
rd browser.
Well, using my view of a secure message, the conceptual browser can't be
a peer. So all it can do is do packet routing.
But, real-world browsers don't do that, they pretend to be the only
peer, and that's where the trouble starts.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
s out...
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
's what they are taught, and for
good marketing reasons. The brand in question was Verisign, not
Verisign Inc.
Certainly, from this pov, if new roots where presented by Symantec Inc
with "Norton" in the O field, I'd not object.
iang
The third question is: Shoul
s site" ...
but that's a wider rant. As BR comes through and more of the legal
links are written down end-to-end, you'll be under more pressure to
clean up the claims you make to users.)
I am interested in hearing other peoples' thoughts on the matter.
Cheers,
Brian
All, just my jotted off thoughts, others usually disagree.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
e industry -- ones where the CA knows there is trouble.
Or, as Alexandre says, 231:
http://www.foo.be/cgi-bin/wiki.pl/2011-12-17_Certificate_Revocation_Reasons_2011
That's what I think they are doing. Partitioning at the legal/admin level.
I would do something different ;-) So would we
on of all those CRLs be huge, even if they strip off certain
reason codes?
The reason I have confidence in them to make this work, or back off in
the event, is that for all Google's many flaws, they are rather good at
Internet engineering. This might be considered to be their core compe
On 9/02/12 06:58 AM, Jean-Marc Desperrier wrote:
In conclusion I'm 100% in favor of Mozilla adopting this solution,
+1
I haven't looked closely but I'm confident they will do the right thing
in this area.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mo
nt was bypassed so badly that
the model was broken. We're not using the SSL security model, and
haven't been since 1995. So you can do whatever you like, or more
practically, whatever you feel you can get away with (think about the
dozens of connections that modern portals fire u
erver operators. No matter that it is an article of faith that
DOSing the users doesn't work, they just click through. Renegotiation
is a theoretically very sucky and heart-rendering bug.
iang
[0] There are academic demos and nuisance attacks. Apparently Twitter
was attack
-truncated form of SHA256 [0]. As the RSA
algorithm operates over a larger number of bits than 256 [1] there is no
point in supporting truncation within RSA, because we'd just end up
padding the truncation.
And, when doing security work, we always get rid of stuff where we can...
iang
reen should analyse
the self-signed cert and show it is self-signed. It is easy
enough to say "look, Mate, this would never be done on a big
ecommerce site or a bank, but it might be done on a hobbyist
or sysadm site."
iang
___
dev-tec
se this
is the place for advocacy. Advocacy can be evened out,
we'll just ask all the other advocates to join in!?!?
iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
lf.
Have you read the auditor's opinion? It generally starts
with something like "*management* has put in place
procedures and policies..." If you don't trust the checks
performed by the CA, then you're sunk, because the auditor
sho
28 matches
Mail list logo
