At shutdown, a process copies /dev/random to /var/random-seed which is
used on reboots.
Is this a good, bad, or "shrug, whatever" idea?
I suppose the idea is that "all startup procs look the same" ?
tnx.
--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/b
> (In a threshold cryptosystem, the shares would be used in a protocol to
> perform the desired cryptographic operation [e.g., signing] without ever
> reconstructing the real secret.) Has real threshold cryptography never
> been used anywhere?
Yes, the root key for the SET consortium was done
> Also, note that HSTS is presently specific to HTTP. One could imagine
> expressing a more generic "STS" policy for an entire site
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In fact, the RTT costs
are now more prohi
(For what it's worth, I find your style of monocase and ellipses so
incredibly difficult to read that I usually delete your postings unread.)
> as previously mentioned, somewhere back behind everything else ... there
> is strong financial motivation in the sale of the SSL domain name
digital
> c
> How could it be arranged that "if anything happens at all to Edward
> Snowden, he told me he has arranged for them to get access to the full
> archives"?
A lawyer or other (paid) confidant was given instructions that would
disclose the key. "Do this if something happens to me."
It doesn't have
I don't think you need all that much to get good secure private email.
You need a client that can make PEM pretty seamless; reduce it to a
button that says "encrypt when possible." You need the client to be
able to generate a keypair, upload the public half, and pull down
(seamlessly) recipient p
> This is everything *but* PRISM-proof
I wasn't trying to be PRISM proof, hence my subject line. The client
and keyserver could help thwart traffic analysis by returning a few
"extra" keys on each request. The client then sends a structure
message to some of those keys that the receiving client r
> ITAR doesn't require a license or permit for strong hash functions, but for
> US persons
> require(d?) notification of NSA of authorship, contact email and download
> URL(s), at least in
> 2006 it did.
That strikes me as an overly-conservative reading of the rules, but
it's been some time sinc
I still think you are reading it too conservatively. The NSA page
defers the actual rules to somewhere else: "Certain commercial IA and
IA-enabled IT products that contain cryptography and the technical
data regarding them are subject to Federal Government export controls"
Suite B includes algor
> Is there any standard, better still existing code, for translating
> keys and certificates and suchlike to and from XML?
Base64-encoded DER. It's what the XML security standards all (W3C/IETF
XML Digital Signature, W3C/IETF XML Encryption, W3C XKMS, OASIS
WS-Security, etc.) all use. XML DSIG
Today in slashdot (http://it.slashdot.org/it/06/06/12/0710232.shtml) there
was an article about China wanting to get WAPI accepted as a new wireless
security standard. Has anyone looked at it?
/r$
--
SOA Appliances
Application Integration Middleware
--
>From http://www.w3.org/2001/tag/doc/leastPower.html :
When designing computer systems, one is often faced with a choice between
using a more or less powerful language for publishing information, for
expressing constraints, or for solving some problem. This finding explores
tradeoffs relating t
> From a security point of view, shar has obvious
> problems :-)
Really, what? There are things it doesn't do, but since it's only a
packaging format that's a good thing.
/r$
--
STSM, Senior Security Architect
SOA Appliances
Application Integration Middleware
> I have posted my ideas on defensive use of crypto here:
>
> https://www.subspacefield.org/security/cgi-bin/moin.py/CryptoMaxims
>
> This is not about cipher design, it's more about protocol design
> and implementation.
And the very first thing that happened is my browser complained about the
>Many protocols use some form of self describing data format, for example
> ASN.1, XML, S expressions, and bencoding.
I'm not sure what you're getting at. All XML and S expressions really get
you is that you know how to skip past something you don't understand. This
is also true for many (XER,
Papers are nice; working hardware is cooler:) A SHA1/MD5 brute-force
cracker built from "scrapped" HD transformers:
http://nsa.unaligned.org/index.php
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
> I'm looking for a halfway self-contained set of ITU-T recommendations
> which are relevant for implementing X.509v3 certificates. The
> references in RFC 3280 appear to be incomplete; for instance, a
> reference for ASN.1 itself is missing.
The ITU/ISO ASN1 standards are available for free down
In my personal experience, if you are developing a mass-market item with
conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to
get a commodity export license which lets you sell globally.
Disclaimers abound, including that I'm not a lawyer and certainly don't
speak for IBM.
> Is there some technology that they are so afraid of that they still
> won't let it ship or does it just matter who you are, not what it is?
I wouldn't know for sure, but I am sure that who is asking permission does
matter.
/r$, sounding like his idol dan :)
--
STSM, DataPower Chief Pr
> SSL is layered on top of TCP, and then one layers one's
> actual protocol on top of SSL, with the result that a
> transaction involves a painfully large number of round
> trips.
Perhaps theoretically painful, but in practice this is not the case;
commerce on the web is the counter-example. The
> The wider point of Peter's writeup -- and of the therapy -- is that
> developers working on security tools should _know_ they're working in
> a notoriously, infamously hard field where the odds are
> _overwhelmingly_ against them if they choose to engineer new solutions.
Developers working in
> Thus unlike with bridges, you fundamentally can't
> evaluate the quality of a security system you built if you're unfamiliar
> with the state of the art of _attacks_ against security systems, and you
> can't become familiar with those unless you realize that these attacks
> have each brough
I would expect hardware designs to be treated more like hardware than
software.
/r$
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
-
The Cryptog
If only to make sure that there's no confusion about where I stand: I
agree with you completely John. I am not surprised that the feds or Sun
see it otherwise.
/r$
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
> Is there a way of constructing a digital signature so
> that the signature proves that at least m possessors of
> secret keys corresponding to n public keys signed, for n
> a dozen or less, without revealing how many more than m,
> or which ones signed?
Yes there are a number of ways. Usually t
> in order for the application to have access to the keys in
> the crypto hardware upon an unattended reboot, the PINs to the hardware
> must be accessible to the application.
The cards that I know about work differently -- you configure them to
allow unattended reboot, and then no PIN is involve
> All the HSMs I've worked with start their system daemons automatically;
> but the applications using them must still authenticate themselves to
> the HSM before keys can be used. How do the cards you've worked with
> authenticate the application if no PINs are involved?
Sorry, I wasn't clear en
> This at least suggests that the v1.7 readers need to check *all*
> hashes that are offered and raise an alarm if some verify and others
> don't. Is that good enough?
Isn't that what SSL/TLS does?
/r$
--
STSM, DataPower CTO
WebSphere Appliance Architect
http://www.ibm.com/software/in
> http://www.ddj.com/linux-open-source/220800130
Status quo.
/r$
--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/
-
The Cryptography Mailing List
Unsubscribe by send
> Have they forgotten the enormous amount of suspicion last time they
> tried this?
More likely they're expecting everyone else to have forgotten about being
suspicious.
/r$
--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/
> I am designing a transport-layer encryption protocol, and obviously wish
> to use as much existing knowledge as possible, in particular TLS, which
> AFAICT seems to be the state of the art.
In general, it's probably a good idea to look at existing mechanisms and
analyze why they're not appropri
31 matches
Mail list logo
