is insecure but
because it doesnt match their preferred configuration. Quite
irritating if you ever tried running your own mail server.
Adam
On 1 January 2015 at 19:12, Adam Back a...@cypherspace.org wrote:
He's been running an open relay since like 2000 or something... why
not its his relay.
Adam
He's been running an open relay since like 2000 or something... why
not its his relay.
Adam
On 1 January 2015 at 18:40, Sadiq Saif li...@sadiqs.com wrote:
On 12/31/2014 07:16, John Young wrote:
http://cryptome.org/2014/12/gilmore-crypto-censored.htm
Don't run an open mail relay and your IP
This is indeed an interesting and scary question:
On Sun, Jan 05, 2014 at 08:31:42PM +0300, ianG wrote:
What is a game changer is the relationship between the NSA and the
other USA civilian agencies. The breach of the civil/military line
is the one thing that has sent the fear level rocketing
On Sun, Jan 05, 2014 at 09:36:29AM -, D. J. Bernstein wrote:
NSA's Kevin Igoe writes, on the semi-moderated c...@irtf.org list:
[...] impact the Certicom patents have on the use of newer families of
curves, such as Edwards curves.
[...] patent FUD. [...] used to argue against switching to
On Sun, Oct 20, 2013 at 06:55:52PM -0400, Peter Todd wrote:
Note that you can use broadcast encryption to efficiently encrypt the
messages to multiple recipients. (a deployed example is in the AACS
video encryption) Or more simply keep people's PGP keys on file and have
the mail server encrypt
Some may remember Bleichenbacher found a random number generator bias in the
original DSA spec, that could leak the key after soem number of signatures
depending the circumstances.
Its described in this summary of DSA issues by Vaudenay Evaluation Report
on DSA
You know part of this problem is the inability to disable dud ciphersuites.
Maybe its time to get pre-emptive on that issue: pair a protocol revocation
cert with a new ciphersuite.
I am reminded of mondex security model: it was a offline respendable
smart-card based ecash system in the UK, with
Well I think there are two issues:
1. if the public key is derived from a password (like a bitcoin
brainwallet), or as in EC based PAKE systems) then if the point derived from
your password isnt on the curve, then you know that is not a candidate
password, hence you can for free narrow the
:14, Adam Back wrote:
Well I think there are two issues:
1. if the public key is derived from a password (like a bitcoin
brainwallet), or as in EC based PAKE systems) then if the point
derived from your password isnt on the curve, then you know that
is not a candidate password, hence you can
On Mon, Sep 30, 2013 at 10:00:12PM -0400, d...@geer.org wrote:
Dr Adam Back wrote:
PBKDF2 + current GPU or ASIC farms = game over for passwords.
Before discarding passwords as yesterday's fish, glance at this:
http://www.wired.com/opinion/2013/09/the-unexpected-result-of-fingerprint-authe
On Tue, Oct 01, 2013 at 08:47:49AM -0700, Tony Arcieri wrote:
On Tue, Oct 1, 2013 at 3:08 AM, Adam Back [1]a...@cypherspace.org
wrote:
But I do think it is a very interesting and pressing research question
as to whether there are ways to plausibly deniably symmetrically
weaken
On Tue, Oct 01, 2013 at 10:25:10AM -0700, coderman wrote:
On Tue, Oct 1, 2013 at 2:12 AM, Adam Back a...@cypherspace.org wrote:
... And Lucky has some gruesome
alternatively low tech version also which doesnt bear thinking about.
i'm curious about defeating the liveness detection
I didnt see your comment lower down before (quoting got too long).
On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
[oneid]
i like the idea. Any issue/complications with re-provisioning or
multiple devices with same identity?
If you lose one device you can replace the device enrole it
On Tue, Oct 01, 2013 at 04:28:01PM -0400, Jonathan Thornburg wrote:
On Tue, 1 Oct 2013, Adam Back wrote:
The point is rather to switch to keys. Check out oneid.com. [[...]]
Its easy to use, just read the transaction confirmation on your smart phone
and click a button, thats the user
On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote:
On 30/09/13 11:02 AM, Adam Back wrote:
no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward
secret ciphersuites, no baked in key length limits [...] support
soft-hosting [...] Add TOFO for self-signed keys.
Personally
I am not sure if everyone is aware that there is also an unmoderated crypto
list, because I see old familiar names posting on the moderated crypto list
that I do not see posting on the unmoderated list. The unmoderated list has
been running continuously (new posts in every day with no gaps)
On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote:
On 30/09/13 10:47, Adam Back wrote:
Well clearly passwords are bad and near the end of their life-time with
GPU advances, and even amplified password authenticated key exchanges like
EKE have a (so far) unavoidable design requirement to have
On Mon, Sep 30, 2013 at 06:52:47PM +0100, Wasa wrote:
Also the PBKDF2 / scrypt happens on the client side - how do you think
your ARM powered smart phone will compare to a 9x 4096 core GPU monster.
Not well :)
How much would it help to delegate PBKDF2 / scrypt to smartphone GPU to
break this
On Mon, Sep 30, 2013 at 07:41:20PM +0100, Wasa wrote:
The only attack is on the PBKDF2 stored on the server (or malware to grab
the password on the client)
right. I was think SRP/JPAKE where the server does not store
PBKDF2(salt,pwd) server-side, but rather it stores something like
On Wed, Sep 25, 2013 at 11:59:50PM +1200, Peter Gutmann wrote:
Something that can sign a new RSA-2048 sub-certificate is called a CA. For
a browser, it'll have to be a trusted CA. What I was asking you to explain is
how the browsers are going to deal with over half a billion (source: Netcraft
While I get wear leveling is a problem, I'm not sure if the flash in a phone
is even going to use wear-leveling, but say for the sake of argument it
does. It is however not a completely brand-new problem, relatedly spinning
disks now and then suffer sector failures, and the failed sectors are
(Changing the subject line to reflect topic drift).
Thats not bad (make the decryption dependant on accessibility of the entire
file) nice as a design idea. But that could be expensive in the sense that
any time any block in the file changes, you have to re-encrypt the
encryption or, more
On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote:
Apple came within a whisker of solving the problem in iOS by creating
an 'effaceable storage' area within the flash storage, which bypasses
block remapping and can be deleted securely. However, iOS only uses
the effaceable storage
Depending on what you're using this protocol for you maybe should try to
make it so that an attacker cannot tell that two messages are for the same
recipient, nor which message comes before another even with access to long
term keys of one or both parties after the fact. (Forward-anonymity
with disclosure of current keys, in the event of a key compromise anonymity
is lost.
Adam
On Fri, Sep 20, 2013 at 11:19:58AM +0200, Adam Back wrote:
Depending on what you're using this protocol for you maybe should try to
make it so that an attacker cannot tell that two messages are for the same
Thats a good approach but note it does assume your messages are delivered in
the same order they are sent (even though they are delivered
asynchronously). That is generally the case but does not have to be -
neither email nor UDP for example guarantee that.
Maybe you would want to include an
Well aside from the PGP PFS draft that you found (which I am one of the
co-authors of) I also had before that in 1998 observed that any IBE system
can be used to make a non-interactively forware secret system.
http://www.cypherspace.org/adam/nifs/
There were prior IBE systems (with expensive
Mining power policy abuse (deciding which transactions prevail based on
compute power advantage for theft reasons, or political reasons, or taint
reasons) is what committed coins protect against:
https://bitcointalk.org/index.php?topic=206303.0
(Its just a proposal, its not implemented).
Adam
On Fri, Sep 13, 2013 at 04:55:05PM -0400, John Kelsey wrote:
The more I think about it, the more important it seems that any anonymous
email like communications system *not* include people who don't want to be
part of it, and have lots of defenses to prevent its anonymous
communications from
I suspect there may be some positive correlation between brilliant minds and
consideration of human rights ability to think independently and
critically including in the area of uncritical acceptance authoritarian
dictates. We're not talking about random grunt - we're talking about gifted
end
You know coincidentally we (the three authors of that paper) were just
talking about that very topic in off-list (and PGP encrypted:) email.
I remain keen on forward-secrecy, and it does seem to be in fashion again
right now.
Personally I think we in the open community need to up our game an
Could you please get another domain name, that name is just ridiculous.
It might tickle your humour but I guarantee it does not 99% of potential
subscribers...
Unless your hidden objective is to drive away potential subscribers.
Adam
On Sun, Jul 21, 2013 at 11:07:26AM +0200, Eugen Leitl
Forward secrecy is exceedingly important security property. Without it an
attacker can store encrypted messages via passive eavesdropping, or court
order an any infrastructure that records messages (advertised or covert) and
then obtain the private key via burglary, subpoena, coercion or
I do not think it is a narrow difference. End point compromise via
subpoena, physical seizing, or court mandated disclosure are far different
things than pre-emptive storing and later decryption. The scale at which a
society will do them, and tolerate doing them given their inherently
increased
I think it time to deprecate non-https (and non-forward secret
ciphersuites.) Compute power has moved on, session cacheing works,
symmetric crypto is cheap.
Btw did anyone get a handle on session resumption - does it provide forward
secrecy (via k' = H(k)?). Otherwise I saw concerns a disk
On Tue, Jul 02, 2013 at 11:48:02AM +0100, Ben Laurie wrote:
On 2 July 2013 11:25, Adam Back a...@cypherspace.org wrote:
does it provide forward secrecy (via k' = H(k)?).
Resumed [SSL] sessions do not give forward secrecy. Sessions should be
expired regularly, therefore.
That seems like
Fully agree. I suspect the released figures showing a spike in FBI
wire-taps may be cover/laundry and indicative of receiving domestic
targetted crime tips from NSA.
Another vector: the UK GCHQ have reportedly on their list of authorized
spying motivations economic well being. That translates
It seems like there is this new narrative in some peoples minds about all
companies backdoor everything and cooperate with law enforcement with no
questions asked, what do you expect. I have to disagree strongly with this
narrative to combat this narrative displacing reality! I've seen several
You know thats the second time you claimed skype was not end2end secure.
Did you read the skype independent security review paper that Ian posted a
link to?
http://download.skype.com/share/security/2005-031%20security%20evaluation.pdf
It is cleary and unambiguously claimed that skype WAS end
:30PM +0200, Florian Weimer wrote:
* Adam Back:
If you want to claim otherwise we're gonna need some evidence.
https://login.skype.com/account/password-reset-request
This is impossible to implement with any real end-to-end security.
___
cryptography
On 22.05.2013 19:28, Florian Weimer wrote:
* Adam Back:
If you want to claim otherwise we're gonna need some evidence.
https://login.skype.com/account/password-reset-request
This is impossible to implement with any real end-to-end security
Actually I think that was the point, as far as anyone knew and from the last
published semi-independent review (some years ago on the crypto list as I
recall) it indeed was end2end secure. Many IM systems are not end2end so
for skype to benefit from the impression that they still are end2end
This below post didnt elicit any response, but the poster references an
interesting though novel (and therefore possibly risky) alternative
accumulator without the need for a centrally trusted RSA key generator
(which is an anathema to a distributed trust system), or alternatively
zero-trust but
[More address typos, its contagious!, so resending]
This below post didnt elicit any response, but the poster references an
interesting though novel (and therefore possibly risky) alternative
accumulator without the need for a centrally trusted RSA key generator
(which is an anathema to a
vs the other things malware does it also seems like a much more benign
payload - uses a bit more electricity! I imagine they throttle it down
dynamically when the user actually does things to hide the computer slow
down. (Though typically you wont notice with GPU mining unless you are
playing
+0200, Adam Back wrote:
It appears to use cut-and-choose technique to create a non-interactive ZKP
on a one-way accumulator (from Camenisch Lysanka). That results in
relatively big ZKPs which impact bitcoin scalability, it doesnt say how big
they actually are but for good security margin I'm guessing
It appears to use cut-and-choose technique to create a non-interactive ZKP
on a one-way accumulator (from Camenisch Lysanka). That results in
relatively big ZKPs which impact bitcoin scalability, it doesnt say how big
they actually are but for good security margin I'm guessing something like
Also without having read the article, but did read the blog post by one of
the authors as Ian G said zerocoin appears to provide payment privacy, and
public auditability while retaining distributed setting.
However payment publicly auditable payment privacy comes from ZKP of non-set
membership
Yeah but that is basically zero traffic, and I suspect in large part because
its a silly domain that people who dislike inviting their addition to a
watch-list will avoid.
Maybe someone with a more neutral domain could try it - or a cypherpunks.*
domain if they have a listserv handy.
Adam
On
On Mon, Mar 25, 2013 at 05:13:57PM +0100, Moritz wrote:
On 25.03.2013 09:25, Adam Back wrote:
because its a silly domain that people who dislike inviting their
addition to a watch-list will avoid.
Isn't exactly that a nice property of a cypherpunks list?
No it is not, it is a way
.
But my point actually was b...@al-qaeda.net??? Come on that is watch list
bait and an invitation NOT to join list blah, whatever it is about.
Adam
On Mon, Mar 25, 2013 at 06:18:14PM +0100, Eugen Leitl wrote:
On Mon, Mar 25, 2013 at 05:50:18PM +0100, Adam Back wrote:
Isn't exactly that a nice
Ian wrote:
Are we saying then that the threat on the servers has proven so small
that in practice nobody's bothered to push a persistent key
mechanism? Or have I got this wrong, and the clients are doing p2p
exchange of their ephemeral keys, thus dispersing the risk?
Its been a while since I
Was there anyone trying to use OpenPGP and/or X.509 in IM?
I mean I know many IM protocols support SSL which itself uses X.509, but
that doesnt really meaningfully encrypt the messages in a privacy sense as
they flow in the plaintext through chat server with that model.
btw is anyone noticing
The realism of export restricting open source software is utterly ludicrous.
Any self-declaration click-through someone might implement can be clicked
through by anyone, from anywhere, and I presume someone from an embargoed
country is more worried about their own countries laws than US laws, to
Seems to me neither of you read the reference I gave:
I (Adam) wrote:
It is tricky to get forward secrecy for store-and-forard messaging [2],
but perhaps you could incorporate rekeying into your protocol in some
convenient way.
...
[2] http://cypherspace.org/adam/nifs/
Not impossible just
With no criticism to the idea and motivation there are similarities with
having a reply-to of a newsgroup such as alt.anonymous.messages, which is
used as a more secure alternative to reply blocks. To pickup those messages
anonymously you'd ideally need to be able to unobservably download
I dont think its too bad, its fairly intuitive and related english meaning
also. At zero-knowlege we had a precedent of the same use: we used it as an
intentional pun that we had zero-knowledge about our customers, and in
actuality in one of the later versions we actually had a ZKP (to do with
You know other source control systems, and presumably git also, have an
excludes list which can contain wildcards. It comes prepopulated with eg
*.o - as you probably dont want to check them in.
I think you could classify this as a git bug (or more probably a mistake in
how github are
I had the impression this list and its predecssor moderated (too heavily
IMO) by Perry were primarily about applied crypto. So you get to tolerate a
bit of applied crypto security stuff if you're interested in crypto theory
and vice versa. Seems healthy to me (cross informs both camps).
In
For http there is a mechanism for cache security as this is an issue that
does come up (you do not want to cache security information or responses
with security information in them, eg cookies or information related to one
user and then have the proxy cache accidentally send that to a different
I think you could say CTR mode is fragile against counter reuse exposing
plaintext pair XORs, but CBC is also somewhat fragile against IV reuse,
forming an ECB code book around the set of same IV messages.
CBC itself has other issues eg using non-repeating (but non-random) IVs, for
example using
, 2012 at 8:29 PM, Adam Back a...@cypherspace.org wrote:
Well one reason people like Lim-Lee primes is its much faster to generate
them. That is because of prime density being lower for strong primes, at
the sizes of p q for p=2q+1 and you need to screen both p q for
primeness.
With Lim-Lee
, 2012 at 01:15:05AM +0100, Adam Back wrote:
Those are Lim-Lee primes where p=2n+1 where a B-smooth composite (meaning n
= p0*p1*...*pk where each p0 is f size B bits.
http://www.gnupg.org/documentation/manuals/gcrypt/Prime_002dNumber_002dGenerator-Subsystem-Architecture.html
So if Crypto
Well one reason people like Lim-Lee primes is its much faster to generate
them. That is because of prime density being lower for strong primes, at
the sizes of p q for p=2q+1 and you need to screen both p q for primeness.
With Lim-Lee as you maybe saw in the paper you just generate a few
Those are Lim-Lee primes where p=2n+1 where a B-smooth composite (meaning n
= p0*p1*...*pk where each p0 is f size B bits.
http://www.gnupg.org/documentation/manuals/gcrypt/Prime_002dNumber_002dGenerator-Subsystem-Architecture.html
So if Crypto++ is testing if the q from p=2q+1 is prime, its
(note the tidy email editing, Ben, and other blind top posters to massive
email threads :)
See inlne.
On Sun, Dec 16, 2012 at 10:52:37AM +0300, ianG wrote:
[...] we want to prove that a certificate found in an MITM was in the chain
or not.
But (4) we already have that, in a non-cryptographic
(I copied Hans-Joachim Knobloch onto the thread)
Weiner is talking about small secret exponents (small d), no one does that.
They choose smallish prime e, with low hamming weight (for
encryption/signature verification efficiency) like 65537 (10001h) and get a
random d, which will by definition
I'd guess they mean salt is pre-pended to the plaintext and then presume eg
then salt + plaintext encrypted with AES in CBC mode with a zero IV. That
would be approximately equivalent to encrypting with a random IV (presuming
the salt, IV and cipher block are all the same size) because
CBC-Enc(
somewhat difficult to respond to cross-posted e-mails, but
here goes:
On 10/03/2012 03:15 PM, Eugen Leitl wrote:
- Forwarded message from Adam Back a...@cypherspace.org -
From: Adam Back a...@cypherspace.org
Date: Wed, 3 Oct 2012 13:25:06 +0100
To: Eugen Leitl eu...@leitl.org
Cc
And make sure there are multiple internet connections to the hidden servers.
Adam
On Thu, Sep 06, 2012 at 03:40:23AM +0100, StealthMonger wrote:
Good argument. Thanks. It makes Natanael's solution, or some variant
of it, all the more appealing. Keep Natanael's servers secret, such
as on
Reminds me of Feb 2003 - Moderately Hard, Memory-bound Functions NDSS 03,
Martin Abadi, Mike Burrows, Mark Manasse, and Ted Wobber.
(cached at) http://hashcash.org/papers/memory-bound-ndss.pdf
By microsoft research, but then when exchange and oulook added a
computational cost function, for
Strikes me 12TH/sec is not actually very much computation?
http://bitcoinwatch.com/ also gives network hashrate at 12.4 TH/sec.
But a single normally clocked (925Mhz) AMD 7970 based graphics card which
has 2048 cores is claimed to provide 555MH/sec.
I think the separate integrity tag is more general, flexible and more secure
where the flexibility is needed. Tahoe has more complex requirements and
hence needds to make use of a separate integrity tag.
I guess in general it is going to be more general, flexible if there are
separate keys
Well the length extension is not fully flexible. ie you get SHA1( msg )
which translates into msg-blocks || pad msg-length which is then fed to
SHA1-transform, and the IV is some magic values.
So the length extension is if you start with a hash that presumably you dont
know all the msg-blocks.
The bit tying in to my comment a few days ago is they note that apple wont
confirm but no doubt does provide a signed private app that takes the
encrypted key material off the device for brute forcing. And an app for
dumping all data off the device if thats also not possible without jail
Surely one cant think of the limitations (requirement for cooperation from
the OS to test the PIN) as if they are cryptographic limitations...
Apple probably supplies such a service themself to law enforcement as a
private apple approved ready-to-go app.
Adam
On Wed, Apr 04, 2012 at 03:45:09PM
As I recall people were calling the PGP ADK feature corporate access to
keys, which the worry was, was only policy + config away from government
access to keys.
I guess the sentiment still stands, and with some justification, people are
still worried about law enforcement access mechanisms for
You know PFS while a good idea, and IMNSO all non-PFS ciphersuites should be
deprecated etc, PFS just ensures the communicating parties delete the key
negotiation emphemeral private keys after use.
Which does nothing intrinsic to prevent massive computation powered 1024
discrete log on stored
Further the fact that the entropy seeding is so bad that some
implementations are generating literally the same p value (but seemingly
different q values) I would think you could view the fact that this can be
detected and efficiently exploited via batch GCD as an indication of an even
bigger
can it be etc. There's a
psychological theory of why this kind of thing happens in general -
the Dunning-Kruger effect. But maybe 1 happened.
Adam
[1] http://en.wikipedia.org/wiki/Dunning–Kruger_effect
On 18 February 2012 07:57, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
Adam Back
plausible for this case... the effect
would be rather like observed.
Adam
On 18 February 2012 10:40, Adam Back a...@cypherspace.org wrote:
I also was pondering as to how the implementers could have arrived at
this situation towards evaluating Stephen Farrell's draft idea to have
a service
Further the fact that the entropy seeding is so bad that some
implementations are generating literally the same p value (but seemingly
different q values) I would think you could view the fact that this can be
detected and efficiently exploited via batch GCD as an indication of an even
bigger
Well I am not sure how they can hope to go very far underground. Any and
all users on their internal network could easily detect and anonymously
report the mitm cert for some public web site with out any significant risk
of it being tracked back to them. Game over. So removal of one CA from a
My point is this - say you are the CEO of a CA. Do you want to bet your
entire company on no one ever detecting nor reporting the MITM sub-CA that
you issued? I wouldnt do it. All it takes is one savy or curious guy in a
10,000 person company.
Consequently if there are any other CAs that have
You know I also noticed mail sending problems when I was in the UK a month
or two ago. I am transit via heathrow right now, and now I have no problem.
This is pay as you go t-mobile. So maybe they saw the PR problem brewing
and stopped whatever they were doing.
One gotcha (though I am sure
On 2 January 2012 03:01, ianG i...@iang.org wrote:
When I was a rough raw teenager doing this, I needed around 2 weeks to
pick up 5 letters from someone typing like he was electrified. The other 3
were crunched in 4 hours on a vax780.
how many samples? (distinct shoulder surf events)
As there are no NIST KAT / test vectors for the KDF defined in NIST SP 108,
I wonder if anyone is aware of any open source implementations of them to
use for cross testing?
Adam
___
cryptography mailing list
cryptography@randombit.net
Stefan Brands credentials [1] have an anti-lending feature where you have to
know all of the private components in order to make a signature with it.
My proposal related to what you said was to put a high value ecash coin as
one of the private components. Now they have a direct financial
the new cert?
Adam
On Mon, Dec 12, 2011 at 06:21:41PM -0800, Arshad Noor wrote:
On 12/9/2011 12:27 AM, Adam Back wrote:
Do the air gapped private PKI root certs (and if applicable their
non-airgapped sub-CA certs they authorize) have the critical name
constraint
extension eg .foocorp.com meaning
Hi Arshad
Do the air gapped private PKI root certs (and if applicable their
non-airgapped sub-CA certs they authorize) have the critical name constraint
extension eg .foocorp.com meaning it is only valid for creating certs for
*.foocorp.com?
(I am presuming these private PKI certs are sub-CA
Did they successfully hack the CA functionality or just a web site housing
network design documents for various dutch government entities? From what
survives google translate of the original dutch it appears to be the latter
no?
And if Kerckhoff's principle was followed what does it matter if
authorize you or CAs to subverting
the SSL guarantee and other people's security. Even people who have
internal CAs for certification SHOULD NOT be abusing them for MitM.
Adam
On Tue, Dec 06, 2011 at 10:52:43AM +, Florian Weimer wrote:
* Adam Back:
Are there really any CAs which issue sub-CA
Well I was aware of RA things where you do your own RA and on the CA side
they limit you to issuing certs belonging to you, if I recall thawte was
selling those. (They pre-vet your ownership of some domains foocorp.com,
foocorpinc.com etc, and then you can issue www.foocorp.com, *.foocorp.com ..
of privacy in work places (and obviously public places).
More below:
On Fri, Dec 02, 2011 at 11:02:14PM +1300, Peter Gutmann wrote:
Adam Back a...@cypherspace.org writes:
Start of the thread was that Greg and maybe others claim they've seen a cert
in the wild doing MitM on domains the definitionally
On Sat, Dec 03, 2011 at 01:00:14AM +1300, Peter Gutmann wrote:
I was asked not to reveal details and I won't,
Of course, I would do the same if so asked. But there are lots of people on
the list who have not obtained information indirectly, with confidentiality
assurances offered, and for
I wonder what that even means. *.com issued by a sub-CA? that private key
is a massive risk if so! I wonder if a *.com is even valid according to
browsers. Or * that would be funny.
Adam
On Sat, Dec 03, 2011 at 02:24:53AM +1300, Peter Gutmann wrote:
Adam Back a...@cypherspace.org writes
Its rather common for people with load balancers and lots of servers serving
the same domain to have multiple certs.
Same for certs to change to a new CA before expiry. (Probably switched to a
new CA when adding more servers to the load balanced web server farm).
I installed cert patrol and
Anyone have informed opinions on whether ECDSA is patent free?
Any suggestions on EC capable crypto library that implements things without
tripping over any certicom claimed optimizations?
(Someone pointed out to me recently that the redhat shipped openSSL is devoid
of ECC which is kind of a
You know this is why you should use ssh-keys and disable password
authentication. First thing I do when someone gives me an ssh account.
ssh-keys is the EKE(*) equivalent for ssh. EKE for web login is decades
overdue and if implemented and deployed properly in the browser and server
could
I thought I already said this in another message, but perhaps it didnt get
to the list. Apart from the fact that they have some kind of script which
trivially allows you to set the conditions of validity to something
impossible to satisfy eg 0 = 1 that Seth Schoen described; the key in the
1 - 100 of 110 matches
Mail list logo
