Adam Back writes:
>I presume its implied (too much tongue in cheek stuff for my literal brain to
>interpret) but a self-signed CA cert is a serious thing
Replying partially to this and partially to an off-list message about "how do
we know it's genuine", look in your browser's trusted CA list, u
"Jeffrey I. Schiller" writes:
>I bet the word "Perfect" mis-leads quite a few people. It isn't perfect
>(unless you take as axiomatic that the cipher in question cannot be broken).
>
>Maybe the term should be renamed "Forward Secrecy... for now." :-)
You could call it Pretty-good Forward Secrecy
StealthMonger writes:
>If we had won, crypto would be in widespread use today for email. As it is,
>enough FUD and confusion was sown to avert that outcome. Even on geek
>mailing lists such as this, signatures are rare.
That's because they serve little purpose and the tools are wy too hard
Jon Callas writes:
>That's hilarious! I love it! But I see some security problems:
>
>[...]
One final one: There's no (implied) guarantee that any money changed hands.
How can I trust a CA certificate if no-one paid for it? This destroys the
very foundations of commercial PKI and the high lev
"James A. Donald" writes:
>You attribute too much competence to our enemies. The problem is that our
>tools are unsatisfactory, no one wants to use them. They need improvement.
Yup.
>One tool that works and is widely used is the vpn.
And Skype. And SSL (as anon-DH opportunistic crypto). An
In the 1980s DEC gave us crypt16, reducing password-guessing from 25 DES
operations to a suffix search requiring only 5 DES operations.
In the 1990s MS gave us LMHASH, reducing it to a single DES operation.
Now, in 2012, the WiFi Alliance is proud to present WPS' wps_reg, which splits
a 7-digit P
Thor Lancelot Simon writes:
>NIST says 2048 bit RSA keys should have a 3 year lifetime. Who here really
>wants to explain to customers (or investors!) that he willfully ignored that
>recommendation and just reused the same old key when making the CSR for that
>new certificate?
This is standard
>So does the expiry period actually matter that much? Intuitively yes,
>rationally, no.
That's a point that I've made as well in the past:
Having said that, the idea that a short certificate lifetime is better seems
to be accepted more as an article of faith than as a product of any real
a
Werner Koch writes:
>Which is not a surprise given that many SSH users believe that ssh
>automagically make their root account save and continue to use their lame
>passwords instead of using PK based authentication.
That has its own problems with magical thinking: Provided you use PK auth,
you'r
Marsh Ray writes:
>Perhaps someone who knows German can better interpret it.
The government was asked "are encrypted communications creating any
difficulties for law enforcement in terms of pursuing criminals and
terrorists?". The government replied "no, not really, so there's no need to
restri
Peter Maxwell writes:
>Why on earth would you need to spread your private-key across any number of
>less secure machines?
The technical details are long and tedious (a pile of machines that need to
talk via SSH because telnet and FTP were turned off/firewalled years ago, I
won't bore you with th
Thierry Moreau writes:
>Unless automated SSH sessions are needed (which is a different problem
>space), the SSH session is directly controlled by a user. Then, the private
>key is stored encrypted on long term storage (swap space vulnerability
>remaining, admittedly) and in *plaintext*form*only*m
Thierry Moreau writes:
>Would you extend the association to PGP usage?
Magical thinking works independently of technology, so I'm sure there's a lot
of it in the PGP world as well :-).
>Would you extend the association to Lotus Notes as another PKC user community
>(http://en.wikipedia.org/wiki
Tim Dierks writes:
>While this is all true, it's also why manufacturers who want persuasive
>analysis of their products hire consulting vendors with a brand and track
>record strong enough that the end consumer can plausibly believe that their
>reputational risk outweighs the manufacturer's desir
coderman writes:
>On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray wrote:
>>...
>> Right, 500 MB/s of random numbers out to be enough for anybody.
>
>these rates often are not useful. even busy secure web or VPN servers use
>orders of magnitude less.
>
>initialization of full disk crypto across an SSD
>From Raymond Chen's blog,
http://blogs.msdn.com/b/oldnewthing/archive/2012/09/06/10346743.aspx:
Since heap corruption can in principle lead to anything, any bug that
results in heap corruption automatically gets a default classification of
Arbitrary Code Execution, and if the heap corrupti
I just got email from Apple asking me to confirm setting up a rescue email
address for my Apple ID account (I haven't owned any Apple products since the
IIe). It's the real thing from Apple, not a phishing email. So it looks like
attackers have gone beyond social engineering access to Apple accoun
coderman writes:
>i'm curious to know if there are documented instances of HSM protected
>private keys stolen via exploit against HSM firmware.
www.cl.cam.ac.uk/~mkb23/research/Chrysalis.pdf
Peter.
___
cryptography mailing list
cryptography@randombi
d...@geer.org writes:
>I clearly need to read something else first. Suggestions?
One of Underwood Dudley's books perhaps?
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
ianG writes:
>from a risk analysis view, the sensible thing to do is to attack the
>bureaucracy not the HSM. The problem with attacking the HSM is that it
>becomes obvious, a property sometimes known as tamper-evidence. Either by
>stealing it or accessing it (I speculate the exploit pointed at b
I was recently sitting downstream of a Deutsche Telekom Speedport router and
noticed that it used a certificate signed by a commercial CA (issued to the
wrong name and expired, but that's another story). The fact that it's a
commercial CA cert indicates that there's only one of them for all Speedp
Marek Lukaszuk writes:
>Have you seen this https://code.google.com/p/littleblackbox/ ?
Yes, they're not in the littleblackbox list, which is why I asked here.
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/
Patrick Mylund Nielsen writes:
>Guess what his optimization was. Yup, he tried every combination of things in
>SSLCipherSuite and simply chose the one with the lest CPU...
I've run into similar things, I've had (potential) users of my software reject
it because it didn't support the NULL_WITH_NU
Steven Bellovin recently forwarded the following link to another list:
http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/all/
In summary, it turns out that what seems like half the world's DKIM users are
using toy keys as short as 384 bits. This isn't just Joe's Pizza and
Zack Weinberg writes:
>Or perhaps the mere presence of a DKIM record is sufficient deterrent against
>spam with forged From addresses at a particular domain, and that's the only
>thing these organizations thought DKIM was good for.
I think it's more likely that DKIM is affecting spammers so li
John Levine writes:
>Hmmn. Is there some point to speculating about the behavior of mail systems
>about which you know nothing?
Absolutely. We have a system design to perform a certain function (and,
unfortunately, mis-marketed as being a solution to a rather different problem,
but that's the
Dave Crocker writes:
>> In summary, it turns out that what seems like half the world's DKIM users are
>> using toy keys as short as 384 bits.
>
>Since neither Wired nor CERT cited anyone's using 384-bit DKIM keys, I don't
>know where this assertion comes from.
Harris found three classes of key
Ben Laurie writes:
>Apparently you think the best way to get a secure platform is to apply
>pressure through pointless security standards.
I think that's a bit of an extreme comment on FIPS 140. For one thing it
makes for a great measure of how desperate a vendor is to get onto the US
governmen
Ben Laurie writes:
>On Tue, Oct 30, 2012 at 11:17 AM, Peter Gutmann
>wrote:
>> Ben Laurie writes:
>>
>>>Apparently you think the best way to get a secure platform is to apply
>>>pressure through pointless security standards.
>>
>> I think that
Jeffrey Walton writes:
>Is anyone aware of of application layer encryption protocols with session
>management tuned for use on cellular networks?
>
>[...]
>From that description your problem isn't at the encryption-protocol level at
all, you need a reliable transport mechanism for cellular netwo
In the past there have been a few proposals to use asymmetric cryptosystems,
typically RSA, like symmetric ones by keeping the public key secret, the idea
behind this being that if the public key isn't known then there isn't anything
for an attacker to factor or otherwise attack. Turns out that do
Jon Callas writes:
>Which immediately prompts the question of "what if it's long or secret?" [1]
>This attack doesn't work on that.
The "asymmetric-as-symmetric" was proposed about a decade ago as a means of
protecting against new factorisation attacks, and was deployed as a commercial
product.
Jeffrey Walton writes:
>I'm trying to figure out why folks like Adobe (who know better and have the
>resources) are still using unsalted MD5.
It's Adobe, you don't even need to go after their passwords, just convince an
employee there to click on a PDF attachment or view a Flash video and you've
John Case writes:
>So what does it cost to start a root CA, get properly audited (as I see the
>root CAs are) and get yourself included into, say, firefox or chrome ?
The rule of thumb I've seen from various inside sources is about $1M [0].
Obviously this can vary quite a lot based on whether yo
In the light of yet another in an apparently neverending string of CA
failures, how long are browser vendors going to keep perpetuating this PKI
farce? [0]. Not only is there no recorded instance, anytime, anywhere, of a
browser certificate warning actually protecting users from harm [1], but the
Ben Laurie writes:
>On Sat, Jan 5, 2013 at 1:26 PM, Peter Gutmann
>wrote:
>> In the light of yet another in an apparently neverending string of CA
>> failures, how long are browser vendors going to keep perpetuating this PKI
>> farce? [0]. Not only is there no re
Ben Laurie with:
>a) I don't believe your figures,
Well I don't believe in the tooth fairy, but in this case you're going to have
to provide a more convincing rebuttal than "I choose not to believe in this
inconvenient information".
>I suspect you don't understand CT - perhaps you'd care to exp
Ben Laurie writes:
I've snipped most of this because, although it'd be fun to keep going back and
forth, I'm not sure if everyone else wants to keep reading the exchange (Ben,
we'll continue it over lunch or dinner some time :-). There is one point
though that really sticks out:
Phishing i
Jon Callas writes:
>Others have said pretty much the same in this thread; this isn't an MITM
>attack, it's a proxy browsing service.
Exactly. Cellular providers have been doing this for ages, it's hardly news.
(Well, OK, given how surprised people seem to be, perhaps it should be news in
ord
Paul Hoffman writes:
>Since there isn't a strong list moderator here, I gotta ask: is this (and
>similar PKIX-is-broken threads) on-topic for this mailing list?
I'd say it is. Despite the title, it's a general-purpose security list, the
logical successor to Perry's list for which the topic was
John Levine writes:
>I'd like a list where people ensured that the subject lines of their messages
>described what the message was about, so I can easily skip the ones that
>aren't of interest. Then I don't much care whether the discussion wanders
>afield of what I want to read.
Isn't topic dri
ianG writes:
>Could OAEP be considered reasonable for signatures?
You need to define "appropriate". For example if you mean "interoperable"
then OAEP isn't even appropriate for encryption, let alone signatures. If
you're worried about timing channels then OAEP is also pretty inappropriate
for
Ryan Sleevi writes:
>Did you just suggest that the timing channels in PKCS#1 v1.5 are easier to
>get right than the timing channels of OAEP?
Yup.
>The same PKCS#1 v1.5 encryption that's confounding people a decade [1] after
>the original attacks [2]?
You're confusing two things, an implementa
Thierry Moreau writes:
>The Bleichenbacher attack adaptation to OAEP is non-existent today and would
>be an even more significant academic result. I must assume that
>Bleichenbacher would have published results in this direction if his research
>would have given those.
Bleichenbacher didn't, but
Ralph Holz writes:
>From what I can tell from our data, the most common symmetric ciphers in SSH
>are proposed by client/servers to be used in CBC mode. With SSL/TLS and
>XMLEnc, this mode has had quite some publicity in the recent past.
There have been attacks on SSH based on the fact that po
Nico Williams writes:
>On Mon, Feb 11, 2013 at 4:45 PM, Peter Gutmann
>wrote:
>> There have been attacks on SSH based on the fact that portions of the packets
>> aren't authenticated, and as soon as the TLS folks stop bikeshedding and
>> adopt
>> encrypt-the
Jeffrey Walton writes:
>I know its nothing new here. I'm just befuddled why standardized protocols
>written in stone by bright folks (IETF, IEEE, et al) continue to suffer
>defects that I don't make/endure (because I listen to cryptographers like
>you).
Well, I'm not really a cryptographer, b
Nico Williams writes:
>I'd go further: this could be the start of the end of the cipher suite
>cartesian product nonsense in TLS. Just negotiate {cipher, mode} and key
>exchange separately, or possibly cipher, mode, and key exchange, in just the
>same way as you propose negotiation of encrypt
Nico Williams writes:
>SSHv2 has a this approach and it has not been a disaster there.
It's still quite a mess. To compare the two, my TLS suite-choosing code is
more or less:
highestSuite = 0;
foreach suite
suite = readInteger();
if priority( suite ) > priority( highestSuite )
Nico Williams writes:
>If we want a policy of limiting what cipher suites we allocate codepoints to
>then we should have an *explicit* policy, and we should not wimp out when it
>comes time to enforcing it.
It'll never work, people will clamour for their pet vanity ciphers no matter
what you say
"Paterson, Kenny" writes:
>In fact, SSHv2 adopts a "Encrypt & MAC" construction and all fields in SSHv2
>are authenticated. But the issue is that this authentication cannot be
>checked until the whole message has arrived, and the receiver has to use a
>field in the plaintext to determine how long
ianG writes:
>Hmmm, I'd say that is 11 times longer than it needs to be :) Anything wrong
>with just this:
>
> CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_GCM_SHA384 =
> { 0x00, 0xXX }
The suites listed were based on a survey of what was used/supported
(admittedly, given that active use
Bodo Moeller writes:
>On Wed, Feb 13, 2013 at 12:52 PM, Peter Gutmann
>wrote:
>
>>active use of ECC suites on the public Internet is practically nonexistent
>
>That's not entirely accurate; try www.google.com.
It was based on the last (SSL Observatory?) scans at the t
Bernhard Amann writes:
>We see quite a bit of ECDHE traffic at the sites that feed our notary. At the
>moment, the top-3 cipher suites we see (by connection count) are
>TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA and
>TLS_ECDHE_RSA_WITH_RC4_128_SHA.
>
>We also see TLS_ECDHE_RSA_WITH_AE
I wrote:
>Those are some pretty odd stats... Camellia is almost as popular as 3DES?
To which Yaron Sheffer pointed me to:
http://stackoverflow.com/questions/10378066/which-algorithm-is-stronger-for-tls-aes-256-or-camellia-256
which says:
The reasoning is contained in the NSS library source c
Bodo Moeller writes:
>If you wonder why NSS would prefer Camellia over AES (I sure did), here's the
>rationale. (Not a very good one, in my opinion -- if servers in certain
>countries are expected to have a strong preference for certain ciphersuites,
>those servers should override client preferen
I've just done a quick tally of the certs posted to
http://www.ccssforum.org/malware-certificates.php, a.k.a. "Digital
Certificates Used by Malware". Looks like Verisign (and its sub-brand Thawte)
are the malware-authors' CA of choice, selling more certs used to sign malware
than all other CAs com
Jon Callas writes:
>As Andy Steingruebl pointed out, there are a lot of malware certs that are
>stolen, so this data needs to be normalized against market share.
Ah, good point. There are some in there that were explicitly sold by CAs to
malware authors, e.g. the "BUSTER ASSISTENCIA TECNICA ELE
I wrote:
>Jon Callas writes:
>>As Andy Steingruebl pointed out, there are a lot of malware certs that are
>>stolen, so this data needs to be normalized against market share.
>
>Ah, good point. There are some in there that were explicitly sold by CAs to
>malware authors, e.g. the "BUSTER ASSISTENC
Say you've implemented a bunch of crypto on your web page via Javascript.
Someone in North Korea (or Iran, or one of the other export-restricted
nations) visits your site.
You've now exported crypto to a restricted country. What happens next?
Peter.
Paul Hoffman writes:
>> You've now exported crypto to a restricted country. What happens next?
>
>You ask a lawyer or a legislator, not a bunch of amateurs in the subject?
Have you tried asking a lawyer or legislator? Would you say the look you got
in response was more deer-in-headlights, or c
Arshad Noor writes:
>Open-source crypto that is downloadable from public-sites has a special
>designation in the EAR; you only need to notify the BIS and provide the
>download URL.
Controls for export to the T countries override the
5D002 exception. In other words there's an exception to the e
Jon Callas writes:
>(Personally, I don't like GCM. I think it's too tetchy. But I'm pretty blase
>about PKCS#1, because I'm used to pouring over it to make sure it's done
>right.)
Same here. GCM combines the scariest features of CTR mode (it's RC4 all over
again, apart from SSL people have man
writes:
>Can anyone enlighten me why client TLS certificates are used so rarely? It
>used to be a hassle in the past
They're still a huge pain to work with, and probably always will be. If you
don't believe me, go to your mother, sit her in front of a computer, sit
behind her with your arms cro
Quoting http://xmpp.org/extensions/xep-0027.html#signing:
Signing enables a sender to verify that they sent a certain block of text.
[...] The text that is signed MAY be the empty string.
(There's no metadata or anything there, just a raw signature).
Peter.
__
Peter Saint-Andre writes:
>No one uses XEP-0027 these days, they all use OTR. The PGP integration with
>XMPP clients was an early experiment in the Jabber community before we even
>called it XMPP. Think 13+ years ago. But clients never signed empty strings,
>although we never fixed the spec becau
Jeffrey Walton writes:
>Android 4.0 and above also offer a Keychain (
>http://developer.android.com/reference/android/security/KeyChain.html). If
>using a lesser version, use a Keystore (
>http://developer.android.com/reference/java/security/KeyStore.html).
What Android gives you is pretty rudim
Thierry Moreau writes:
>Client-side storage of long-term secrets can only be secured by dedicated
>client-side hardware. Your mileage may vary.
In a perfect world, yes. However having an OS-provided, standardised
mechanism that gets things mostly right (Apple Keyring) is far, far better
than fo
Paul Walker writes:
>I'm curious which bits you feel Apple got right with the Keychain - not
>because I disbelieve you, but because I don't know. :-) Have you got any
>links or documents, either for what they did right or for what the others do
>wrong?
Link sent off-list. Another nice thing Ap
Jeffrey Walton writes:
>What is the reason for checksumming symmetric keys in ciphers like BATON?
>
>Are symmetric keys distributed with the checksum acting as a authentication
>tag? Are symmetric keys pre-tested for resilience against, for example,
>chosen ciphertext and related key attacks?
Fo
Ethan Heilman writes:
>Do I understand you correctly. The checksum is calculated using a key or the
>checksum algorithm is secret so that they can't generate checksums for new
>keys? Are they using a one-way function? Do you have any documentation about
>this?
Like the algorithms themselves, th
ianG writes:
>"An internal Drug Enforcement Administration document seen by CNET discusses
>a February 2013 criminal investigation and warns that because of the use of
>encryption, "it is impossible to intercept iMessages between two Apple
>devices" even with a court order approved by a federal j
"Kevin W. Wall" writes:
>I think you're giving the NSA way too much credit on why security sucks. Even
>if we were to restrict 'security' to the scope of cryptography, even there, I
>think the NSA has much less to do with dumbing down crypto security than
>other factors.
Exactly. If the NSA di
jimsimps...@hushmail.com writes:
>We are researchers from different parts of the world and conducted a study on
>the worldâs biggest bogus computer science conference WORLDCOMP (
>http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia
>from University of Georgia, USA.
... and
Bill Scannell writes:
>"Last week NSA Director Keith Alexander told the House Permanent Select
>Committee on Intelligence that Snowden was able to access files inside the
>NSA by fabricating digital keys that gave him access to areas he was not
>allowed to visit as a low-level contractor and syst
Nadim Kobeissi writes:
>AES-GCM is already prioritized over RC4, but unfortunately most browsers
>don't support AES-GCM yet, which is why RC4 remains as the secondary choice.
>In the case that AES-GCM is not supported, we use RC4 instead of AES-CBC in
>order to mitigate for BEAST. If you have alt
Nico Williams writes:
>I'd like to understand what attacks NSA and friends could mount, with Intel's
>witting or unwitting cooperation, particularly what attacks that *wouldn't*
>put civilian (and military!) infrastructure at risk should details of a
>backdoor leak to the public, or *worse*, be s
William Yager writes:
>no cryptographer ever got hurt by being too paranoid, and not trusting your
>hardware is a great place to start.
And while you're lying awake at night worrying whether the Men in Black have
backdoored the CPU in your laptop, you're missing the fact that the software
that's
Noon Silk writes:
>A good point, of course. So what should everyone do?
Look for things, and fix things, in order of likelihood of occurrence and
exploitability. (Strong) Crypto is bypassed, not penetrated, so address that
first. Once you've addressed all of those issues, then you can start
William Yager writes:
>It's nice that you can be so cavalier about this, but if your system's RNG is
>fundamentally broken, it doesn't really matter so much whether your other
>stuff is well-programmed or not.
Well I'm not sure what thread you're coming in from, but the current one was
about th
Ben Laurie writes:
>But what's the argument for _not_ mixing their probably-not-backdoored RNG
>with other entropy?
Oh, no argument from me on that one, mix every entropy source you can get your
hands on into your PRNG, including less-than-perfect ones, the more redundancy
there is the less the
Matthew Green writes:
>In summary, don't use RC4. Don't use it carelessly with IVs. And don't use
>RC4.
The first rule of RC4 club is...
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/crypto
Eugen Leitl quotes:
>Just came accross this article, apparently showing the bad quality of the
>hardware RNG in Raspberri Pi devices.
>
>http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
That shows the bad quality of RANDU. It shows t
Marcus Brinkmann writes:
>If you trust anonymous leaks to the Financial Review by members of your
>favourite spying agency network, then I guess its "evidence".
More importantly, look at the dates:
The ban was introduced in the mid-2000s after intensive laboratory testing
of its equipment a
I recently got a another of the standard phishing emails for Paypal, directing
me to https://email-edg.paypal.com, which redirects to
https://view.paypal-communication.com, which has a PayPal EV certificate from
Verisign. According to this post
http://www.onelogin.com/a-paypal-phishing-attack/
Erwann Abalea writes:
>Looks like paypal-communication.com is a legit domain owned by "Paypal, Inc".
Even though, according to the second article I referenced, Paypal said it was
a phishing site and said they'd take it down?
Peter.
___
cryptography ma
Nico Williams writes:
>It might be useful to think of what a good API would be.
The problem isn't the API, it's the fact that you've got two mutually
exclusive requirements, the security geeks want the (P)RNG to block until
enough entropy is available, everyone else wants execution to continue
yersinia writes:
>To illustrated this, Peter displayed a photograph of three icosahedral says
>That He'd thrown at home, saying" here, if you need a random number, you can
>use 846.
And there's the problem, he used a D20 so there's a bias in the results. If
he'd used a D16 like this one,
http
shawn wilson writes:
>It's not like they're the only ones that sell these, but they /were/ the only
>ones to sell USB PRNG at <$800.
You can get them for as little as $50 in the form of USB-key media players
running Android. Or if you really insist on doing the whole thing yourself,
get somethi
Sandy Harris writes:
>A sound device is available on many server boards and often unused, or you
>can add one in a slot or USB on others,
A friend of mine looked at this a while back using the pretty simple technique
of drawing a scatter plot from the samples. The output of most disconnected
au
ianG writes:
>On a related point, what name do we give to the design/pattern for
>
> entropy sources ==> mix/pool ==> deterministic expansion function
>
>?
"The standard way to do things"? Or "a standard CSPRNG" (continually seeded
PRNG).
Peter.
__
Alan Braggins writes:
>A general purpose cloud VM where an attacker has a chance to run his VM on
>the same underlying hardware may be more problematic. But also harder to fix
>with a DIY USB device
... plugging it in when your service provider is in Belgium and you're in
Canada is going to
Just appeared on the GnuPG list:
NeuG 0.11 was released. NeuG is an implementation of True Random
Number Generator based on quantization error of ADC of STM32F103.
It is basically intended to be used as a part of Gnuk, but we also
have standalone USB CDC-ACM version (you can get random stream fr
ianG writes:
>One mystery is left for me. Why so much? It clearly doesn't cost that much
>money to implement the DRBG, or if it did, I would have done it for $5m,
>honest injun! Nor would it cost that to test it nor to deploy it on mass.
>Documentation, etc.
You're assuming that someone got p
Adam Back writes:
>Apparently or so I've heard claim SSDs also offer lower level APIs to
>actually wipe physical (not logically wear-level mapped) cells, to reliably
>wipe working cells. Anyone know about those? They could be used where
>available and to the extent they are trusted.
What you'r
Tony Arcieri writes:
>What threat are you trying to prevent that isn't already solved by the use of
>cryptography alone?
The threat of people saying "we'll just throw some cryptography at it and then
all our problems will be solved".
Peter.
___
crypto
Adam Back writes:
>Is there a possibility with RSA-RSA ciphersuite to have a certified RSA
>signing key, but that key is used to sign an RS key negotiation?
Yes, but not in the way you want. This is what the 1990s-vintage RSA export
ciphersuites did, but they were designed so you couldn't use t
Paul Bakker writes:
>So you agree we DO need an additional layer of symmetric and public key
>encryption, don't you? Six layers might not be enough!!
Oh everyone knows that, if it doesn't have the full seven layers then you're
not even trying.
Peter.
___
"James A. Donald" writes:
>By moving away from anything NIST has touched he deprives the NSA of leverage
>to insert backdoors,
Just as a bit of a counterpoint here, how far do you want to go down this
rathole? Someone recently pointed me to the latest CERT vuln. summary
(because of a few intere
Jon Callas writes:
>In Silent Text, we went far more to the "one true ciphersuite" philosophy. I
>think that Iang's writings on that are brilliant.
Absolutely. The one downside is that you then need to decide what the OTS is
going to be. For example Mozilla (at least via Firefox) seems to thin
201 - 300 of 324 matches
Mail list logo
