Wednesday, January 11, 2017

Off The Record communications

The title of the paper has a byline: “Why Not To Use PGP”. Sometimes, private back channel conversations are best when
  • - They are confidential and kept private between the participants – so the messages should be encrypted in transit
  • - The parties must be clearly authenticated / identified so you know who you’re talking to
  • - They offer repudiation: the conversation must remain unverifiable to third parties, where conventional encryption would identify and verify who said what (and when), if keys were to be compromised or broken.
PFS (perfect forward secrecy) is desirable in these use cases since “compromise of long-term keys does not compromise past session keys”. From the article, “If forward secrecy is used, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered.”

If it is useful to have a verifiable record, use PGP and proper signatures.

If you want to just float an idea privately, say among representatives of nations with externally antagonistic views, or peace talks among parties in the Middle East, “just us girls talking”, OTR protocols can be great ways to explore options without being held to previous statements. OTR conversations allow participants to more freely speculate about a wide range of options, which is very much in the nature of human conversation that is not formally recorded.

Preliminary conversations relating to merger and acquisitions, or collaborations, might be helped by a properly implemented "off the record" conversation. Until the concept gains general understanding and acceptance, however, it seems unlikely that such benefits will become widely used.

Separately, Forward Anonymity has a different emphasis and objective, in that the identities of the participants should not be discoverable after the fact.

Saturday, December 3, 2016

Blockchain - BitCoin - moocs

Be on lookout for developments in "FinTech" (technology implementations in finance and business transactions).  "Follow the money" - tomorrow, money being manipulated and analyzed by technology, is where it is.  Let me know if you want to talk about it.

Univ of Nicosia (classes are in English, not to worry), and first online Masters degree on BlockChain / BitCoin.

Much more than digital currency.   Next class starts in February, but youtube videos of previous class in fall of 2016 are online - link below.


http://courses.dcurr.unic.ac.cy/course/view.php?id=29

========= other resources =====

Tuesday, November 8, 2016

libvirt - why it's important

http://libvirt.org/   is a foundation stone of many virtualization capabilities and where really interesting features are being added to cloud and virtualization.

for one area,  it is where software defined storage (SDS) inserts itself, for example, ceph provides software defined storage and makes it available to OpenStack as a swift interface.   Underneath, it is not part of OpenStack but so tightly integrates with OpenStack and works underneath, that tenants will never know nor detect any difference in their access to storage.

another, VMQoS examines the QoS (quality of service) issues internal to a complex service like OpenStack.   Conventional QoS talks about external connectivity (communications QoS), but what about the internal movement of data between compute and storage (through the network linking them)?   How is that measured and what assurances can be established, and corrected when the performance deviates beyond set limits?

it can also be an interesting attack surface for malicious actors since so much depends on libvirt

Saturday, October 1, 2016

Mirantis Fuel - deploy OpenStack

Using Mirantis 7.0 from https://www.mirantis.com/software/mirantis-openstack/releases/   - use the iso image to boot a virtual server under VirtualBox.

Mirantis can then deploy OpenStack to two other virtual servers.  Once the 2 "slave" servers are deployed, you can log on to the OpenStack console (Horizon) and create virtual servers, virtual networks (switches), virtual routers, import images of other cloud servers; for example from http://cloud-images.ubuntu.com/.

After deploying, I ran 'ifconfig -a' on all three systems, and grouped where the IP addresses appeared to be on the same subnet.  Note Horizon 172.16.0.3 is not a physical interface, it's a virtual IP on the compute node (slave1).















After deploying some instances of virtual networks and servers, here is how the virtual parts align with the physical parts:






































Observe that the 172.160.0.x address that is the "associated IP" for the internal virtual server (associated / mapped to the virtual server in 192.168.111.x), is in the same routing domain and IP address subnet as they physical 172.16.0.1 address of the Fuel server, the application virtual IP accessing Horizon at 172.16.0.3, and now the IP you will use to access the virtual server created by OpenStack.