DES, 3DES and AES

Discussion:

AES is the successor of DES as standard symmetric encryption algorithm for US federal organizations. AES uses keys of 128, 192 or 256 bits, although, 128 bit keys provide sufficient strength today. It uses 128 bit blocks, and is efficient in both software and hardware implementations. It was selected through an open competition involving hundreds of cryptographers during several years.

DES is the previous “data encryption standard” from the seventies. Its key size is too short for proper security. The 56 effective bits can be brute-forced, and that has been done more than ten years ago. DES uses 64-bit blocks, which poses some potential issues when encrypting several gigabytes of data with the same key.

3DES is a way to reuse DES implementations, by chaining three instances of DES with different keys. 3DES is believed to still be secure because it requires 2^112 operations which is not achievable with foreseeable technology. 3DES is very slow especially in software implementations because DES was designed for performance in hardware.

Link: https://security.stackexchange.com/questions/26179/security-comparsion-of-3des-and-aes

 

Simple ATM program to widraw money

//simple ATM program to get widraw amount and show whether they input correct possible banknotes
#include <stdio.h>

int main(){

    int money;
    char ch;
    printf("Input your money to widraw: ");
    scanf("%d", &money);
    if((money%100)==0){
        printf("Do you want to widraw it now? (y/n):");
        getchar();
        ch = getchar();
        if(ch=='y'){
            printf("*** sucess!\n");
        }
    else{
        printf("*** fail!\n");
    }
/*
switch(ch){
case 'y':
printf("Success! you did widraw %d baht\n", money);
break;
case 'n':
printf("\nYou cancelled!\n");
break;
default:
printf("invalid input\n");
break;
}
*/
}
    else {
        printf("\nInvalid amount of money, we cannot proceed further\n");
    }

    return 0;
}

Solved: keyboard key NOT working

The easy way to solve this problem is to use hotkey e.g. if your key "n" is broken, you may use Ctrl+m to simulate lower "n" and Ctrl+shift+m to assume capital "N".

To make this done, you can use a tool called "AutoHotkey" where you can download by downloading it from the link below.
https://www.autohotkey.com/download/

After installed, you can follow the documentation.

Handle error with basic socket creation

#handling errors in python socket programs

import socket #for sockets
import sys #for exit

try:
#create an AF_INET, STREAM socket (TCP)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
except socket.error, msg:
print 'Failed to create socket. Error code: ' + str(msg[0]) + ' , Error message : ' + msg[1]
sys.exit();

print 'Socket Created'

OVN, Bringing Native Virtual Networking to OVS

By Justin Pettit, Ben Pfaff, Chris Wright, and Madhu Venugopal

Today we are excited to announce Open Virtual Network (OVN), a new project that brings virtual networking to the OVS user community. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Just like OVS, our design goal is to have a production quality implementation that can operate at significant scale.

Why are we doing this? The primary goal in developing Open vSwitch has always been to provide a production-ready low-level networking component for hypervisors that could support a diverse range of network environments. As one example of the success of this approach, Open vSwitch is the most popular choice of virtual switch in OpenStack deployments. To make OVS more effective in these environments, we believe the logical next step is to augment the low-level switching capabilities with a lightweight control plane that provides native support for common virtual networking abstractions.

To achieve these goals, OVN’s design is narrowly focused on providing L2/L3 virtual networking. This distinguishes OVN from general-purpose SDN controllers or platforms.

OVN is a new project from the Open vSwitch team to support virtual network abstraction. OVN will put users in control over cloud network resources, by allowing users to connect groups of VMs or containers into private L2 and L3 networks, quickly, programmatically, and without the need to provision VLANs or other physical network resources. OVN will include logical switches and routers, security groups, and L2/L3/L4 ACLs, implemented on top of a tunnel-based (VXLAN, NVGRE, Geneve, STT, IPsec) overlay network.

OVN aims to be sufficiently robust and scalable to support large production deployments. OVN will support the same virtual machine environments as Open vSwitch, including KVM, Xen, and the emerging port to Hyper-V. Container systems such as Docker are growing in importance but pose new challenges in scale and responsiveness, so we will work with the container community to ensure quality native support. For physical-logical network integration, OVN will implement software gateways, as well as support hardware gateways from vendors that implement the “vtep” schema that ships with OVS.

Northbound, we will work with the OpenStack community to integrate OVN via a new plugin. The OVN architecture will simplify the current Open vSwitch integration within Neutron by providing a virtual networking abstraction. OVN will provide Neutron with improved dataplane performance through shortcut, distributed logical L3 processing and in-kernel based security groups, without running special OpenStack agents on hypervisors. Lastly, it will provide a scale-out and highly available gateway solution responsible for bridging from logical into physical space.

The Open vSwitch team will build and maintain OVN under the same open source license terms as Open vSwitch, and is open to contributions from all. The outline of OVN’s design is guided by our experience developing Open vSwitch, OpenStack, and Nicira/VMware’s networking solutions. We will evolve the design and implementation in the Open vSwitch mailing lists, using the same open process used for Open vSwitch.

OVN will not require a special build of OVS or OVN-specific changes to ovs-vswitchd or ovsdb-server. OVN components will be part of the Open vSwitch source and binary distributions. OVN will integrate with existing Open vSwitch components, using established protocols such as OpenFlow and OVSDB, using an OVN agent that connects to ovs-vswitchd and ovsdb-server. (The VTEP emulator already in OVS’s “vtep” directory uses a similar architecture.)

OVN is not a generic platform or SDN controller on which applications are built. Rather, OVN will be purpose built to provide virtual networking. Because OVN will use the same interfaces as any other controller, OVS will remain as flexible and unspecialized as it is today. It will still provide the same primitives that it always has and continue to be the best software switch for any controller.

The design and implementation will occur on the ovs-dev mailing list. In fact, a high-level description of the architecture was posted this morning. If you’d like to join the effort, please check out the mailing list.

Happy switching!

Ref: https://networkheresy.com/2015/01/13/ovn-bringing-native-virtual-networking-to-ovs/