The Doctor writes:
>I was getting roughly twice that - 15-30 counts per minute. The hardware was
>set up for alpha and beta particles, so it got a decent amount of background
>radiation.
The counter you linked to looked like it was using a cheap M4011 tube (Chinese
equivalent of the ubiquitous
The Doctor writes:
>It took me an afternoon to write some Python to measure the times in between
>particles hitting the tube, hash them, and cat them into /dev/urandom.
Problem is that in a standard environment you're getting very little input,
maybe 10-15 counts per minute. If you need entropy
Antonio Sanso writes:
>Comments/answers are welcomed :)
The older RFC 2409 primes are standard PKCS #3 values, {p, g}. RFC 5114 uses
FIPS 186 values, {p, q, g} which allows verification of the values, or at
least certain properties of the values, e.g. that g is a generator of order q.
Unfortuna
Jeffrey Walton writes:
>Google has read the riot act to Symantec, scolding the security biz for its
>slapdash handling of highly sensitive SSL certificates.
Hardly. It's just TB2F business as usual. If you read the original article:
>Symantec performed another audit and, on October 12th, anno
Thierry Moreau writes:
>Q.1 Is the generator value selection per RFC6124 a better alternative than
>the fixed generator value 2?
It's a fashion statement. Specifically, the reasoning in RFC 6142 is:
Many of the commonly used Diffie-Hellman groups are inappropriate for
use in EKE. Most o
On a related topic, I love the fact that they not only have a Trusted
Computing Jamboree, a celebration of subverting TCG technology, but that this
is the seventh annual one...
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.
ianG writes:
>"We will also describe and present results for an entirely new unpublished
>attack against a Chinese Remainder Theorem (CRT) implementation of RSA that
>will yield private key information in a single trace."
>
>An actual cryptography breach! Outstanding if true...
No, just a DPA a
Thor Lancelot Simon writes:
>For at least 15 years there's been general grumbling that the MD5 based
>stream cipher used for confidentiality in RADIUS looks like snake oil.
It's not snake oil, the MD5-based masking was created because it was
exportable. Proper crypto like DES wouldn't have been
Naveen Nathan writes:
>[Quoting someone else]
>> As I see it from that paper the advantages of a key-wrap scheme over using a
>> generic AEAD scheme is that
>>
>> (a) it may be lighter weight in computation and size of ciphertext
>> (b) Defends against âIV misuseâ.
>> (c) RFC 3394 has been aro
ianG writes:
>Seems like we'll find out tho, as Peter and Bear are willing to give it a
>shot.
It's not really "giving it a shot" in my case, it's taking crypto
implementation mistakes so old that people have forgotten about them and
adding them to recent code. All you need to do in theory is p
ianG quotes:
>Can you design an encrypted chat protocol that looks secure to everyone who
>reviews it, but in reality lets anyone who knows some fixed key decrypt the
>messages?
Since some of the organisers read this list and this question may be relevant
for other contributors as well I'll as
stef writes:
>let me summarize (and ask you to reread and understand) grapamps response to
>you: email is dead.
... he said, via email.
Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptog
Jason Iannone writes:
>With that, I ask for a history lesson to more fully understand the PKI's
>genesis and how we got here.
http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf, chapter "PKI".
Peter.
___
cryptography mailing list
cryptography@random
Tony Arcieri writes:
>http://clearcryptocode.org/tls/
>
>Probably not going to happen, but it's nice to dream...
And it is a dream. This is another one of the "let's replace TLS with My Pet
Secure Protocol and then we'll be safe", ignoring the fact that an
implementation of MPSP can and will be
Greg Rose writes:
>You get the routers to create valid-looking certificates for the endpoints,
>to mount man-in-the-middle attacks.
This is relatively easy for home routers, since the self-signed certs they're
configured with are frequently CA certs. In other words they ship from the
factory in
"L. Aaron Kaplan" writes:
>So, Peter, how about this approach?
Sorry about the delayed reply, too much other stuff on my plate at the
moment...
>1. We will have three config options: cipher String A,B,C ( generic safe
>config, maximum interoperability (== this also makes the mozilla people happ
=?iso-8859-15?Q?Kriszti=E1n_Pint=E9r?= writes:
>you can make RSA safer adding more cycles and more code. or you can implement
>it without blinding, and call it a day. it is inconceivable that nobody ever
>will choose the latter "strategy".
I've mentioned this one before, but some time ago I aske
"L. Aaron Kaplan" writes:
>> As a general observation, it also promotes the thinking that all we need to
>> do
>> is choose magic algorithm A instead of magic algorithm B and everything is
>> fixed.
>
>No, if we created that impression then we failed.
The problem is that as you read through th
ianG writes:
>Not sure if it has been mentioned here. The Better Crypto group at
>bettercrypto.org have written a (draft) paper for many of those likely
>configurations for net tools. The PDF is here:
>
>https://bettercrypto.org/static/applied-crypto-hardening.pdf
>
>If you're a busy sysadm with
Warren Kumari writes:
>I've often wondered if there is a clever way to do the inverse -- basically
>to have a "latest" timestamp? This seems like a much harder problem -- 'm
>looking for a "movie plot" type solution that the public can easily
>understandâ¦
You could do it with a physical one-wa
"Paterson, Kenny" writes:
>So what are we to do? Continue to recommend something that is
>cryptographically dreadful simply because everybody is using it? Or to try to
>kickstart the process of breaking with the past? My view is that the latter
>is the right course of action. And a report like th
Sandy Harris writes:
>Cited in a comment on Schneier's blog:
>https://www.schneier.com/blog/archives/2013/10/nsa_eavesdroppi_2.html
>
>Register article with link to actual report:
>http://www.theregister.co.uk/2013/10/31/most_security_protocols_insecure_suggests_enisa/
The original paper was wri
quotes:
>We reject: kings, presidents and voting.
>We believe in: rough consensus and running code.
>-- David Clark
Well that was certainly an elegant concept for a more civilized age, but it's
been:
We used to reject: kings, presidents and voting.
We believed in: ro
Jeffrey Walton writes:
>For completeness, Crypto++ has a factory-like method that serves curves. The
>curves are sorted by OID in the function, so Crypto++ would need an OID for
>ed25519.
{ 1 3 6 1 4 1 3029 1 5 1 } ed209^H^H5519
You have been OIDed. Go forth and encrypt.
Peter.
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
"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
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.
___
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
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:
>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
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
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
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
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.
__
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
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
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
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
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
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/
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
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
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
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
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
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:
>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
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
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
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
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
"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
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
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
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
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
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
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
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
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.
__
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
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
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
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
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.
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
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'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
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 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
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
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
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
"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
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
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:
>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
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:
>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
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
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
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
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
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
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
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
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
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:
>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
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
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
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
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.
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
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
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
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
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
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
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
1 - 100 of 324 matches
Mail list logo
