Podcasts about RC4

Play Episode Listen Later Sep 3, 2023 7:57

And, so, if you could pick one or two people who have contributed most to our online security, who would it be? Ron Rivest? Shafi Goldwasser? Ralph Merkle? Marty Hellman? Whitfield Diffie? Neal Koblitz? Well, in terms of the number of data bytes protected, that prize is likely to go to Joan Daemen and Vincent Rijmen, and who created the Rijndael method that became standardized by NIST as AES (Advanced Encryption Standard). If you are interested, Rijndael (“rain-doll”) comes from the names of its creators: Rijmen and Daemen (but don't ask me about the rogue “l” at the end). And, so, Joan Daemen was awarded the Levchin Prize at the Real World Symposium conference in 2016: Now, his co-researcher, Vincent Rijmen — a Professor at KU Leuven — has been awarded the Levchin Prize at the Real-World Crypto Symposium [here]: This follows illustrious past winners, including Paul Kocher (for work on SSL and side-channels), Dan Coppersmith (on cryptoanalysis), Neal Koblitz and Victor Miller (for their co-invention of ECC) and Ralph Merkle (for work on digital signatures and hashing trees). Vincent's track record in high-quality research work is exceptional and especially in the creation of the Rijndael approach to symmetric key encryption [here]: Before AES, we had many symmetric key encryption methods, including DES, 3DES, TwoFish, BlowFish, RC4, and CAST. But AES came along and replaced these. Overall, ChaCha20 is the only real alternative to AES, and where it is used in virtually every web connection that we have and is by far the most popular method in encrypting data. And, it has stood the test of time — with no known significant vulnerabilities in the method itself. Whilst we might use weak keys and have poor implementations, Rijndael has stood up well. AES method With AES, we use symmetric key encryption, and where Bob and Alice share the same secret key: In 2000/2001, NIST ran a competition on the next-generation symmetric key method, and Rijndael won. But in second place was Serpent, which was created by Ross Anderson, Eli Biham, and Lars Knudsen. Let's have a look at the competition and then outline an implementation of Serpent in Go lang. In the end, it was the speed of Rijndael that won over the enhanced security of Serpent. If NIST had seen security as more important, we might now be using Serpent than Rijndael for AES. NIST created the race for AES (Advanced Encryption Standard). It would be a prize that the best in the industry would join, and the winner would virtually provide the core of the industry. So, in 1997, NIST announced the open challenge for a block cipher that could support 128-bit, 192-bit, and 256-bit encryption keys. The key evaluation factors were: Security: They would rate the actual security of the method against the others submitted. This would method the entropy in the ciphertext — and show that it was random for a range of input data. The mathematical foundation of the method. A public evaluation of the methods and associated attacks. Cost: The method would provide a non-exclusive, royalty-free basis licence across the world; It would be computationally and memory efficient. Algorithm and implementation characteristics: It would be flexible in its approach, and possibly offer different block sizes, key sizes, convertible into a stream cipher, and so on. Be ready for both hardware and software implementation for a range of platforms. Be simple to implement. Round 1 The call was issued on 12 Sept 1997 with a deadline of June 1998, and a range of leading industry players rushed to either create methods or polish down their existing ones. NIST announced the shortlist of candidates at a conference in August 1998, and which included some of the key leaders in the field, such as Ron Rivest, Bruce Schneier, and Ross Anderson (University of Cambridge) [report]: Australia LOKI97 (Lawrie Brown, Josef Pieprzyk, Jennifer Seberry). Belgium RIJNDAEL (Joan Daemen, Vincent Rijmen). Canada: CAST-256 (Entrust Technologies, Inc), DEAL (Richard Outerbridge, Lars Knudsen). Costa Rica FROG (TecApro Internacional S.A.). France DFC (Centre National pour la Recherche Scientifique). Germany MAGENTA (Deutsche Telekom AG). Japan E2 (Nippon Telegraph and Telephone Corporation) Korea CRYPTON (Future Systems, Inc.) USA: HPC (Rich Schroeppel), MARS IBM, RC6(TM) RSA Laboratories [try here], SAFER+ Cylink Corporation, TWOFISH (Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson) [try here]. UK, Israel, Norway SERPENT (Ross Anderson, Eli Biham, Lars Knudsen). One country, the USA, had five short-listed candidates, and Canada has two. The odds were thus on the USA to come through in the end and define the standard. The event, too, was a meeting of the stars of the industry. Ron Rivest outlined that RC6 was based on RC5 but highlighted its simplicity, speed, and security. Bruce Schneier outlined that TWOFISH had taken a performance-driven approach to its design, and Eli Biham outlined that SERPENT and taken an ultra-conservative philosophy for security in order for it to be secure for decades. Round 2 And so the second conference was arranged for 23 March 1999, after which, on 9 August 1999, the five AES finalists were announced: Belgium RIJNDAEL (Joan Daemen, Vincent Rijmen). USA: MARS IBM, RC6(TM) RSA Laboratories, TWOFISH (Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson) UK, Israel, Norway SERPENT (Ross Anderson, Eli Biham, Lars Knudsen). Canada: CAST-256 (Entrust Technologies, Inc), The big hitters were now together in the final, and the money was on them winning through. Ron Rivest, Ross Anderson and Bruce Schiener all made it through, and with half of the candidates being sourced from the USA, the money was on MARS, TWOFISH or RC6 winning the coveted prize. While the UK and Canada both had a strong track record in the field, it was the nation of Belgium that surprised some and had now pushed itself into the final [here]. While the other cryptography methods which tripped off the tongue, the RIJNDAEL method took a bit of getting used to, with its name coming from the surnames of the creators: Vincent Rijmen and Joan Daemen. Ron Rivest — the co-creator of RSA, had a long track record of producing industry-standard symmetric key methods, including RC2, and RC5, along with creating one of the most widely used stream cipher methods: RC4. His name was on standard hashing methods too, including MD2, MD4, MD5, and MD6. Bruce Schneier, too, was one of the stars of the industry, with a long track record of creating useful methods, including TWOFISH and BLOWFISH. Final After nearly two years of review, NIST opened up to comments on the method, which ran until May 2000. A number of submissions were taken, and the finalist seemed to be free from attacks, with only a few simplified method attacks being possible: Table 1: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4863838/ As we can see in Table 1, the methods had different numbers of rounds: 16 (Twofish), 32 (Serpent), 10, 12, or 14 (Rijndael), 20 (RC6), and 16 (MARS). Rijndael had a different number of rounds for different key sizes, with 10 rounds for 128-bit keys and 14 for 256-bit keys. Its reduced number of rounds made it a strong candidate for being a winner. In the AES conference to decide the winner, Rijndael received 86 votes, Serpent got 59 votes, Twofish 31 votes, RC6 23 votes, and MARS 13 votes. Although Rijndael and Serpent were similar, and where both used S-boxes, Rijndael had fewer rounds and was faster, but Serpent had better security. The NIST scoring was: Conclusions AES has advanced cybersecurity more that virtually all the other methods put together. Without it, the Internet would be a rats-nest of spying, person-in-the-middle attacks, and, would be a complete mess.

Bill Buchanan - A Bluffer's Guide To Encryption In The Cloud: Top 100

Play Episode Listen Later Aug 21, 2023 20:55

In cybersecurity, the teaching of Cloud security is often weak. So, here are my Top 100 things about encryption in the Cloud. I've focused on AWS, but Azure is likely to also be applicable. Keys are created in the AWS KMS (Key Management Store). In Azure, this is named KeyVault. The cost of using a key in KMS is around $1/month (prorated hourly). When a key is disabled, it is not charged. With AWS KMS, we use a shared customer HSM (Hardware Security Module), and with AWS CloudHSM it is dedidated to one customer. For data at rest, with file storage, we can integrate encryption with Amazon EBS (Elastic Block Storage) and Amazon S3. Amazon EBS drives are encrypted with AES-256 with XTS mode. For AWS-managed keys, a unique key is used for every object within S3 buckets. Amazon S3 uses server-side encryption to store encrypted data. The customer can use client-side encryption to encrypt data before it is stored in the AWS infrastructure. AWS uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) for its symmetric key encryption. In AWS S3, by default, all the objects are encrypted. A customer can use client-side encryption to encrypt data before it goes into the AWS infrastructure. For data at rest, for databases, we can integrate encryption with Amazon RDS (AWS's relational database service) and Amazon Redshift (AWS's data warehousing). For data at rest, we can integrate encryption into ElastiCache (AWS's content caching service), AWS Lambda (AWS's serverless computing service), and Amazon SageMake (AWS's machine learning service). Keys are tokenized and have an ARN (Amazon Resource Names) and alias. An example ARN for a key is arn:aws:kms:us-east-1:103269750866:key/de30e8e6-c753–4a2c-881a-53c761242644, and an example alias is “Bill's Key”. Both of these should be unique in the user's account. To define a KMS key, we can either use its key ID, its key ARN, its alias name, or alias ARN. You can link keys to other AWS Accounts. For this, we specify in the form of “arn:aws:iam::[AWS ID]:root”, and where AWS ID is the ID of the other AWS account. To enhance security, we can use AWS CloudHSM (Hardware Security Module). For simpler and less costly solutions, we typically use AWS KMS (Key Management Solution). For CloudHSM, we pay per hour, but for KMS, we just pay for the usage of the keys. The application of the keys is restricted to defined services. Key identifiers and policies are defined with a JSON key-value pair for data objects. Each key should have a unique GUID, such as “de30e8e6-c753–4a2c-881a-53c761242644”. Users are identified and roles are identified with an ARN, such as : “arn:aws:iam::222222:root”. With the usage of keys we have Key Administrative Permission and a Key Usage policies. There is an explicit denial on a policy if there is not a specific allow defined in a policy. For key permissions, we have fields of “Sid” (the descriptive name of the policy), “Effect” (typically “Allow”), Principal (the ARN of the user/group), “Action” (such as Create, Disable and Delete) and “Resource”. A wildcard (“*”) allows or disallows all. To enable a user of “root” access to everything with a key would be : “Sid”: “Enable IAM User Permissions”, “Effect”: “Allow”,“Principal”: {“AWS”: “arn:aws:iam::22222222:root”},“Action”: “kms:*”, “Resource”: “*”}. The main operations within the KMS are to encrypt/decrpyt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes). Key are either AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer). Custom key stores are where the customer has complete control over the keys). The main use of keys are for EC2 (Compute), EBS (Elastic Block Storage) and S3 (Storage). AES symmetric keys or an RSA key pair are used to encrypt and decrypt. RSA uses 2K, 3K or 4K keys, and with either “RSA PCKS1 v1.5” or “RSA PSS” padding. RSA PCKS1 v1.5 padding is susceptible to Bleichenbacher's attack, so it should only be used for legacy applications, and for all others, we should use RSA PSS. For RSA, we can use a hashing method of SHA-256, SHA-384 or SHA-512. In RSA, we encrypt with the public key and decrypt with the private key. For signatures, we can use either RSA or ECC signing. For RSA, we have 2K, 3K, or 4K keys, whereas ECC signing uses NIST P256, NIST P384, NIST P521, and SECG P256k1 (as used in Bitcoin and Ethereum). For MACs (Message Authentication Codes), Bob and Alice have the same shared secret key and can authenticate the hash version of a message. In the KMS, we can have HMAC-224, HMAC-256, HMAC-384 and HMAC-512. KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer). Keys will never appear in an AWS disk or backup, and only existing the memory of the HSM. They are only loaded when used. Encryption keys can be restricted to one region of the world (unless defined by the user). With symmetric keys, the key never appears outside the HSM, and for asymmetric keys (public key encryption), the private key stays inside the HSM, and only the public key is exported outside. AWS CloudWatch shows how and when the encryption keys are being used. The minimum time that can be set for a key to be deleted is seven days (and up to 30 days maximum). An organisation can also create its own HSM with the CloudHSM cluster. When a key is then created in KMS, it is then stored in the cluster. The usage of encryption keys should be limited to a minimal set of service requirements. If possible, separate key managers and key users. With a key management (KEY_ADMINISTRATOR) role, we typically have the rights to create, revoke, put, get, list and disable keys. The key management role will typically not be able to encrypt and decrypt. For a key user (KEY_WORKER) role, we cannot create or delete keys and typically focus on tasks such as encrypting and decrypting. Hae a rule of minimum access rights, and simplify user access by defining key administration and usage roles. Users are then added to these roles. Avoid manual updates to keys and use key rotation. The system keeps track of keys that are rotated and can use previously defined ones. The default time to rotate keys is once every year. Key rotation shows up in the CloudWatch and CloudTrail logs. KMS complies with PCI DSS Level 1, FIPS 140–2, FedRAMP, and HIPAA. AWS KMS is matched to FIPS 140–2 Level 2. AWS CloudHSM complies with FIPS 140–2 Level 3 validated HSMs. AWS CloudHSM costs around $1.45 per hour to run, and the costs end when it is disabled or deleted. The CloudHSM is backed-up every 24 hours, and where we can cluster the HSMs into a single logical HSM. CloudHSM can be replicated in AWS regions. AWS KSM is limited to the popular encryption methods, whereas the CloudHSM can implement a wider range of methods. The CloudHSM can support methods such as 3DES with AWS Payment Cryptography. This complies with payment card industry (PCI) standards, such as PCI PIN, PCI P2PE, and PCI DSS. In the CloudHSM for payments, we can generate CVV, CVV2 and ARQC values, and where sensitive details never exist outside the HSM in an unprotected form. With the CloudHSM, we have a command line interface where we can issue commands, and is named CloudHSM CLI. Within the CloudHSM CLI, we can use the genSymKey command to generate symmetric key within the HSM, such as where -t is a key type (31 is AES), -s is a key size (32 bytes) and -l is the label: genSymKey -t 31 -s 32 -l aes256 With genSymKey the key types are: 16 (Generic Secret), 18 (RC4), 21 (Triple DES), and 31 (AES). Within the CloudHSM CLI, we can use the genRSAKeyPair command to generate an RSA key pair, such as where -m is the modulus and -e is the public exponent: genRSAKeyPair -m 2048 -e 65537 -l mykey AWS CloudHSM is integrated with AWS CloudTrail, and where we can track user, role, or an AWS service within AWS CloudHSM. With AWS Payments Cryptography, the 2KEY TDES is Two-key Triple DES and has a 112-bit equivalent key size. The Pin Encryption Key (PEK) is used to encryption PIN values and uses a KEY TDES key. This can store PINs in a secure way, and then decrypt them when required. S3 buckets can be encrypted either with Amazon S3-managed keys (SSE-S3) or AWS Key Management Service (AWS KMS) keys. There is no cost to use SSE keys. For symmetric key encryption, AWS uses envelope encryption, and where a random key is used to encrypt data, and then the key is encrypted with the user's key. AWS should not be able to access the key used for the encryption. The default in creating an encryption key is for it only be to used in a single region, but this can be changed to multi-region, and where the key will be replicated across more than one region. In AWS, a region is a geographical area, and which is split into isolated locations. US-East-1 (N.Virginia) and US-East-2 (Ohio) are different regions, while us-east-1a, us-east-1b and us-east-1c are in the same region. A single region key the US-East-1 region would replicate across eu-east-1a, eu-east-1b and eu-east-1c, and not to eu-east-2a, eu-east-2b and eu-east-2c. When creating a key, you can either create in the KMS, import a key (BYOK — bring your own key), create in the AWS CloudHSM, or create in an external key store (HYOK — hold you own key). For keys stored on-premise we can use an external key store (XKS) — this can be defined as Hold Your Own Keys (HYOKs), and where and where no entity in AWS will able to read any of the encrypted data. [here]. You can BYOK (bring your own key) with KMS, and import keys. KMS will keep a copy of this key. With XKS, we need a proxy URI endpoint, with the proxy credentials of an access key ID, and secret access key. To export keys from AWS CloudHSM, we can encrypt them with an AES key. This is known as key wrapping, as defined in RFC 5648 (for padding with zeros) or RFC 3394 (without padding). A strong password should always be used for key wrapping. AWS encryption operations can either be conducted from the command line or within API, such as with Python, Node.js or Golang. With KMS, the maximum data size is 4,096 bytes for a symmetric key, 190 bytes for RSA 2048 OAEP SHA-256, 318 bytes for RSA 3072 OAEP SHA-256, ad 446 bytes for RSA 4096 OAEP SHA-256. An example command to encrypt a file for 1.txt with symmetric key encryption is: aws kms encryp --key-id alias/MySymKey --plaintext fileb://1.txt --query CiphertextBlob --output text > 1.out To decrypt a file with symmetric key encryption, an example with 1.enc is: aws kms decrypt --key-id alias/BillsNewKey --output text --query Plaintext --ciphertext-blob fileb://1.enc > 2.out In Python, to integrate with KMS, we use the Boto3 library. The standard output of encrypted content is in byte format. If we need to have a text version of ciphertext, we typically use Base64 format. The base64 command can be used to convert byte format in Base64, such as with: $ base64 -i 1.out — decode > 1.enc The xxd command in the command line allows the cipher text to be dumped to a hex output and can then be edited. We can then convert it back to a binary output with: An example piece of Python code for encrypting a plaintext message with the symmetric key in Python is: ciphertext = kms_client.encrypt(KeyId=alias,Plaintext=bytes(secret, encoding='utf8') An example piece of Python code to decrypt some cipher text (in Base64 format) is: plain_text = kms_client.decrypt(KeyId=alias,CiphertextBlob=bytes(base64.b64decode(ciphertext))) To generate an HMAC signature for a message in the command line, we have the form of: aws kms generate-mac --key-id alias/MyHMACKey --message fileb://1.txt --mac-algorithm HMAC_SHA_256 --query Mac > 4.out To verify an HMAC signature for a message in the command line, we have the form of: aws kms verify-mac -key-id alias/MyHMACKey -message fileb://1.txt -mac-algorithm HMAC_SHA_256 -mac fileb://4.mac To create an ECDSA signature in the command line, we have the form of: aws kms sign -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signing-algorithm ECDSA_SHA_256 -query Signature > 1.out To verify an ECDSA signature in the command line, we have the form of: aws kms verify -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signature fileb://1.sig -signing-algorithm ECDSA_SHA_256 To encrypt data using RSA in the command line, we have the form of: aws kms encrypt -key-id alias/PublicKeyForDemo -plaintext fileb://1.txt -query CiphertextBlob -output text -encryption-algorithm RSAES_OAEP_SHA_1 > 1.out To decrypt data using RSA in the command line, we have the form of: aws kms decryptb -key-id alias/PublicKeyForDemo -output text -query Plaintext -ciphertext-blob fileb://1.enc -encryption-algorithm RSAES_OAEP_SHA_1 > 2.out To sign data using RSA in the command line, we have the form of: aws kms sign --key-id alias/MyRSAKey --message fileb://1.txt --signing-algorithm RSASSA_PSS_SHA_256 --query Signature --output text > 1.out To verify data using RSA in the command line, we have the form of: aws kms verify --key-id alias/MyRSAKey --message fileb://1.txt — signature fileb://1.sig --signing-algorithm RSASSA_PSS_SHA_256 You cannot encrypt data with Elliptic Curve keys. Only RSA and AES can do that. Elliptic Curve keys are used to sign data. If you delete an encryption key, you will not be able to decrypt any ciphertext that uses it. We can store our secrets, such as application passwords, in the secrets manager. An example of a secret name of “my-secret-passphrase” and a secret string of “Qwery123” we can have: aws secretsmanager create-secret --name my-secret-passphrase --secret-string Qwerty123 In China regions, along with RSA and ECDSA, you can use SM2 KMS signing keys. In China Regions, we can use SM2PKE to encrypt data with asymmetric key encryption. Find out more here: https://asecuritysite.com/aws

guide action ohio keys bitcoin cloud mac id principal cybersecurity resource users api ethereum signature python 4k aws top100 azure pin buchanan 2k sha pins hipaa cloud computing s3 rsa node encryption uri lambda arn ecc pci aes 3k cryptography json guid rfc hsm disable sse kms golang amazon s3 pci dss hae cvv fips fedramp plain text us east cloudwatch base64 ecdsa key worker rc4 hmac xts aws cloudtrail 3des aws accounts aws cloudhsm

Bill Buchanan - 100 Interesting Things to Learn About Cryptography

Play Episode Listen Later Aug 17, 2023 31:13

Here are my 100 interesting things to learn about cryptography: For a 128-bit encryption key, there are 340 billion billion billion billion possible keys. [Calc: 2**128/(1e9**4)] For a 256-bit encryption key, there are 115,792 billion billion billion billion billion billion billion billion possible keys. [Calc: 2**256/(1e9**8)] To crack a 128-bit encryption with brute force using a cracker running at 1 Teracracks/second, will take — on average — 5 million million million years to crack. Tera is 1,000 billion. [Calc: 2**128/100e9/2/60/60/24/365/(1e6**3)] For a 256-bit key this is 1,835 million million million million million million million million million years. For the brute force cracking of a 35-bit key symmetric key (such as AES), you only need to pay for the boiling of a teaspoon of energy. For a 50-bit key, you just need to have enough money to pay to boil the water for a shower. For a 90-bit symmetric key, you would need the energy to boil a sea, and for a 105-bit symmetric key, you need the energy to boil and ocean. For a 128-bit key, there just isn't enough water on the planet to boil for that. Ref: here. With symmetric key encryption, anything below 72 bits is relatively inexpensive to crack with brute force. One of the first symmetric key encryption methods was the LUCIFER cipher and was created by Horst Feistel at IBM. It was further developed into the DES encryption method. Many, at the time of the adoption of DES, felt that its 56-bit key was too small to be secure and that the NSA had a role in limiting them. With a block cipher, we only have to deal with a fixed size of blocks. DES and 3DES use a 64-bit (eight-byte) block size, and AES uses a 128-bit block size (16 bytes). With symmetric key methods, we either have block ciphers, such as DES, AES CBC and AES ECB, or stream ciphers, such as ChaCha20 and RC4. In order to enhance security, AES has a number of rounds where parts of the key are applied. With 128-bit AES we have 10 rounds, and 14 rounds for 256-bit AES. In AES, we use an S-box to scramble the bytes, and which is applied for each round. When decrypting, we have the inverse of the S-box used in the encrypting process. A salt/nonce or Initialisation Vector (IV) is used with an encryption key in order to change the ciphertext for the same given input. Stream ciphers are generally much faster than block cipers, and can generally be processed in parallel. With the Diffie-Hellman method. Bob creates x and shares g^x (mod p), and Alice creates y, and shares g^y (mod p). The shared key is g^{xy} (mod p). Ralph Merkle — the boy genius — submitted a patent on 5 Sept 1979 and which outlined the Merkle hash. This is used to create a block hash. Ralph Merkle's PhD supervisor was Martin Hellman (famous as the co-creator of the Diffie-Hellman method). Adi Shamir defines a secret share method, and which defines a mathematical equation with the sharing of (x,y), and where a constant value in the equation is the secret. With Shamir Secret Shares (SSS), for a quadratic equation of y=x²+5x+6, the secret is 6. We can share three points at x=1, x=2 and y=3, and which gives y=12, y=20, and y=20, respectively. With the points of (1,12), (2,20), and (3,20), we can recover the value of 6. Adi Shamir broke the Merkle-Hellman knapsack method at a live event at a rump session of a conference. With secret shares, with the highest polynomial power of n, we need n+1 points to come together to regenerate the secret. For example, y=2x+5 needs two points to come together, while y=x²+15x+4 needs three points. The first usable public key method was RSA — and created by Rivest, Shamir and Adleman. It was first published in 1979 and defined in the RSA patent entitled “Cryptographic Communications System and Method”. In public key encryption, we use the public key to encrypt data and the private key to decrypt it. In digital signing, we use the private key to sign a hash and create a digital signature, and then the associated public key to verify the signature. Len Adleman — the “A” in the RSA method — thought that the RSA paper would be one of the least significant papers he would ever publish. The RSA method came to Ron Rivest while he slept on a couch. Martin Gardner published information on the RSA method in his Scientific American article. Initially, there were 4,000 requests for the paper (which rose to 7,000), and it took until December 1977 for them to be posted. The security of RSA is based on the multiplication of two random prime numbers (p and q) to give a public modulus (N). The difficulty of RSA is the difficulty in factorizing this modulus. Once factorized, it is easy to decrypt a ciphertext that has been encrypted using the related modulus. In RSA, we have a public key of (e,N) and a private key of (d,N). e is the public exponent and d is the private exponent. The public exponent is normally set at 65,537. The binary value of 65,537 is 10000000000000001 — this number is efficient in producing ciphertext in RSA. In RSA, the ciphertext is computed from a message of M as C=M^e (mod N), and is decrypted with M=C^d (mod N). We compute the the private exponent (d) from the inverse of the public exponent (e) modulus PHI, and where PHI is (p-1)*(q-1). If we can determine p and q, we can compute PHI. Anything below a 738-bit public modulus is relatively inexpensive to crack for RSA. To crack 2K RSA at the current time, we would need the energy to boil ever ocean on the planet to break it. RSA requires padding is required for security. A popular method has been PCKS#1v1.5 — but this is not provably secure and is susceptible to Bleichenbacher's attack. An improved method is Optimal Asymmetric Encryption Padding (OAEP) and was defined by Bellare and Rogaway and standardized in PKCS#1 v2. The main entity contained in a digital certificate is the public key of a named entity. This is either an RSA or an Elliptic Curve key. A digital certificate is signed with the private key of a trusted entity — Trent. The public key of Trent is then used to prove the integrity and trust of the associated public key. For an elliptic curve of y²=x³+ax+b (mod p), not every (x,y) point is possible. The total number of points is defined as the order (n). ECC (Elliptic Curve Cryptography) was invented by Neal Koblitz and Victor S. Miller in 1985. Elliptic curve cryptography algorithms did not take off until 2004. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A “04” in the public key is an uncompressed public key, and “02” and “03” are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even. Satoshi selected the secp256k1 curve for Bitcoin, and which gives the equivalent of 128-bit security. The secp256k1 curve uses the mapping of y²=x³ + 7 (mod p), and is known as a Short Weierstrass (“Vier-strass”) curve. The prime number used with secp256k1 is 2²⁵⁶-2³²-2⁹-2⁸-2⁷-2⁶-2⁴-1. An uncompressed secp256k1 public key has 512 bits and is an (x,y) point on the curve. The point starts with a “04”. A compressed secp256k1 public key only stores the x-co-ordinate value and whether the y coordinate is odd or even. It starts with a “02” if the y-co-ordinate is even; otherwise, it starts with a “03”. In computing the public key in ECC of a.G, we use the Montgomery multiplication method and which was created by Peter Montgomery in 1985, in a paper entitled, “Modular Multiplication without Trial Division.” Elliptic Curve methods use two basic operations: point address (P+Q) and point doubling (2.P). These can be combined to provide the scalar operation of a.G. In 1999, Don Johnson Alfred Menezes published a classic paper on “The Elliptic Curve Digital Signature Algorithm (ECDSA)”. It was based on the DSA (Digital Signature Algorithm) — created by David W. Kravitz in a patent which was assigned to the US. ECDSA is a digital signature method and requires a random nonce value (k), and which should never be reused or repeated. ECDSA is an elliptic curve conversion of the DSA signature method. Digital signatures are defined in FIPS (Federal Information Processing Standard) 186–5. NIST approved the Rijndael method (led by Joan Daemen and Vincent Rijmen) for Advanced Encryption Standard (AES). Other contenders included Serpent (led by Ross Anderson), TwoFish (led by Bruce Schneier), MARS (led by IBM), and RC6 (led by Ron Rivest). ChaCha20 is a stream cipher that is based on Salsa20 and developed by Daniel J. Bernstein. MD5 has a 128-bit hash, SHA-1 has 160 bits and SHA-256 has 256-bits. It is relatively easy to create a hash collision with MD5. Google showed that it was possible to create a signature collision for a document with SHA-1. It is highly unlikely to get a hash collision for SHA-256. In 2015, NIST defined SHA-3 as a standard, and which was built on the Keccak hashing family — and which used a different method to SHA-2. The Keccak hash family uses a sponge function and was created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche and standardized by NIST in August 2015 as SHA-3. Hash functions such as MD5, SHA-1 and SHA-256 have a fixed hash length, whereas an eXtendable-Output Function (XOF) produces a bit string that can be of any length. Examples are SHAKE128, SHAKE256, BLAKE2XB and BLAKE2XS. BLAKE 3 is the fastest cryptographically secure hashing method and was created by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn. Hashing methods can be slowed down with a number of rounds. These slower hashing methods include Bcrypt, PBKDF2 and scrypt. Argon 2 uses methods to try and break GPU cracking, such as using a given amount of memory and defining the CPU utlization. To speed up the operation of the SHA-3 hash, the team reduced the security of the method and reduce the number of rounds. The result is the 12 Kangaroo's hashing method. The number of rounds was reduced from 24 to 12 (with a security level of around 128 bits). Integrated Encryption Scheme (IES) is a hybrid encryption scheme which allows Alice to get Bob's public key and then generate an encryption key based on this public key, and she will use her private key to recover the symmetric. With ECIES, we use elliptic curve methods for the public key part. A MAC (Message Authentication Code) uses a symmetric key to sign a hash, and where Bob and Alice share the same secret key. The most popular method is HMAC (hash-based message authentication code). The AES block cipher can be converted into a stream cipher using modes such as GCM (Galois Counter Mode) and CCM (counter with cipher block chaining message authentication code; counter with CBC-MAC). A MAC is added to a symmetric key method in order to stop the ciphertext from being attacked by flipping bits. GCM does not have a MAC, and is thus susceptible to this attack. CCM is more secure, as it contains a MAC. With symmetric key encryption, we must remove the encryption keys in the reverse order they were applied. Commutative encryption overcomes this by allowing the keys to be removed in any order. It is estimated that Bitcoin miners consume 17.05 GW of electrical power per day and 149.46 TWh per year. A KDF (Key Derivation Function) is used to convert a passphrase or secret into an encryption key. The most popular methods are HKDF, PBKDF2 and Bcrypt. RSA, ECC and Discrete Log methods will all be cracked by quantum computers using Shor's algorithm Lattice methods represent bit values as polynomial values, such as 1001 is x³+1 as a polynomial. Taher Elgamal — the sole inventor of the ElGamal encryption method — and Paul Koche were the creators of SSL, and developed it for the Netscape browser. David Chaum is considered as a founder of electronic payments and, in 1983, created ECASH, along with publishing a paper on “Blind signatures for untraceable payments”. Satoshi Nakamoto worked with Hal Finney on the first versions of Bitcoin, and which were created for a Microsoft Windows environment. Blockchains can either be permissioned (requiring rights to access the blockchain) or permissionless (open to anyone to use). Bitcoin and Ethereum are the two most popular permissionless blockchains, and Hyperledger is the most popular permissioned ledger. In 1992, Eric Hughes, Timothy May, and John Gilmore set up the cypherpunk movement and defined, “We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.” In Bitcoin and Ethereum, a private key (x) is converted to a public key with x.G, and where G is the base point on the secp256k1 curve. Ethereum was first conceived in 2013 by Vitalik Buterin, Gavin Wood, Charles Hoskinson, Anthony Di Iorio and Joseph Lubin. It introduced smaller blocks, improved proof of work, and smart contracts. NI-ZKPs involves a prover (Peggy), a verifier (Victor) and a witness (Wendy) and were first defined by Manuel Blum, Paul Feldman, and Silvio Micali in their paper entitled “Non-interactive zero-knowledge and its applications”. Popular ZKP methods include ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and ZK-STARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge). Bitcoin and Ethereum are pseudo-anonymised, and where the sender and recipient of a transaction, and its value, can be traced. Privacy coins enable anonymous transactions. These include Zcash and Monero. In 1992, David Chaum and Torben Pryds Pedersen published “Wallet databases with observers,” and outlined a method of shielding the details of a monetary transaction. In 1992, Adi Shamir (the “S” in RSA) published a paper on “How to share a secret” in the Communications of the ACM. This supported the splitting of a secret into a number of shares (n) and where a threshold value (t) could be defined for the minimum number of shares that need to be brought back together to reveal the secret. These are known as Shamir Secret Shares (SSS). In 1991, Torbin P Pedersen published a paper entitled “Non-interactive and information-theoretic secure verifiable secret sharing” — and which is now known as Pedersen Commitment. This is where we produce our commitment and then show the message that matches the commitment. Distributed Key Generation (DKG) methods allow a private key to be shared by a number of trusted nodes. These nodes can then sign for a part of the ECDSA signature by producing a partial signature with these shares of the key. Not all blockchains use ECDSA. The IOTA blockchain uses the EdDSA signature, and which uses Curve 25519. This is a more lightweight signature version and has better support for signature aggregation. It uses Twisted Edwards Curves. The core signing method used in EdDSA is based on the Schnorr signature scheme and which was created by Claus Schnorr in 1989. This was patented as a “Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system”. The patent ran out in 2008. Curve 25519 uses the prime number of 2²⁵⁵-19 and was created by Daniel J. Bernstein. Peter Shor defined that elliptic curve methods can be broken with quantum computers. To overcome the cracking of the ECDSA signature from quantum computers, NIST are standardising a number of methods. At present, this focuses on CRYSTALS-Dilithium, and which is a lattice cryptography method. Bulletproofs were created in 2017 by Stanford's Applied Cryptography Group (ACG). They define a zero-knowledge proof as where a value can be checked to see it lies within a given range. The name “bulletproofs” is defined as they are short, like a bullet, and with bulletproof security assumptions. Homomorphic encryption methods allow for the processing of encrypted values using arithmetic operations. A public key is used to encrypt the data, and which can then be processed using an arithmetic circuit on the encrypted data. The owner of the associated private key can then decrypt the result. Some traditional public key methods enable partial homomorphic encryption. RSA and ElGamal allow for multiplication and division, whilst Pailier allows for homomorphic addition and subtraction. Full homomorphic encryption (FHE) supports all of the arithmetic operations and includes Fan-Vercauteren (FV) and BFV (Brakerski/Fan-Vercauteren) for integer operations and HEAAN (Homomorphic Encryption for Arithmetic of Approximate Numbers) for floating point operations. Most of the Full Homomorphic encryption methods use lattice cryptography. Some blockchain applications use Barreto-Lynn-Scott (BLS) curves which are pairing-friendly. They can be used to implement Bilinear groups and which are a triplet of groups (G1, G2 and GT), so that we can implement a function e() such that e(g1^x,g2^y)=gT^{xy}. Pairing-based cryptography is used in ZKPs. The main BLS curves used are BLS12–381, BLS12–446, BLS12–455, BLS12–638 and BLS24–477. An accumulator can be used for zero-knowledge proof of knowledge, such as using a BLS curve to create to add and remove proof of knowledge. Metamask is one of the most widely used blockchain wallets and can integrate into many blockchains. Most wallets generate the seed from the operating system and where the browser can use the Crypto.getRandomValues function, and compatible with most browsers. With a Verifiable Delay Function (VDF), we can prove that a given amount of work has been done by a prover (Peggy). A verifier (Victor) can then send the prover a proof value and compute a result which verifies the work has been done, with the verifier not needing to do the work but can still prove the work has been done. A Physical Unclonable Functions (PUFs) is a one-way function which creates a unique signature pattern based on the inherent delays within the wires and transistors. This can be used to link a device to an NFT.

google phd digital mars bitcoin nfts blind crypto mac stanford method blockchain stream privacy ibm montgomery ethereum lucifer serpent wallet curve nsa micha kangaroos bulletproof gt buchanan gw scientific american cm cpu pairing sha gpu hash rsa phi ref g1 dsa satoshi ccm nist g2 ssl satoshi nakamoto acm ecc aes microsoft windows cryptography netscape iota monero vitalik buterin metamask bls lattice arithmetic peeters shamir merkle zcash shor hashing argon bruce schneier cypherpunk interesting things hyperledger calc charles hoskinson gcm elliptic twh hal finney ross anderson gavin wood md5 m c schnorr rivest john gilmore fhe ecash joseph lubin david chaum martin gardner eric hughes anthony di iorio ecdsa peter montgomery rc4 diffie hellman silvio micali bcrypt hmac martin hellman peter shor pkcs pbkdf2 3des bilinear

Bill Buchanan - The 100 Basic Rules of Cryptography (and Secure Programming)

Play Episode Listen Later Aug 10, 2023 14:43

Kerckhoff's principle defines that “a Cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known”, but there aren't too many other rules defined. So here are my 100 Basic Rules of Cryptography (and Secure Programming). First, my Top 10: Cryptography is both an art and a science. Cryptography needs to be both theoretical and practical — one without the other leaves gaps. The maths is not actually that difficult — it is just the way that researchers talk about it that is a problem. Know your knowledge gaps — and plug them. Your university education is unlikely to have properly set you up for the serious world of cryptography. Crypto is cryptography and not cryptocurrency. Few methods are perfect — know the limits of any method you use. Don't cook your own crypto! How many times do you have to say this to yourself? Security-by-obfuscation never works that well. Confidentiality, Integrity and Assurance are different things and require different methods. Don't merge them all together into one thing. And the rest: Digital certificates and PKI (Public Key Infrastructure) are two of the least understood areas of cybersecurity — don't expect many people to understand them. For public key encryption, you encrypt with Alice's public key, and she decrypts with her private key. For public key signatures, you sign a hash of the message with your private key, and Alice proves your public key. Your baseline hack is always brute force. Know how many dollars it would cost the NSA to crack something. Machine code can reveal your secrets. A hack of one key should not lead to the loss of all the previous keys. A key should only exist for the time it was meant to exist for. Use session keys wherever possible, and watch out for long-term keys. Your role is typically to protect the user and not reveal things to the NSA. Listen to experts, and be a teacher to others. Be open with your knowledge, and don't pretend you know something that you don't. Try and understand the basics of the maths involved — otherwise, you are trusting others. Understand entropy, and know how to calculate it and prove it with experiments. Run entropy calculations before pushing related code to production. Don't use a method unless it has been peer-reviewed and published. Understand the strengths and weaknesses of your methods. No method is perfect —but at least know what problems it might cause and try and mitigate against these. Know why you have chosen X over Y, and be able to defend the reason to others. The maths may be sound, but human is typically the main weakness. Everything will work fine until it doesn't. Test for out-of-band conditions as much for good conditions. Zero is not your friend in cryptography, so always know what it will do to your system. Don't just catch exceptions; action them. Do not allow to progress unless everything checks out okay. Log good and bad. Catch good things, along with bad things. Monitor your security logs for exceptions and bad operations. Remove debugging code from your production version. Keep up to date with the latest research. Beware of backdoors in methods and code. Side channels are smart ways to reveal the 1s and 0s, and every bit discovered reduces the security level by two and makes it so much less expensive to crack. Every bit drops the price tag for a crack by a half. The core security of your system is likely to depend on the generation of random oracles (seed values). Make sure they are generated so they do not repeat within a given time and cannot be brute forced by the NSA. If you can use real randomisation and not pseudo-randomness. If you generate pseudo-randomness, take the randomness from several sources. Continually review your code, and get external experts to review it. Don't push your code in production until you have tested it — fully! Check the code in the libraries you use, and perhaps, don't use them if there are no open-source repositories. If you can, open source your libraries. Watch out for version updates on your code, and try and lock a given (known) version to your code. Encrypt anything that looks like PII (Personally Identifiable Information) at rest and over the air. Remember that running memory can reveal keys and cryptographic artefacts, so know the risk. Learn a new method every day, and don't get stuck with the same old crypto! Quantum computers will happen one day and will disrupt our life, so start thinking about the impact they might have. Revealing your private keys is like giving someone the keys to your castle, so know where they are and restrict access to them. Only give access to private keys to those you most trust to use them properly. Air your development environment from your production environment, and don't let private keys propagate. The best systems use zero trust. No rights to anything unless they can be proven. You will — at times — need to revoke your public keys. Be aware of the processes involved and of the embarrassment it will cause. Educate the board on the importance of good crypto! Encourage your team to undertake academic study, and get them to reserve a few hours a week for independent study of new methods. Read classic research papers, and don't dismiss methods because they are not currently used. Collaborate with an academic team which has complementary skills to your own team. If you lack theoretical knowledge in your team, get external experts to come in for a chat. Once a private key is destroyed, any data encrypted with it is also likely to be destroyed. Limit the copies of a secret key. If you can, keep your keys in an HSM (Hardware Security Module). Cryptography in the Cloud pushes you to the limits and will often enhance the methods you use. Back up those secret keys, but make sure they are well-wrapped before putting them in a place that others can access. Learn about the garbage collector and how your program deals with data when running. Leave the coding of the maths in papers to experts. Don't trust auditors to prove the security of your system. Generally, auditors are likely to have little understanding of the methods you will use — get experts to review your methods. Beware of Denial of Service (DoS) on your code — such as continual exception handling. Most systems boil down to one single thing that defines the overall security — know what this is. If you are interested in the X method, go and contact the person that created it — you will often be surprised how open many researchers are in sharing their ideas. Watch those CVE updates like a hawk — it can be a race between you and your adversary. On Cloud-based systems, log everything about your keys. In the Cloud, only allow keys to be used for the purpose they should be used for, and don't use them generally. Limit access to keys for services and roles. Reduce the impact of a stolen or lost secret key. Never encrypt large-scale data infrastructures with the same secret key — try to use envelope encryption. Passwords are dead — replace with cryptographic signing methods. Your enemy can be within. Watch out for key stealing and deletion. Tell your incident response team about the difference between losing encrypted data and non-encrypted data. Scan your network for secret keys placed in locations where they should not be stored. Know what the acronyms mean and not just what they stand for. Know why we use message authentication codes (MACs). If you need to generate an encryption key from a password or secret, pick a good KDF (Key Derivation Function), and know the cost to crack it. Rainbow tables aren't much of a threat anymore, so make use your use a good salt value. Everything below 72 bits of entropy is likely to be crackable by the NSA — unless a slow method is used for the processing with the key. Nonce/salt values should start at 96 bits. Never use anything less. RC4 has been cracked … get over it. Stream ciphers can often be broken — make sure you never reuse your salt value. DES and 3DES are mainly uncracked, but DES only uses a 56-bit key, so never use it Compared with ECC, RSA requires a good deal more processing and has larger key sizes, but it is still great. ECDSA suffers from nonce reuse attacks. For digital signatures, you should delete the nonce value after the signature has been created, but for symmetric key and hashing, you need to store it. In ECC, the public key is a point on the elliptic curve. For secp256k1, we have a 256-bit private key and a 512-bit (x,y) point for the public key. A “04” in the public key is an uncompressed public key, and “02” and “03” are compressed versions with only the x-co-ordinate and whether the y coordinate is odd or even. Consider writing papers — it is a great way to develop your writing and abstraction skills. Don't sit back with the status quo — try to continually improve privacy and security. Have a risk register and maintain it. Don't be shy, and don't hide things. Have someone to check your code — on a regular basis. Remember Moore's Law … computing power is increasing every year, so know that something that is safe now might not be in 10 years. Know how long something needs to be kept secure and secure for that age (and a lot more). And there you go … 100 rules of cryptography

Bill Buchanan - TETRA:BURST

Paul's Security Weekly TV

Play Episode Listen Later Aug 1, 2023 10:33

Blog: https://medium.com/asecuritysite-when-bob-met-alice/tetra-burst-42773a490b35 Introduction Anyone can create a cipher. Basically, Bob and Alice do some modulo maths and could encrypt their secret messages into ciphertext by multiplying by 10 and adding 5, and then to decrypt back into plaintext, they would just subtract the ciphertext by 5 and divide by 10. The maths involved could then be defined by a Galois Field (GF)— and which is named after Évariste Galois. Bob and Alice could then keep their method secret from Eve (their adversary), and where they believe their method is secure and thus do not ask Trent to evaluate its security. But Eve is sneaky and tries lots of different ways to crack the cipher. Eventually, after trying to crack the ciphertext, she discovers the method, and can then crack all the future (and, possibly, previous) ciphers. Bob and Alice then carry on using the secret cipher method and would then have no way of knowing that Eve now knows their method. This approach is often known as “cooking your own crypto”, and is not recommended in most implementations. Along with this, as Bob and Alice try to hide their method from Eve, the approach is “Security by obfuscation” rather than “Security-by-design”. Cooking your own crypto There are many cases of propriety cryptography methods being used in production. In 2013, for example, researchers at the University of Birmingham found flaws in the key fobs related to the Volkswagen group vehicles. In fact, the encryption used in the Swiss-made Megamos transponder was so weak that an intruder only needed to listen to two transmitted messages from the fob in order to crack the key. The vulnerability related to the poor, proprietary cryptographic methods used by the device, and where the researchers found they could generate the transponder's 96-bit secret key and start the car in less than half an hour. The vulnerability has been well known since 2012, and code to exploit the flaw has circulated online since 2009. Yet, at the time, there was no product recall for the dozens of models that were affected, including Audi, Porsche, Bentley and Lamborghini, Nissan and Volvo. The research team were even stopped from publishing their work through the threat of legal action from Volkswagen. Testing, Evaluation and Standardization Along with the risk of discovering a secret method, the other major problem is that the method used to create a cipher is when it is not rigorously reviewed by experts. This can take years of reviewing and testing — both in the formal theory and in practice. Many companies, too, have bug bounties and which try to discover vulnerabilities in their code. To overcome this, NIST has created open competitions for the standardization of encryption methods. These have included standards related to symmetric key encryption (AES), hashing methods (SHA-3) and post-quantum cryptography (PQC). Once rigorously evaluated, the industry can then follow the standards defined, and where proprietary methods and implementations are often not trusted. With symmetric-key methods (where the same key is used to both encrypt and decrypt), at one time, we used a wide range of methods, such as DES, 3DES, RC2, RC4, Blowfish, and Twofish. To overcome this, NIST set up an operation standardization process for the Advanced Encryption Standard (AES). In the end, and after extensive testing and performance analysis, the Rijndael method was selected. It is now used in most systems, with either a 128-bit, a 192-bit or 256-bit encryption key. Overall, the larger the key size, the more difficult it is to brute force the key. The TETRA standard This week it has been reported that the TETRA (TErrestrial Trunked RAdio) standard [here] has a number of vulnerabilities in its cryptography. Overall, TETRA is used by many police and military forces across the world for encrypted radio. These vulnerabilities have existed for over a decade and could have led to the leakage of sensitive information. These vulnerabilities have been discovered by Midnight Blue and will be presented as “Redacted Telecom Talk” at Black Hat 2023 on 9 August 2023 [here]. As the work is so sensitive, there are many issues related to its disclosure, so the full details of the talk have not been released. But, it has involved over 18 months of responsible disclosure related to the cracking of TETRA-powered radios purchased from eBay. TETRA was first standardised by the European Telecommunications Standards Institute (ETSI) in 1996 and used by many radio manufacturers, such as Motorola and Airbus. It does not have open-source software and relies on cryptography which is secret and proprietary. TEA1 — Intentionally weak crypto Goverments around the world have generally used export controls on cryptography — in order to reduce security levels so that their own law enforcement agents have a good chance to crack encrypted traffic outside their own borders. One of the most famous was related to Netscape and who created the original version of TLS (Transport Layer Security) that created a secure channel for Web pages — the HTTPs that we see on most of our Web accesses now. This, though, had reduced security levels because of export control — with the RSA method used set at only 512 bits (and which is now easily crackable). As this key was used to pass the encryption key that was used in the secure tunnel, it meant that agencies could break the communications channel for HTTPs communications. We have since paid for this weakening —and with vulnerabilities such as Freak and BEAST. The vulnerability in TETRA, too, relates to similar issues and where the cryptography was reduced to comply with export controls. Within TERTA, the TEA1 method reduces the key size down to 80 bits, and, along with other vulnerabilities, allows the encrypted traffic to be cracked within minutes on a standard laptop. Along with this, researchers found other vulnerabilities with TETRA methods that released sensitive information — including within historical communications. The core vulnerability involved a jump-off from the main interface on the radio, and then which followed through with running malicious code execution on the process and then onto the signal processor and wifi hardware. This main chip on the device then contains a secure enclave, which stores the main encryption keys. The team were able to access this chip and discover the cryptography methods used and associated artefacts. For this, they have dubbed the vulnerability TETRA:BURST [here]: The reduced security method of TEA1 was discovered as having an encryption key of just 80 bits (normally, we would use a 128-bit key size, at least). A key size of 80 bits puts it within a range which can be cracked using GPU clusters. But, the research team found a “secret reduction step” which supported lower levels of randomization for the encryption key and which significantly reduced the key strength. Using this, the team were able to crack the communication with consumer-level hardware and with inexpensive radio equipment. Ultimately, the researchers define the attack as fairly trivial to implement. Vulnerabilities discovered A number of CVEs have already been defined for the vulnerabilities. These are [here]: CVE-2022–24401. This involved the Air Interface Encryption (AIE) keystream generator allows for decryption oracle attacks. CVE-2022–24402. This relates to the backdoor of the 80-bit key on the TEA1 algorithm — and which allows a trivial cipher crack. CVE-2022–24404. This involves weaknesses in the AIE for malleability attacks. CVE-2022–24403. This is a weak cryptographic scheme that allows attackers to deanonymize and track users. CVE-2022–24400. This allows attackers to set the Derived Cypher Key (DCK) to 0. On the CVE database [here], these vulnerabilities are marked as “** RESERVED **” and will be populated soon. Conclusions What we have here is “Security by obscurity” and not “Security by design”. It is difficult to keep anything a secret these days, and, as much as possible, methods should be open to assessment. Along with this, the reduction in the security level for TEA1 is causing major problems — just the Netscape restriction on TLS left us with a security legacy that took decades to address.

PSW #762 - Ben Hibben

Paul's Security Weekly

Play Episode Listen Later Nov 3, 2022 163:01

Blenster comes on to talk about the Maker Movement, Hackerspaces, community and inclusive cultures, intentionality and kindness as a social cheat code, the right to repair movement, and using tools like the arduino/raspberry Pi to bring your projects to the next level! In the Security News: last year's open source is tomorrow's vulnerabilities, RepoJacking, I feel like there will always be authenitcation bypass, super charge your hacking, do you have your multipath, RC4 and why not to use it, here's the problem with vulnerability scanners, packages and expired domains, initrd should not be trusted, Apple kernels, oh and did you hear there is a vulnerability in OpenSSL! Visit https://www.securityweekly.com/psw for all the latest episodes! Visit https://securityweekly.com/acm to sign up for a demo or buy our AI Hunter! Follow us on Twitter: https://www.twitter.com/securityweekly/ Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/psw762

apple pi openssl maker movement security news hackerspaces rc4 ai hunter

OpenSSL Vulns, RepoJacking, Authentication Bypass, & Supercharging Your Hacking - PSW #762

Play Episode Listen Later Nov 3, 2022 91:27

In the Security News: last year's open source is tomorrow's vulnerabilities, RepoJacking, I feel like there will always be authenitcation bypass, super charge your hacking, do you have your multipath, RC4 and why not to use it, here's the problem with vulnerability scanners, packages and expired domains, initrd should not be trusted, Apple kernels, oh and did you hear there is a vulnerability in OpenSSL! Visit https://www.securityweekly.com/psw for all the latest episodes! Show Notes: https://securityweekly.com/psw762

apple hacking bypass authentication supercharging openssl security news vulns rc4

PSW #762 - Ben Hibben

Paul's Security Weekly (Podcast-Only)

Play Episode Listen Later Nov 3, 2022 163:01

apple pi openssl maker movement security news hackerspaces rc4 ai hunter

OpenSSL Vulns, RepoJacking, Authentication Bypass, & Supercharging Your Hacking - PSW #762

Paul's Security Weekly (Video-Only)

Play Episode Listen Later Nov 3, 2022 91:27

apple hacking bypass authentication supercharging openssl security news vulns rc4

Le RPOD - Edito du 23 /05/2022 - WRC : Portugal, et de 2 pour Anthony FOTIA !

Le RPod

Play Episode Listen Later May 23, 2022 2:45

23/05/2022 - Le RPOD - Au sommaire de cet édito du 20 Mai : WRC : Nouvelle victoire en RC4 pour Anthony FOTIA au Portugal !

portugal edito rc4 rpod wrc portugal

Positron afl 4: Geflipte bits

De Dienst

Play Episode Listen Later Mar 1, 2022 33:06

Malware onderzoeker Marc legt uit hoe de binary eruitziet. Cryptoloog Bas is best in zijn nopjes met de RC4 versleuteling. Hij vertelt Liesbeth waarom. Stap voor stap komen ze dichterbij een mogelijke doorbraak. De voorwaarde is wel dat het slachtoffer de malware laat zitten, maar durft het bedrijf dat? Wil jij meekijken? Kijk op: www.operatiepositron.nl. De Dienst is een podcast van de AIVD. De Dienst is tot stand gekomen in samenwerking met WerkMerk en Het Podcast Kantoor. De presentatie is in handen van Liesbeth Rasker. Operatie Positron is een fictief verhaal. Alle overeenkomsten met bestaande personen of gebeurtenissen berusten op toeval.

bits hij wil malware kijk stap liesbeth aivd positron rc4

Le RPOD - Edito du 24/01/2022 - WRC: Monte-Carlo, Retour en gloire de M-Sport et première victoire en WRC pour Anthony FOTIA !

Le RPod

Play Episode Listen Later Jan 24, 2022 3:58

24/01/2022 - Le RPOD - Au sommaire de cet édito du 24 janvier: WRC - Monte-Carlo: M-Sport renoue enfin avec la victoire en WRC - Première participation et première victoire au Monte Carlo pour Anthony FOTIA en catégorie RC4 !

premi retour monte carlo victoire gloire edito m sport rc4 rpod

Le RPOD - Edito du 21/01/2022 - WRC: Monte-Carlo, Evans avec les deux Seb et Fotia, premier de la RC4 !

Le RPod

Play Episode Listen Later Jan 21, 2022 3:39

21/01/2022 - Le RPOD - Au sommaire de cet édito du 21 janvier: WRC: Monte-Carlo : Après la nuit du Turini, Evans avec les deux Seb, Fourmaux en embuscade et Anthony Fotia, premier de la classe RC4. - Rallye : Anthony Fotia intègre le collectif Espoir de la FFSA !

premier evans avec les monte carlo seb les deux espoir edito rc4 rpod

Wireless encryption Explore the vulnerabilities it had before you use it.

Ethical Hacking

Play Episode Listen Later Jan 11, 2022 13:26

Hello everyone welcome to the show "Ethical Hacking" episode 84 today we are going to discuss about Wireless encryption. Another huge vulnerability in wireless networks is the encryption that you choose to use.In this lesson, we're going to do a quick review of wireless encryption types,that you learned back in your Network Plus studies.The reason for this is because encryption of your data being transmitted is going to be paramount to increasing the security of your wireless networks.Now, most wireless encryption schemes rely on a pre-shared key.This is when the access point and the client use the same encryption key to encrypt and decrypt the data.The problem with this is scalability becomes difficult.Think about it, when a friend comes over to your house,to use your WiFi.You have to tell him your password.Now, if you have 50 friends come over,you're going to tell 50 different people your password,and now, all 50 of them know your password.And so, this is one of the first problems that we have with wireless encryption,is that if you're going to use a pre-shared key,you've got to figure out a secure way to distribute that key to everybody,and keep it secret.If all 50 people know your password,then it's probably not that secret anymore.Now, there are three main types of encryption that are in use from wireless networks.We have WEP, WPA, and WPA2.WEP is our first one.WEP is the Wired Equivalent Privacy.This came from the original 802.11 wireless security standard,and it claimed to be as secure as a wired network.I'm going to prove this wrong to you in our demonstration later,because we're going to brute-force WEP,and break it in about three minutes.WEP was originally used with a static 40-bit pre-shared encryption key,but later it was upgraded to a 64-bit key,and, then again, to a 128-bit key.This isn't the main problem with WEP, though.The main problem is a 24-bit Initialization Vector,or IV, that it uses in establishing the connection,and it's sent in clear text.As I said, WEP is not very secure,and because of this weak Initialization Vector,we're going to be able to brute-force WEP in just a couple of minutes,using using Aircrack-Ng and other tools.So, to replace WEP, they came up with WPA.WPA is the WiFi Protected Access standard.It uses a Temporal Key Integrity Protocol, or TKIP,which uses a 48-bit Initialization Vector,instead of the 24-bit Initialization Vector used by WEP.The encryption that it uses is the Rivest Cipher 4,or RC4, and it added Message Integrity Checking, or MIC.And, it uses all of this to make sure that the data is secure,and ensuring that it's not modified in transit.Overall, it's a pretty good standard,but it does have some flaws,and so version 2 was released to fix those.WPA version 2, or WiFi Protected Access version 2 was created as part of the 802.11i standard,to provide stronger encryption and better integrity checking.The integrity checking is conducted through CCMP,which is the Counter Mode with Cipher Block Chaining Message Authentication Code Protocol.And, the encryption uses AES,the Advanced Encryption Standard.AES supports a 128-bit key, or higher,and WPA2 uses either a personal mode,with pretty short keys,or an enterprise mode,with centralized authentication via a radio server,or another centralized server,to handle that password distribution we were talking about.Now, I want to pause here for a second,and before we go any further,give you a couple of quick exam tips.First, if you're asked about WiFi,and it uses the word, Open, in the question, it's usually looking for some kind of answer that says the network has no security, or no protection.

explore open iv wifi mic wireless vulnerabilities encryption aes wpa ethical hacking wep wpa2 ccmp rc4

REAL TALK 447 - RYAN DUNGEY - PART 2 - SX12

Play Episode Listen Later May 22, 2021 34:20

Part 2 of our time with Ryan Dungey, where he's takes a look back on his career.

real talk world championships motorcycles motocross supercross mxgp monster energy supercross feld entertainment ricky carmichael fox racing ken roczen pro motocross eli tomac ryan dungey jett lawrence christian craig rc4 jeff emig colt nichols lucas oil pro motocross cameron mcadoo

REAL TALK 447 - RYAN DUNGEY - PART 1 - SX12

Play Episode Listen Later May 11, 2021 34:02

Ryan Dungey sits down with Ricky Carmichael and Jeff Emig to discuss life after racing. Join us for part 1 of a 2 part interview, where Ryan talks coffee, babies and opportunities that come his way since his retirement from Monster Energy Supercross and Lucas Oil Pro Motocross.

Real Talk 447 - 2021 - SX10

Play Episode Listen Later Apr 17, 2021 42:17

Ricky and Jeff debate the battle for the Monster energy Supercross title between Cooper Webb, Ken Roczen and Eli Tomac. Plus, they highlight the amazing crashes in Atlanta by Cameron Mcadoo and more.

monster real talk world championships motorcycles motocross supercross mxgp monster energy supercross feld entertainment ricky carmichael fox racing ken roczen pro motocross eli tomac cooper webb christian craig rc4 jeff emig colt nichols lucas oil pro motocross cameron mcadoo

Real Talk 447 - 2021 - SX9

Play Episode Listen Later Mar 19, 2021 33:43

Two rounds of Monster Energy Supercross have been completed in at the residency in Arlington, TX. Ricky Carmichael and Jeff Emig dissect a few of the stand out moments and the racers who created them.

REAL TALK 447 - 2021 - SX8

Play Episode Listen Later Mar 12, 2021 24:22

Ricky Carmichael and Jeff Emig break down a few on the important moments from Daytona, round 9 of Monster Energy Supercross.

REAL TALK 447 - 2021 - SX7

Play Episode Listen Later Mar 5, 2021 32:15

Ricky Carmichael and Jeff Emig talk red flag issues, radio communication and segmented main events for Monster Energy Supercross.

REAL TALK 447 - 2021 - SX6 - ADAM ENTICKNAP

Play Episode Listen Later Feb 25, 2021 34:41

The 722 Adam Enticknap joins Jeff Emig to analyze the tops stories from Round 6 of Monster Energy Supercross.

real talk world championships motorcycles motocross supercross mxgp monster energy supercross dean wilson justin cooper feld entertainment ricky carmichael fox racing ken roczen pro motocross eli tomac cooper webb justin barcia christian craig rc4 jeff emig colt nichols lucas oil pro motocross adam enticknap

REAL TALK 447 - 2021 - SX5

Play Episode Listen Later Feb 20, 2021 39:45

Ricky Carmichael and Jeff Emig discuss Round 7 of Monster Energy Supercross.

real talk world championships motorcycles motocross supercross mxgp monster energy supercross feld entertainment ricky carmichael fox racing ken roczen pro motocross eli tomac chad reed christian craig rc4 jeff emig colt nichols lucas oil pro motocross

REAL TALK 447 - 2021 - SX4

Play Episode Listen Later Feb 10, 2021 30:23

Ricky Carmichael and Jeff Emig focus on the blue flag and lapped rider situation from rounds 4 & 5 of Monster Energy Supercross.

real talk motorcycles motocross supercross mxgp monster energy supercross dean wilson feld entertainment ricky carmichael fox racing ken roczen pro motocross eli tomac justin barcia christian craig rc4 jeff emig colt nichols lucas oil pro motocross

REAL TALK 447 - 2021 - SX3

Play Episode Listen Later Feb 3, 2021 30:12

Ricky Carmichael and Jeff Emig discuss Round 3 of Monster Energy Supercross from Houston, Texas.

texas real talk world championships motorcycles motocross supercross mxgp monster energy supercross feld entertainment ricky carmichael fox racing ken roczen pro motocross eli tomac christian craig rc4 jeff emig colt nichols lucas oil pro motocross

REAL TALK 447 - 2021 - SX2

Play Episode Listen Later Jan 27, 2021 38:17

Ricky Carmichael and Jeff Emig discuss the incident between Dean Wilson, Ken Roczen and Cooper Webb in round 3 of Monster Energy Supercross. Plus, they remember the 1980 AMA Supercross Champion Mike Bell.

real talk world championships motorcycles motocross supercross mxgp monster energy supercross dean wilson feld entertainment ricky carmichael fox racing ken roczen pro motocross cooper webb rc4 jeff emig lucas oil pro motocross

REAL TALK 447 - 2021 - EP1

Play Episode Listen Later Jan 23, 2021 35:22

Ricky Carmichael and Jeff Emig are back in 2021 with candid conversations about Monster Energy Supercross. With two races in the books, they discuss the biggest stories up to this point.

real talk world championships motorcycles motocross supercross mxgp monster energy supercross feld entertainment ricky carmichael fox racing pro motocross rc4 jeff emig lucas oil pro motocross

Decred subiu 2000% na Korea, o que aconteceu? Bate papo, Politeia-Propostas, DCRDEX e novidades.

Decred Brasil

Play Episode Listen Later Dec 19, 2020 8:16

DECRED SEMANAL--------------------------------Sistema híbrido em destaque pela segurançahttps://twitter.com/woonomic/status/1337795685433790467--------------------------------Patrocinando https://gioui.org/https://twitter.com/raedahgroup/status/1336145716213809152--------------------------------Decred Journal de Novembrohttps://medium.com/decred/decred-journal-november-2020-d1bb2681a4d8--------------------------------Novo site do checkmate com todas as analises da Decredhttps://twitter.com/_Checkmatey_/status/1338418991212052485--------------------------------6 novos ATHshttps://twitter.com/_Checkmatey_/status/1337468814028640261--------------------------------Análiseshttps://twitter.com/PermabullNino/status/1338497116864438273https://twitter.com/_Checkmatey_/status/1337482205606506500?s=20--------------------------------Testes e Imagens do RC4 - https://twitter.com/xsanchezpr/status/1337978824278085632Anúncio: https://twitter.com/behindtext/status/1336721507855249408--------------------------------@EpsilonTheory fez um podcast e Decred foi mencionada.https://twitter.com/EpsilonTheory/status/1336658291066277889--------------------------------Entrevista com o Jake (PR work).https://twitter.com/merej99/status/1337216099415326720--------------------------------POLITEIAPropostas em discussãoDecred in Spanish Communications and Content Creation Proposal 3: https://proposals.decred.org/proposals/350f64bDecred Hackathons and LATAM Initial Chapter: https://proposals.decred.org/proposals/5ce1636

entrevista korea privacy governance novo dao novidades bate papo dex aconteceu testes imagens propostas subiu decred politeia rc4

Real Talk 447 - 30+2 - Zach Osborne

Play Episode Listen Later Nov 5, 2020 41:49

Ricky Carmichael and Jeff Emig are joined by Rockstar Energy Husqvarna Factory Racing’s Zach Osborne. The newly crowned Lucas Oil Pro Motocross 450 Champion talks about life, family and his quest to be a champion.

champion real talk motorcycles motocross supercross monster energy supercross feld entertainment ricky carmichael fox racing pro motocross zach osborne rc4 jeff emig lucas oil pro motocross

Real Talk 447 - Dave Prater - SX 2021 Update

real talk motorcycles motocross prater supercross monster energy supercross feld entertainment ricky carmichael fox racing rc4 jeff emig

Play Episode Listen Later Oct 28, 2020 26:48

Ricky Carmichael and Jeff Emig are joined by Dave Prater from Feld Entertainment to discuss the newly announced 2021 Monster Energy Supercross schedule.

La bataille de la RC4

C'était, il y a...

Play Episode Listen Later Oct 11, 2020

La bataille de la RC4

la bataille rc4

Real Talk 447 - 30+2 - Ep4 - David Vuillemin

Play Episode Listen Later Sep 13, 2020 40:34

Ricky Carmichael and Jeff Emig are joined by David Vuillemin. David Vuillemin is a French former professional motocross and supercross racer. He competed in the Motocross World Championships from 1995 to 1999 and won the 1999 supercross world championship. He competed in the AMA Motocross Championships from 2000 and 2008 before returning to the Motocross World Championships for one final season in 2009. was one of the few competitors who could beat both Jeremy McGrath and Ricky Carmichael in their prime.

france french real talk motorcycles motocross supercross mxgp monster energy supercross ricky carmichael fox racing pro motocross jeremy mcgrath rc4 jeff emig lucas oil pro motocross david vuillemin

Real Talk 447 - 30+2 - Ep3

Play Episode Listen Later Aug 31, 2020 38:00

Ricky Carmichael and Jeff Emig discuss round 2 of Lucas Oil Pro Motocross from Loretta Lynn’s Ranch. Ricky and Jeff are going on the clock for 30+2.

real talk ranch motorcycles loretta lynn motocross supercross mxgp ricky carmichael fox racing pro motocross rc4 jeff emig lucas oil pro motocross

REAL TALK 447 - 30+2 - MXGP UPDATE #1

Play Episode Listen Later Aug 28, 2020 39:24

Ricky Carmichael and Jeff Emig are joined by the former MXGP star and current voice of MXGP, Paul Malin. Paul is there for every lap, so he will bring us up to speed on everything MXGP after 5 races are in the books.

real talk motorcycles motocross supercross mxgp monster energy supercross ricky carmichael fox racing pro motocross rc4 jeff emig lucas oil pro motocross

REAL TALK 447 - 30+2 - RICKY CARMICHAEL AND JEFF EMIG - Ep2

Play Episode Listen Later Aug 21, 2020 35:30

Ricky Carmichael and Jeff Emig discuss round 1 of Lucas Oil Pro Motocross from Loretta Lynn’s Ranch. Ricky and Jeff are going on the clock for 30+2.

real talk ranch motorcycles loretta lynn motocross supercross mxgp ricky carmichael fox racing pro motocross rc4 jeff emig lucas oil pro motocross

REAL TALK 447 I 30+2 I RICKY CARMICHAEL AND JEFF EMIG I Ep1

Play Episode Listen Later Aug 18, 2020 33:28

Summer is here and that means Pro Motocross and MXGP! So Ricky Carmichael and Jeff Emig are going on the clock for 30+2, starting now!

real talk motocross supercross mxgp monster energy supercross ricky carmichael fox racing pro motocross rc4 jeff emig lucas oil pro motocross

Real Talk 447 - 2020 - Ken Roczen

Play Episode Listen Later Jun 10, 2020 58:57

A very special edition of RealTalk447 with Jeff Emig & Ricky Carmichael as Ken Roczen joins the show for Episode 22. Join the crew as Ken goes back to the early days of his career growing up in Germany, racing the GP’s, and his transition to over to the States after winning his MX2 World Title in 2011. Then catch up on the last few years of Ken’s career and massive success, plus all the ups and downs that have come along with it. And don’t worry, there’s plenty of smack talk to go along as well. Enjoy!

germany states real talk gp motocross supercross mxgp monster energy supercross fox racing ken roczen pro motocross rc4 lucas oil pro motocross

Real Talk 447 - 2020 - Steve Astephen

Play Episode Listen Later May 23, 2020 66:05

Ricky and Fro welcome Sports Agent and founder of The Familie, Steve Astephen to the show. Steve tells his background of how he got into the sport from the Snowboard industry and the guys discuss the more business side of things. Hear how everything works behind the scenes and it even gets a little heated towards the end!

familie real talk snowboards motocross sports agent supercross fro mxgp monster energy supercross fox racing rc4 lucas oil pro motocross astephen

Real Talk 447 - 2020 - Tim Gasjer

Play Episode Listen Later May 14, 2020 51:48

RealTalk447 is back and Jeff & Ricky are joined by a very special guest, 2-time MXGP World Champion and Factory HRC rider Tim Gajser. Get to know the Champ as the guys talk about the competition in the MXGP series, Tim’s 2019 championship run, his experiences racing Supercross in the US and his unique program in Europe that keeps him based full-time in his home country of Slovenia.

europe real talk champ slovenia motorcycles motocross supercross mxgp monster energy supercross fox racing rc4 lucas oil pro motocross

Real Talk 447 - 2020 - Austin Forker

Play Episode Listen Later May 6, 2020 51:42

Join Jeff & Ricky for another classic installment of RealTalk447, with 250 Class ace Austin Forkner joining the show for Episode 18. Hear what Austin has been up to during the current Covid-19 pandemic and dive deeper into his promising career and what makes him tick. And as always, there’s plenty of banter to go around - Enjoy!

class real talk ricky carmichael fox racing rc4 jeff emig austin forkner

Real Talk 447 - 2020 - Carey Hart - RCH

Play Episode Listen Later Apr 15, 2020 76:44

Ricky and Jeff welcome FMX Legend Carey Hart to the show. Walk through Carey’s career as a rider and transition into his race team that Hart & Huntington Racing, which eventually evolved into the factory supported RCH Racing with RC.

walk real talk hart rc motorcycles motocross supercross mxgp monster energy supercross rch fox racing carey hart rc4 lucas oil pro motocross

Real Talk 447 - 2020 - Dave Prater, Supercross Live

director sr real talk motocross monster energy prater supercross monster energy supercross feld entertainment pro motocross rc4

Play Episode Listen Later Mar 30, 2020 35:19

Dave Prater, the Sr. Director of two-wheel operations, Feld Entertainment, joins Ricky and Jeff to discuss Monster Energy Supercross, how it has been affected by the Cover-19 outbreak and what the possible plans are going forward to finish the championship before the end of 2020.

Real Talk 447 - 2020 - Dean Palmer

baseball mlb real talk major league baseball rc monster energy supercross rc4

Play Episode Listen Later Mar 17, 2020 60:08

Dean, RC and Jeff discuss Dean's MLB career, baseball and Supercross, and the two differ. And of course, there is some epic story telling in there too.

Real Talk 447 - 2020 Ep11 - Fox Racing Studios

real talk studios daytona motorcycles motocross supercross daytona international speedway monster energy supercross fox racing daytona supercross rc4

Play Episode Listen Later Mar 11, 2020 51:53

Plus, Ricky and Jeff tell some stories from their racing careers, give you stats from the SX Research Department, talk RMfantasySX and give away some goodies from RMatvmc, Slick Products, ODI Grips and Fox Racing.

Real Talk 447 - 2020 Ep10 Joey Savatgy - Fox Racing

SANS Internet Stormcenter Daily Network/Cyber Security and Information Security Stormcast

Play Episode Listen Later Mar 5, 2020 52:43

Ricky Carmichael and Jeff Emig are joined by JGR Suzuki rider Joey Savatgy to talk Round 9 of Monster Energy Supercross, go over the stats from the SX Research Department and tell some stories.

real talk motorcycles motocross supercross monster energy supercross ricky carmichael fox racing rc4 jeff emig joey savatgy jgr suzuki

Scraping The Surface Of Modern Cryptography

The History of Computing

Play Episode Listen Later Aug 7, 2019 14:43

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is scraping the surface of cryptography. Cryptography is derived from the Greek words kryptos, which stands for hidden and grafein, which stands for to write. Through history, cryptography has meant the process of concealing the contents of a message from all except those who know the key. Dating back to 1900 BC in Egypt and Julius Caesar using substitution cyphers, encryption used similar techniques for thousands of years, until a little before World War II. Vigenere designed the first known cipher thatused an encryption key in the 16th century. Since then with most encryption, you convert the contents, known as plaintext, into encrypted information that's otherwise unintelligible, known as cipher text. The cypher is a pair of algorithms - one to encrypt, the other to decrypt. Those processes are done by use of a key. Encryption has been used throughout the ages to hide messages. Thomas Jefferson built a wheel cypher. The order of the disks you put in the wheel was the key and you would provide a message, line the wheels up and it would convert the message into cypher text. You would tell the key to the person on the other end, they would put in the cypher text and out would pop the message. That was 1795 era encryption and is synonymous with what we call symmetrical key cryptography, which was independently invented by Etienne Bazeries and used well into the 1900s by the US Army. The Hebern rotor machine in the 19th century gave us an electro-mechanical version of the wheel cypher and then everything changed in encryption with the introduction of the Enigma Machine, which used different rotors placed into a machine and turned at different speeds based on the settings of those rotors. The innovations that came out of breaking that code and hiding the messages being sent by the Allies kickstarted the modern age of encryption. Most cryptographic techniques rely heavily on the exchange of cryptographic keys. Symmetric-key cryptography refers to encryption methods where both senders and receivers of data share the same key and data is encrypted and decrypted with algorithms based on those keys. The modern study of symmetric-key ciphers revolves around block ciphers and stream ciphers and how these ciphers are applied. Block ciphers take a block of plaintext and a key, then output a block of ciphertext of the same size. DES and AES are block ciphers. AES, also called Rijndael, is a designated cryptographic standard by the US government. AES usually uses a key size of 128, 192 or 256 bits. DES is no longer an approved method of encryption triple-DES, its variant, remains popular. Triple-DES uses three 56-bit DES keys and is used across a wide range of applications from ATM encryption to e-mail privacy and secure remote access. Many other block ciphers have been designed and released, with considerable variation in quality. Stream ciphers create an arbitrarily long stream of key material, which is combined with a plaintext bit by bit or character by character, somewhat like the one-time pad encryption technique. In a stream cipher, the output stream is based on an internal state, which changes as the cipher operates. That state's change is controlled by the key, and, in some stream ciphers, by the plaintext stream as well. RC4 is an example of a well-known stream cipher. Cryptographic hash functions do not use keys but take data and output a short, fixed length hash in a one-way function. For good hashing algorithms, collisions (two plaintexts which produce the same hash) are extremely difficult to find, although they do happen. Symmetric-key cryptosystems typically use the same key for encryption and decryption. A disadvantage of symmetric ciphers is that a complicated key management system is necessary to use them securely. Each distinct pair of communicating parties must share a different key. The number of keys required increases with the number of network members. This requires very complex key management schemes in large networks. It is also difficult to establish a secret key exchange between two communicating parties when a secure channel doesn't already exist between them. You can think of modern cryptography in computers as beginning with DES, or the Data Encryption Standard, us a 56-bit symmetric-key algorithm developed by IBM and published in 1975, with some tweaks here and there from the US National Security Agency. In 1977, Whitfield Diffie and Martin Hellman claimed they could build a machine for $20 million dollars that could find a DES key in one day. As computers get faster, the price goes down as does the time to crack the key. Diffie and Hellman are considered the inventors of public-key cryptography, or asymmetric key cryptography, which they proposed in 1976. With public key encryption, two different but mathematically related keys are used: a public key and a private key. A public key system is constructed so that calculation of the private key is computationally infeasible from knowledge of the public key, even though they are necessarily related. Instead, both keys are generated secretly, as an interrelated pair. In public-key cryptosystems, the public key may be freely distributed, while its paired private key must remain secret. The public key is typically used for encryption, while the private or secret key is used for decryption. Diffie and Hellman showed that public-key cryptography was possible by presenting the Diffie-Hellman key exchange protocol. The next year, Ron Rivest, Adi Shamir and Leonard Adleman developed the RSA encryption algorithm at MIT and founded RSA Data Security a few years later in 1982. Later, it became publicly known that asymmetric cryptography had been invented by James H. Ellis at GCHQ, a British intelligence organization and that both the Diffie-Hellman and RSA algorithms had been previously developed in 1970 and were initially called “non-secret encryption.” Apparently Ellis got the idea reading a bell labs paper about encrypting voice communication from World War II. Just to connect some dots here, Alan Turing, who broke the Enigma encryption, visited the proposed author of that paper, Shannon, in 1943. This shouldn't take anything away from Shannon, who was a brilliant mathematical genius in his own right, and got to see Gödel, Einstein, and others at Princeton. Random note: he invented wearables to help people cheat at roulette. Computer nerds have been trying leverage their mad skills to cheat at gambling for a long time. By the way, he also tried to cheat at, er, I mean, program chess very early on, noting that 10 to the 120th power was the game-tree complexity of chess and wrote a paper on it. Of course someone who does those things as a hobby would be widely recognized as the father of informational theory. RSA grew throughout the 80s and 90s and in 1995, they spun off a company called VeriSign, who handled patent agreements for the RSA technology until the patents wore out, er, I mean expired. RSA Security was acquired by EMC Corporation in 2006 for $2.1 billion and was a division of EMC until EMC was acquired by Dell in 2016. They also served as a CA - that business unit was sold in 2010 to Symantec for $1.28B. RSA has made a number of acquisitions and spun other businesses off over the years, helping them get into more biometric encryption options and other businesses. Over time the 56 bit key size of DES was too small and it was followed up by Triple-DES in 1998. And Advanced Encryption Standard, or AES, also in 1998. Diffie-Hellman and RSA, in addition to being the first public examples of high quality public-key cryptosystems have been amongst the most widely used. In addition to encryption, public-key cryptography can be used to implement digital signature schemes. A digital signature is somewhat like an ordinary signature; they have the characteristic that they are easy for a user to produce, but difficult for anyone else to forge. Digital signatures can also be permanently tied to the content of the message being signed as they cannot be moved from one document to another as any attempt will be detectable. In digital signature schemes, there are two algorithms: one for signing, in which a secret key is used to process the message (or a hash of the message or both), and one for verification, in which the matching public key is used with the message to check the validity of the signature. RSA and DSA are two of the most popular digital signature schemes. Digital signatures are central to the operation of public key infrastructures and to many network security schemes (SSL/TLS, many VPNs, etc). Digital signatures provide users with the ability to verify the integrity of the message, thus allowing for non-repudiation of the communication. Public-key algorithms are most often based on the computational complexity of hard problems, often from number theory. The hardness of RSA is related to the integer factorization problem, while Diffie-Hellman and DSA are related to the discrete logarithm problem. More recently, elliptic curve cryptography has developed in which security is based on number theoretic problems involving elliptic curves. Because of the complexity of the underlying problems, most public-key algorithms involve operations such as modular multiplication and exponentiation, which are much more computationally expensive than the techniques used in most block ciphers, especially with typical key sizes. As a result, public-key cryptosystems are commonly hybrid systems, in which a fast symmetric-key encryption algorithm is used for the message itself, while the relevant symmetric key is sent with the message, but encrypted using a public-key algorithm. Hybrid signature schemes are often used, in which a cryptographic hash function is computed, and only the resulting hash is digitally signed. OpenSSL is a software library that most applications use to access the various encryption mechanisms supported by the operating systems. OpenSSL supports Diffie-Hellman and various versions of RSA, MD5, AES, Base, sha, DES, cast and rc. OpenSSL allows you to create ciphers, decrypt information and set the various parameters required to encrypt and decrypt data. There are so many of these algorithms because people break them and then a new person has to come along and invent one and then version it, then add more bits to it, etc. At this point, I personally assume that all encryption systems can be broken. This might mean that the system is broken while encrypting, or the algorithm itself is broken once encrypted. A great example would be an accidental programming mistake allowing a password to be put into the password hint rather than in the password. Most flaws aren't as simple as that. Although Kerckhoffs's principle teaches us that the secrecy of your message should depend on the secrecy of the key, and not on the secrecy of the system used to encrypt the message. Some flaws are with the algorithms themselves, though. At this point most of those are public and security without a password or private key they just take too long to decrypt to be worth anything once decrypted. This doesn't mean we don't encrypt things, it just means that in addition to encryption we now add another factor to that security. But we'll leave the history of two-factor security to another episode. Finally, RSA made a lot of money because they used ciphers that were publicly reviewed and established as a standard. Public review of various technological innovations allows for commentary and making it better. Today, you can trust most encryption systems because due to that process, it costs more to decrypt what you're sending over the wire than what is being sent is worth. In other words, collaboration trumps secrecy.

history british digital dating mit public modern greek world war ii computers stream bc base albert einstein ibm triple hybrid us army allies surface atm enigma thomas jefferson julius caesar rsa encryption alan turing dsa vpns aes emc scraping cryptography symantec hellman gchq openssl verisign cryptographic md5 symmetric 28b enigma machine ssl tls rsa security diffie emc corporation rc4 diffie hellman us national security agency martin hellman

Episode 98 - Encryption

IGeometry

Play Episode Listen Later Jun 16, 2019 22:38

Encryption is the process of scrambling data to protect personal files, secure communication, hide identities and much more. In this video we will learn about the different type of encryptions we will talk about symmetric encryption, asymmetrical encryption, where they are used for and the pros and cons of each one. Symmetric encryption Asymmetrical encrypt Pros and cons of sym va asym Symmetric encryption Might as well just call it classic encryption I would argue and i think this is the first encryption known to us. I have some thing I dont want anyone to see I use a lock key to lock it. Only I can open it unless I have a lock. The same key you use to encrypt is the same key to Decrypt. Examples Examples of popular symmetric-key algorithms include AES Twofish Serpent DES Twofish, Serpent, AES (Rijndael), Blowfish CAST5, Kuznyechik, RC4, DES, 3DES, Skipjack, Safer+/++ (Bluetooth), and IDEA Asymmetrical encryptions We had symmetric encryptions for a long time, then internet came and networking and we needed to encrypt messages going back and forth. We said cool lets use AES. Then we said wait a second.. the other computer doesnt really have my key so we need to encrypt it.. Also called Public key encryption 1977 Rivest–Shamir–Adleman (RSA) Diffie–Hellman key exchange protocol DSS (Digital Signature Standard), which incorporates the Digital Signature Algorithm ElGamal Various elliptic curve techniques Various password-authenticated key agreement techniques Paillier cryptosystem RSA encryption algorithm (PKCS#1) Cramer–Shoup cryptosystem YAK authenticated key agreement protocol --- Send in a voice message: https://anchor.fm/hnasr/message

public pros serpent rsa encryption yak aes asymmetrical decrypt symmetric skipjack rc4 pkcs 3des

ISC StormCast for Monday, November 5th 2018

Play Episode Listen Later Nov 5, 2018 5:18

Beyond good ol' LaunchAgents https://isc.sans.edu/forums/diary/Beyond+good+ol+LaunchAgent+part+1/24274/ Dissecting a CVE-2017-11882 Exploit https://isc.sans.edu/forums/diary/Dissecting+a+CVE201711882+Exploit/24272/ Microsoft Edge Exploit About to Be Released https://twitter.com/Yux1xi Portsmash Vulnerability https://github.com/bbbrumley/portsmash RC4 (Arcfour) Depreciation in SSH https://tools.ietf.org/html/draft-ietf-curdle-rc4-die-die-die-12

business internet news microsoft network security computers cybersecurity intel cyber hacking dissecting macos cpu exploit infosec cve ssh smt be released rc4 isc stormcast

ISC StormCast for Monday, November 5th 2018

SANS Internet Stormcenter Daily Network/Cyber Security and Information Security Stormcast

Play Episode Listen Later Nov 4, 2018 5:18

business internet news microsoft network security computers cybersecurity intel cyber hacking dissecting macos cpu exploit infosec cve ssh smt be released rc4 isc stormcast

Podcast 071 - Bill Sempf on Sneakers

Cross Cutting Concerns Podcast

Play Episode Listen Later Feb 25, 2018 64:27

Bill Sempf and I watched a movie called Sneakers. This episode is sponsored by Smartsheet. This is an extra-large, jumbo-sized, special episode of Cross Cutting Concerns. There's just too much awesome in Sneakers to fit in a 15 minute episode. But don't worry, I'll be back to regular length episodes starting next week! Show Notes: Sneakers is a 1992 movie. If you haven't seen it yet, go watch it first, because this podcast contains spoilers! It's available to stream on Amazon, and it is well worth a purchase. Check out the incredible cast on IMDb (and also peek at the trivia section) An interview with Bob Abbott RSA - named after Rivest, Shamir, Adleman Intel's 49 qubit chip Fluhrer, Mantin, and Shamir attack on RC4 Book: Brute Force: Cracking the Data Encryption Standard by Matt Curtin We mentioned: Dark Web, Deep Web, Tor, look it up OSINT Framework by Justin Nordine Blue Team vs Red Team Conferences: CodeMash, DerbyCon David Kennedy segment on CNN Money Podcast: Security Through Education - Episode 098: Winning the SECTF with Chris & Rachel The Economist cover and story: The world’s most valuable resource is no longer oil, but data Bitcoin was mentioned Paper: Smartphone User Identity Verification Using Gait Characteristics (gait analysis) Comic: XKCD on Security Captain Crunch = John Draper, here's a video from ABC News Tiger Team: Car Dealer Takedown OWASP Bill Sempf is on Twitter. Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Music is by Joe Ferg, check out more music on JoeFerg.com!

music amazon technology winning security bitcoin software computers comic lightning intel economists programming talks imdb conferences abc news sneakers abbott tor dark web rsa deep web cnn money red team shamir owasp blue team xkcd smartsheet david kennedy rivest derbycon tiger team codemash rc4 sectf page1 bob abbott matt curtin bill sempf

ngAir 73 - Discussion Topics Show

Angular Air

Play Episode Listen Later Jul 22, 2016 57:59

ngAir 73 - discussion show Topics Panelist updates Justin Back from Vegas where I tied the knot with a MacBook Pro Auth and single sign on with ng2 and Auth0 Ng2 forms api changes for RC4 and beyond Jeff Raising money Fast initial load Preboot Admin dashboard Angular News Angular Team Notes https://docs.google.com/document/d/150lerb1LmNLuau_a_EznPV1I1UHMTbEl61t4hZ7ZpS0/edit#heading=h.4p9qrlj65ncu New new new Angular 2 Router http://blog.thoughtram.io/angular/2016/06/14/routing-in-angular-2-revisited.html From Team Notes: Now v1 feature complete. Lazy loading, guards, etc. works. Release will come after RC5. More docs in the works to help with adoption. Migrating to new forms API http://schwarty.com/2016/07/18/migrating-model-driven-forms-to-the-new-forms-api-in-angular-2/ From Team Notes: updateValue going into RC5, reset going in later, more features coming. As of RC5, no forms are included by default. Developers will specify the ones they want at bootstrap. Good time to move to the new forms! CLI From Team Notes: Adding WebPack under the hood, support Offline Compiler, blueprints with app module support and new bootstrapping code, and upgrade story to get folks from ng2 vN to ng2 vN+1. Mention React CLI...movement toward more opinions... Angular 2 release date? https://github.com/angular/angular/milestones 27% complete? Coming up next in the world of Angular: AngularConnect http://angularconnect.com/ about to release the schedule: 5 tracks! AngularUp http://angular-up.com/ Israel Angular conf Nov 17 Coming up next on AngularAir July 26 - CLI with Mike Brocchi August 2 - Webpack 2 with Sean Larkin August 9 - Universal Tips and Tricks Tips & Picks Jeff Star Wars Rebels https://www.youtube.com/watch?v=xmXp802sFgQ Justin Mr. Robot http://www.usanetwork.com/mrrobot --- Support this podcast: https://anchor.fm/angularair/support

israel las vegas robots developers api angular router vn cli webpack rc4 rc5 angularup

Эпизод 61 - It was, It will, It can be...

Securit13 Podcast

Play Episode Listen Later Jun 5, 2016 74:15

Intro / Outro We are Connected (the Chemma Chi Remix) by SackJo22 http://dig.ccmixter.org/files/SackJo22/48168 00:01:39 GCHQ joins Twitter https://twitter.com/GCHQ 00:02:42 Интервью с Андреем Кузьменко. Связаться с Андреем можно в LinkedIn https://goo.gl/nYXCwT или по почте andrii.kuzmenko@ua.ibm.com 00:05:53 Your car can be held for ransom http://goo.gl/k3CPOE Car hacking news: Ransomware threat could reach auto dealerships http://goo.gl/Hwr3Ep Ransomware cyberattacker did not pretend to be Car-Part.com employee http://goo.gl/yDWS21 Visa USA | Visa Everywhere | Innovation | Connected Car https://goo.gl/dPqFfw Ditch the Wallet and Pay With Your Car http://goo.gl/yrvQgw https://security.love/Pastejacking/ 00:10:38 Hospital pays ransom, ransomware demands more money http://goo.gl/MIfeas 00:10:47 Observations and thoughts on the LinkedIn data breach https://goo.gl/BlUfgW 00:19:48 Heart surgery stalled for nearly 5 mins as anti-virus scan crashes computers https://goo.gl/duIz16 00:33:19 Pornhub said to be compromised, shell access available for $1,000 http://goo.gl/X2jbUz 00:37:04 У Києві поліція затримала кіберзлодіїв, які обкрадали банкомати з допомогою вірусу http://goo.gl/It8mYn 00:51:33 Symantec antivirus bug allows utter exploitation of memory http://goo.gl/yAehKc 00:56:02 Книга от гостя On the Road by Jack Kerouac http://goo.gl/HSO7fs 00:58:05 CVE-2016-4117: Flash Zero-Day Exploited in the Wild https://goo.gl/QMhPHS 01:00:08 Взломан украинский реестр недвижимости http://goo.gl/SHFyEB 01:01:40 Ukrainian hacker pleads guilty to insider trading in US http://goo.gl/dtf8jy 01:02:16 Observations and thoughts on the LinkedIn data breach https://goo.gl/BlUfgW 01:04:06 SWIFT Warns of Second Bank Attack via PDF Malware https://goo.gl/2x9DFX U.S. banks scrutinize SWIFT security after hacks: reports http://goo.gl/iCuJZS Exclusive: UK banks ordered to review cyber security after SWIFT heist http://goo.gl/EVkOvU 01:05:23 Hacker fans give Mr. Robot website free security checkup http://goo.gl/pgMRmI 01:06:13 TeslaCrypt shuts down and Releases Master Decryption Key http://goo.gl/mvdBF1 01:06:54 You really shouldn't download 'WhatsApp Gold' http://goo.gl/Ku3Buc 01:07:45 Google Set to Kill SSLv3, RC4 in SMTP, Gmail in June https://goo.gl/7JcYAY Видео запись эпизода на нашем канале https://www.youtube.com/channel/UCGYHYOm_J3zpyE5jCNzAHJg

wild heart hospitals robots connected ukrainian hackers swift observations gmail wallet pornhub ransomware jack kerouac symantec cve gchq smtp sackjo22 rc4 teslacrypt

134: Marking up the Ports tree

Brakeing Down Security Podcast

Play Episode Listen Later Mar 24, 2016 125:28

This week on the show, Allan and I have gotten a bit more sleep since AsiaBSDCon, which is excellent since there is a LOT of news to cover. That plus our interview with Ports SecTeam member Mark Felder. So keep it This episode was brought to you by Headlines FreeNAS 9.10 Released (http://lists.freenas.org/pipermail/freenas-announce/2016-March/000028.html) OS: The base OS version for FreeNAS 9.10 is now FreeBSD 10.3-RC3, bringing in a huge number of OS-related bug fixes, performance improvements and new features. +Directory Services: You can now connect to large AD domains with cache disabled. +Reporting: Add the ability to send collectd data to a remote graphite server. +Hardware Support: Added Support for Intel I219-V & I219-LM Gigabit Ethernet Chipset Added Support for Intel Skylake architecture Improved support for USB devices (like network adapters) USB 3.0 devices now supported. +Filesharing: Samba (SMB filesharing) updated from version 4.1 to 4.3.4 Added GUI feature to allow nfsv3-like ownership when using nfsv4 Various bug fixes related to FreeBSD 10. +Ports: FreeBSD ports updated to follow the FreeBSD 2016Q1 branch. +Jails: FreeBSD Jails now default to a FreeBSD 10.3-RC2 based template. Old jails, or systems on which jails have been installed, will still default to the previous FreeBSD 9.3 based template. Only those machinesusing jails for the first time (or deleting and recreating their jails dataset) will use the new template. +bhyve: ++In the upcoming 10 release, the CLI will offer full support for managing virtual machines and containers. Until then, the iohyve command is bundled as a stop-gap solution to provide basic VM management support - *** Ubuntu BSD's first Beta Release (https://sourceforge.net/projects/ubuntubsd/) Under the category of “Where did this come from?”, we have a first beta release of Ubuntu BSD. Specifically it is Ubuntu, respun to use the FreeBSD kernel and ZFS natively. From looking at the minimal information up on sourceforge, we gather that is has a nice text-based installer, which supports ZFS configuration and iSCSI volume creation setups. Aside from that, it includes the XFCE desktop out of box, but claims to be suitable for both desktops and servers alike right now. We will keep an eye on this, if anybody listening has already tested it out, maybe drop us a line on your thoughts of how this mash-up works out. *** FreeBSD - a lesson in poor defaults (http://vez.mrsk.me/freebsd-defaults.txt) Former BSD producer, and now OpenBSD developer, TJ, writes a post detailing the defaults he changes in a fresh FreeBSD installation Maybe some of these should be the defaults While others are definitely a personal preference, or are not as security related as they seem A few of these, while valid criticisms, but some are done for a reason Specifically, the OpenSSH changes. So, you're a user, you install FreeBSD 10.0, and it comes with OpenSSH version X, which has some specific defaults As guaranteed by the FreeBSD Project, you will have a nice smooth upgrade path to any version in the 10.x branch Just because OpenSSH has released version Y, doesn't mean that the upgrade can suddenly remove support for DSA keys, or re-adding support for AES-CBC (which is not really weak, and which can be hardware accelerated, unlikely most of the replacements) “FreeBSD is the team trying to increase the risk.” Is incorrect, they are trying to reduce the impact on the end user Specifically, a user upgrading from 10.x to 10.3, should not end up locked out of their SSH server, or otherwise confronted by unexpected errors or slowdowns because of upstream changes I will note again, (and again), that the NONE cipher can NOT allow a user to “shoot themselves in the foot”, encryption is still used during the login phase, it is just disabled for the file transfer phase. The NONE cipher will refuse to work for an interactive session. While the post states that the NONE cipher doesn't improve performance that much, it infact does In my own testing, chacha20-poly1305 1.3 gbps, aes128-gcm (fastest) 5.0 gbps, NONE cipher 6.3 gbps That means that the NONE cipher is an hour faster to transfer 10 TB over the LAN. The article suggests just removing sendmail with no replacement. Not sure how they expect users to deliver mail, or the daily/weekly reports Ports can be compiled as a regular user. Only the install phase requires root for ntpd, it is not clear that there is an acceptable replacement yet, but I will not that it is off by default In the sysctl section, I am not sure I see how enabling tcp blackhole actually increases security at all I am not sure that linking to every security advisory in openssl since 2001 is actually useful Encrypted swap is an option in bsdinstall now, but I am not sure it is really that important FreeBSD now uses the Fortuna PRNG, upgraded to replace the older Yarrow, not vanilla RC4. “The resistance from the security team to phase out legacy options makes mewonder if they should be called a compatibility team instead.” I do not think this is the choice of the security team, it is the ABI guarantee that the project makes. The stable/10 branch will always have the same ABI, and a program or driver compiled against it will work with any version on that branch The security team doesn't really have a choice in the matter. Switching the version of OpenSSL used in FreeBSD 9.x would likely break a large number of applications the user has installed Something may need to be done differently, since it doesn't look like any version of OpenSSL, (or OpenSSH), will be supported for 5 years ever again *** ZFS Raidz Performance, Capacity and Integrity (https://calomel.org/zfs_raid_speed_capacity.html) An updated version of an article comparing the performance of various ZFS vdev configurations The settings users in the test may not reflect your workload If you are benchmarking ZFS, consider using multiple files across different datasets, and not making all of the writes synchronous Also, it is advisable to run more than 3 runs of each test Comparing the numbers from the 12 and 24 disk tests, it is surprising to see that the 12 mirror sets did not outperform the other configurations. In the 12 drive tests, the 6 mirror sets had about the same read performance as the other configurations, it is not clear why the performance with more disks is worse, or why it is no longer in line with the other configurations More investigation of this would be required There are obviously so other bottlenecks, as 5x SSDs in RAID-Z1 performed the same as 17x SSDs in RAID-Z1 Interesting results none the less *** iXSystems FreeNAS Mini Review (http://www.nasanda.com/2016/03/ixsystems-freenas-mini-nas-device-reviewed/) Interview - Mark Felder - feld@freebsd.org (mailto:feld@freebsd.org) / @feldpos (https://twitter.com/feldpos) Ports, Ports and more Ports DigitalOcean Digital Ocean's guide to setting up an OpenVPN server (https://www.digitalocean.com/community/tutorials/how-to-configure-and-connect-to-a-private-openvpn-server-on-freebsd-10-1) News Roundup AsiaBSDCon OpenBSD Papers (http://undeadly.org/cgi?action=article&sid=20160316153158&mode=flat&count=0) + Undeadly.org has compiled a handy list of the various OpenBSD talks / papers that were offered a few weeks ago at AsiaBSDCon 2016. Antoine Jacoutot (ajacoutot@) - OpenBSD rc.d(8) (slides | paper) Henning Brauer (henning@) - Running an ISP on OpenBSD (slides) Mike Belopuhov (mikeb@) - Implementation of Xen PVHVM drivers in OpenBSD (slides | paper) Mike Belopuhov (mikeb@) - OpenBSD project status update (slides) Mike Larkin (mlarkin@) - OpenBSD vmm Update (slides) Reyk Floeter (reyk@) - OpenBSD vmd Update (slides) Each talk provides slides, and some the papers as well. Also included is the update to ‘vmm' discussed at bhyveCon, which will be of interest to virtualization enthusiasts. *** Bitcoin Devs could learn a lot from BSD (http://bitcoinist.net/bitcoin-devs-could-learn-a-lot-from-bsd/) An interesting article this week, comparing two projects that at first glance may not be entirely related, namely BitCoin and BSD. The article first details some of the woes currently plaguing the BitCoin development community, such as toxic community feedback to changes and stakeholders with vested financial interests being unable to work towards a common development purpose. This leads into the crux or the article, about what BitCoin devs could learn from BSD: First and foremost, the way code is developed needs change to stop the current negative trend in Bitcoin. The FreeBSD project has a rigid internal hierarchy of people with write access to their codebase, which the various Bitcoin implementations also have, but BSD does this in a way that is very open to fresh eyes on their code, allowing parallel problem solving without the petty infighting we see in Bitcoin. Anyone can propose a commit publicly to the code, make it publicly available, and democratically decide which change ends up in the codebase. FreeBSD has a tiny number of core developers compared to the size of their codebase, but at any point, they have a huge community advancing their project without hard forks popping up at every small disagreement. Brian Armstrong commented recently on this flaw with Bitcoin development, particularly with the Core Devs: “Being high IQ is not enough for a team to succeed. You need to make reasonable tradeoffs, collaborate, be welcoming, communicate, and be easy to work with. Any team that doesn't have this will be unable to attract top talent and will struggle long term. In my opinion, perhaps the biggest risk in Bitcoin right now is, ironically, one of the things which has helped it the most in the past: the Bitcoin Core developers.” A good summary of the culture that could be adopted is summed up as follows: The other thing Bitcoin devs could learn from is the BSD community's adoption of the Unix Design philosophy. Primarily “Worse is Better,” The rule of Diversity, and Do One Thing and Do It Well. “Worse is Better” emphasizes using extant functional solutions rather than making more complex ones, even if they would be more robust. The Rule of Diversity stresses flexibility of the program being developed, allowing for modification and different implementations without breaking. Do one Thing and Do it well is a mantra of the BSD and Unix Communities that stresses modularity and progress over “perfect” solutions. Each of these elements help to make BSD a wildly successful open source project with a healthy development community and lots of inter-cooperation between the different BSD systems. While this is the opposite of what we see with Bitcoin at present, the situation is salvageable provided changes like this are made, especially by Core Developers. All in all, a well written and interesting take on the FreeBSD/BSD project. We hope the BitCoin devs can take something useful from it down the road. *** FreeBSD cross-compiling with gcc and poudriere (http://ben.eficium.net/2016/03/freebsd-cross-compiling-with-gcc.html) Cross-Compiling, always a challenge, has gotten easier using poudriere and qemu in recent years. However this blog post details some of the particular issues still being face when trying to compile some certain ports for ARM (I.E. rPi) that don't play nicely with FreeBSD's default CLANG compiler. The writer (Ben Slack) takes us through some of the work-arounds he uses to build some troublesome ports, namely lsof and libatomic_ops. Note this is not just an issue with cross compile, the above mentioned ports also don't build with clang on the Pi directly. After doing the initial poudriere/qemu cross-compile setup, he then shows us the minor tweaks to adjust which compiler builds specific ports, and how he triggers the builds using poudriere. With the actual Makefile adjustment being so minor, one wonders if this shouldn't just be committed upstream, with some if (ARM) - USE_GCC=yes type conditional. *** Nvidia releases new Beta graphics driver for FreeBSD (https://devtalk.nvidia.com/default/topic/925607/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-364-12-beta-/) Added support for the following GPUs: GeForce 920MX & GeForce 930MX Added support for the Vulkan API version 1.0. Fixed a bug that could cause incorrect frame rate reporting on Quadro Sync configurations with multiple GPUs. Added a new RandR property, CscMatrix, which specifies a 3x4 color-space conversion matrix. Improved handling of the X gamma ramp on GF119 and newer GPUs. On these GPUs, the RandR gamma ramp is always 1024 entries and now applies to the cursor and VDPAU or workstation overlays in addition to the X root window. Fixes for bugs and added several other EGL extensions *** Beastie Bits New TN Bug started (http://knoxbug.org/) DragonFlyBSD Network/TCP Performance's gets a bump (http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/4a43469a10cef8c17553c342aab9d73611ea7bc8?utm_source=anzwix) FreeBSD Foundation introduces a new website and logo (https://www.freebsdfoundation.org/blog/introducing-a-new-look-for-the-foundation/) Our producer made these based on the new logo: http://q5sys.sh/2016/03/a-new-freebsd-foundation-logo-means-its-time-for-some-new-wallpapers/ http://q5sys.sh/2016/03/pc-bsd-and-lumina-desktop-wallpapers/ https://github.com/pcbsd/lumina/commit/60314f46247b7ad6e877af503b3814b0be170da8 IPv6 errata for 5.7/5.8, pledge errata for 5.9 (http://undeadly.org/cgi?action=article&sid=20160316190937&mode=flat) Sponsoring “PAM Mastery” (http://blather.michaelwlucas.com/archives/2577) A visualization of FreeBSD commits on GitHub for 2015 (https://rocketgraph.com/s/v89jBkKN4e-) The VAX platform is no more (http://undeadly.org/cgi?action=article&sid=20160309192510) Feedback/Questions Hunter - Utils for Blind (http://slexy.org/view/s20KPYDOsq) Chris - ZFS Quotas (http://slexy.org/view/s2EHdI3z3L) Anonymous - Tun, Tap and Me! (http://slexy.org/view/s21Nx1VSiU) Andrew - Navigating the BSDs (http://slexy.org/view/s2ZKK2DZTL) Brent - Wifi on BSD (http://slexy.org/view/s20duO29mN) ***

interview guide running diversity bitcoin built tree blind os integrity worse released tap developers pi beta iq switching capacity improved nvidia storage added how to implementation usb open source tutorials github lan tb vm abi fixes marking ubuntu ports ssd isp gpus dsa cli rpi ssh digital ocean yarrow ipv6 bsd brian armstrong freebsd openssl clang bitcoin core egl openssh zfs openvpn openbsd xfce r and r rc2 rc3 beta release freenas iscsi rc4 netbsd do one thing allan jude bsds ixsystems freebsd foundation kris moore tarsnap vulkan api dragonflybsd asiabsdcon

2016-002-Cryptonite- or how to not have your apps turn to crap

Play Episode Listen Later Jan 10, 2016 63:15

This week, we find ourselves understanding the #Cryptonite that can weaken devs and software creators when dealing with #cryptographic #algorithms and #passwords. Lack of proper crypto controls and hardcoded passwords can quickly turn your app into crap. Remember the last time you heard about a hardcoded #SSH private key, or have you been at work when a developer left the #API keys in his #github #repo? We go through some gotchas from the excellent book "24 Deadly Sins of Software Security". Anyone doing a threat analysis, or code audit needs to check for these things to ensure you don't end up in the news with a hardcoded password in your home router firmware, like these guys: https://securityledger.com/2015/08/hardcoded-firmware-password-sinks-home-routers/ Book: http://www.amazon.com/Deadly-Sins-Software-Security-Programming/dp/0071626751 Show Notes: https://docs.google.com/document/d/1MUPj8CCzDodik61_1K8lCKywkv0JbfBkve20rxwbmzE/edit?usp=sharing *NEW* we are on Stitcher!: http://www.stitcher.com/s?fid=80546&refid=stpr TuneIn Radio App: http://tunein.com/r…/Brakeing-Down-Security-Podcast-p801582/ BrakeSec Podcast Twitter: http://www.twitter.com/brakesec Bryan's Twitter: http://www.twitter.com/bryanbrake Brian's Twitter: http://www.twitter.com/boettcherpwned Join our Patreon!: https://www.patreon.com/bds_podcast RSS FEED: http://www.brakeingsecurity.com/rss Comments, Questions, Feedback: bds.podcast@gmail.com Direct Download: http://traffic.libsyn.com/brakeingsecurity/2016-002-Cryptonite.mp3 iTunes: https://itunes.apple.com/us/podcast/2016-002-cryptonite-or-how/id799131292?i=360440391&mt=2

code lack crypto apps stitcher developers api crap passwords repo deadly sins aes firmware ssh sdlc software security rc4 sha1 cryptonite brakeing down security podcast

A Bias to Insecurity | TechSNAP 223

TechSNAP Large Video

Play Episode Listen Later Jul 16, 2015 82:12

The Hacking Team fallout continues with more zero day patches you need to install, a new attack against RC4 might finally kill it & how to save yourself from a DDoS attack. Plus a great batch of your questions, our answers & much, much more!

stories technology news debate microsoft windows bias analysis jupiter broadcasting insecurity linux apache ddos encryption ssl bsd hacking team rc4 techsnap

On this week's mini-episode, we'll be talking with Baptiste Daroussin about packaging the FreeBSD base system with pkgng. Is this the best way going forward, or are we getting dangerously close to being Linux-like? We'll find out, and also get to a couple of your emails while we're at it, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines Xen dom0 in FreeBSD 11-CURRENT (https://svnweb.freebsd.org/ports?view=revision&revision=382965) FreeBSD has just gotten dom0 (http://wiki.xen.org/wiki/Dom0) support for the Xen hypervisor, something NetBSD has had (http://wiki.netbsd.org/ports/xen/howto/#netbsd-dom0) for a while now The ports tree will now have a Xen kernel and toolstack, meaning that they can be updated much more rapidly than if they were part of base It's currently limited to Intel boxes with EPT and a working IOMMU, running a recent version of the -CURRENT branch, but we'll likely see it when 11.0 comes out How will this affect interest in Bhyve? *** A tale of two educational moments (http://blog.anthrobsd.net/044.html) Here we have a blog post from an OpenBSD developer about some experiences he had helping people get involved with the project It's split into two stories: one that could've gone better, and one that went really well For the first one, he found that someone was trying to modify a package from their ports tree to have fewer dependencies Experience really showed its worth, and he was able to write a quick patch to do exactly what the other person had been working on for a few hours - but wasn't so encouraging about getting it committed In the second story, he discussed updating a different port with a user of a forum, and ended up improving the new user's workflow considerably with just a few tips The lesson to take away from this is that we can all help out to encourage and assist new users - everyone was a newbie once *** What's coming in NetBSD 7 (http://saveosx.org/NetBSD7/) We first mentioned NetBSD 7.0 on the show in July of 2014, but it still hasn't been released and there hasn't been much public info about it This blog post outlines some of the bigger features that we can expect to see when it actually does come out Their total platform count is now over 70, so you'd be hard-pressed to find something that it doesn't run on There have been a lot of improvements in the graphics area, particularly with DRM/KMS, including Intel Haswell and Nouveau (for nVidia cards) Many ARM boards now have full SMP support Clang has also finally made its way into the base system, something we're glad to see, and it should be able to build the base OS on i386, AMD64 and ARM - other architectures are still a WIP In the crypto department: their PNRG has switched from the broken RC4 to the more modern ChaCha20, OpenSSL has been updated in base and LibreSSL is in pkgsrc NetBSD's in-house firewall, npf, has gotten major improvements since its initial debut in NetBSD 6.0 Looking to the future, NetBSD hopes to integrate a stable ZFS implementation later on *** OpenZFS office hours (https://www.youtube.com/watch?v=mS4bfbEq46I) We mentioned a couple weeks back that the OpenZFS office hours series was starting back up They've just uploaded the recording of their most recent freeform discussion, with Justin Gibbs (http://www.bsdnow.tv/episodes/2015_03_11-the_pcbsd_tour_ii) being the main presenter In it, they cover how Justin got into ZFS, running in virtualized environments, getting patches into the different projects, getting more people involved, reviewing code, spinning disks vs SSDs, defragging, speeding up resilvering, zfsd and much more *** Interview - Baptiste Daroussin - bapt@freebsd.org (mailto:bapt@freebsd.org) Packaging the FreeBSD base system with pkgng Discussion Packaging the FreeBSD base system with pkgng (follow-up) Feedback/Questions Jeff writes in (http://slexy.org/view/s20AWp6Av1) Anonymous writes in (http://slexy.org/view/s20QiFcdh8) Alex writes in (http://slexy.org/view/s2YzZlswaB) Joris writes in (http://slexy.org/view/s21Mx9TopQ) *** Mailing List Gold ok feedback@ (https://www.marc.info/?l=openbsd-ports&m=142679136422432&w=2) ***

interview guide current built os remove presentation developers intel arm nvidia storage how to sd open source tutorials nouveau linux packaging ssd domu digital ocean bsd xen freebsd openssl ept zfs openbsd openzfs pkg rc4 netbsd allan jude ixsystems kris moore tarsnap justin gibbs iommu bsd now dragonflybsd asiabsdcon

64: Rump Kernels Revisited

Play Episode Listen Later Nov 19, 2014 113:32

This time on the show, we'll be talking with Justin Cormack about NetBSD rump kernels. We'll learn how to run them on other operating systems, what's planned for the future and a lot more. As always, answers to viewer-submitted questions and all the news for the week, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines EuroBSDCon 2014 talks and tutorials (http://2014.eurobsdcon.org/talks-and-schedule/) The 2014 EuroBSDCon videos have been online for over a month, but unannounced - keep in mind these links may be temporary (but we'll mention their new location in a future show and fix the show notes if that's the case) Arun Thomas, BSD ARM Kernel Internals (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/03.Saturday/01.BSD-ARM%20Kernel%20Internals%20-%20Arun%20Thomas.mp4) Ted Unangst, Developing Software in a Hostile Environment (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/03.Saturday/02.Developing%20Software%20in%20a%20Hostile%20Environment%20-%20Ted%20Unangst.mp4) Martin Pieuchot, Taming OpenBSD Network Stack Dragons (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/03.Saturday/03.Taming%20OpenBSD%20Network%20Stack%20Dragons%20-%20Martin%20Pieuchot.mp4) Henning Brauer, OpenBGPD turns 10 years (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/03.Saturday/04.OpenBGPD%20turns%2010%20years%20-%20%20Henning%20Brauer.mp4) Claudio Jeker, vscsi and iscsid iSCSI initiator the OpenBSD way (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/03.Saturday/05.vscsi(4)%20and%20iscsid%20-%20iSCSI%20initiator%20the%20OpenBSD%20way%20-%20Claudio%20Jeker.mp4) Paul Irofti, Making OpenBSD Useful on the Octeon Network Gear (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/03.Saturday/06.Making%20OpenBSD%20Useful%20on%20the%20Octeon%20Network%20Gear%20-%20Paul%20Irofti.mp4) Baptiste Daroussin, Cross Building the FreeBSD ports tree (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/04.Sunday/01.Cross%20Building%20the%20FreeBSD%20ports%20tree%20-%20Baptiste%20Daroussin.mp4) Boris Astardzhiev, Smartcom's control plane software, a customized version of FreeBSD (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/04.Sunday/02.Smartcom%e2%80%99s%20control%20plane%20software,%20a%20customized%20version%20of%20FreeBSD%20-%20Boris%20Astardzhiev.mp4) Michał Dubiel, OpenStack and OpenContrail for FreeBSD platform (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/04.Sunday/03.OpenStack%20and%20OpenContrail%20for%20FreeBSD%20platform%20-%20Micha%c5%82%20Dubiel.mp4) Martin Husemann & Joerg Sonnenberger, Tool-chaining the Hydra, the ongoing quest for modern toolchains in NetBSD (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/04.Sunday/04.(Tool-)chaining%20the%20Hydra%20The%20ongoing%20quest%20for%20modern%20toolchains%20in%20NetBSD%20-%20Martin%20Huseman%20&%20Joerg%20Sonnenberger.mp4) Taylor R Campbell, The entropic principle: /dev/u?random and NetBSD (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/04.Sunday/05.The%20entropic%20principle:%20dev-u%3frandom%20and%20NetBSD%20-%20Taylor%20R%20Campbell.mp4) Dag-Erling Smørgrav, Securing sensitive & restricted data (https://va.ludost.net/files/eurobsdcon/2014/Rodopi/04.Sunday/06.Securing%20sensitive%20&%20restricted%20data%20-%20Dag-Erling%20Sm%c3%b8rgrav.mp4) Peter Hansteen, Building The Network You Need (https://va.ludost.net/files/eurobsdcon/2014/Pirin/01.Thursday/01.Building%20The%20Network%20You%20Need%20With%20PF%20-%20Peter%20Hansteen.mp4) With PF (https://va.ludost.net/files/eurobsdcon/2014/Pirin/01.Thursday/02.Building%20The%20Network%20You%20Need%20With%20PF%20-%20Peter%20Hansteen.mp4) Stefan Sperling, Subversion for FreeBSD developers (https://va.ludost.net/files/eurobsdcon/2014/Pirin/01.Thursday/03.Subversion%20for%20FreeBSD%20developers%20-%20Stefan%20Sperling.mp4) Peter Hansteen, Transition to (https://va.ludost.net/files/eurobsdcon/2014/Pirin/02.Friday/01.Transition%20to%20OpenBSD%205.6%20-%20Peter%20Hansteen.mp4) OpenBSD 5.6 (https://va.ludost.net/files/eurobsdcon/2014/Pirin/02.Friday/02.Transition%20to%20OpenBSD%205.6%20-%20Peter%20Hansteen.mp4) Ingo Schwarze, Let's make manuals (https://va.ludost.net/files/eurobsdcon/2014/Pirin/02.Friday/03.Let%e2%80%99s%20make%20manuals%20more%20useful%20-%20Ingo%20Schwarze.mp4) more useful (https://va.ludost.net/files/eurobsdcon/2014/Pirin/02.Friday/04.Let%e2%80%99s%20make%20manuals%20more%20useful%20-%20Ingo%20Schwarze.mp4) Francois Tigeot, Improving DragonFly's performance with PostgreSQL (https://va.ludost.net/files/eurobsdcon/2014/Pirin/03.Saturday/01.Improving%20DragonFly%e2%80%99s%20performance%20with%20PostgreSQL%20-%20Francois%20Tigeot.mp4) Justin Cormack, Running Applications on the NetBSD Rump Kernel (https://va.ludost.net/files/eurobsdcon/2014/Pirin/03.Saturday/02.Running%20Applications%20on%20the%20NetBSD%20Rump%20Kernel%20-%20Justin%20Cormack.mp4) Pierre Pronchery, EdgeBSD, a year later (https://va.ludost.net/files/eurobsdcon/2014/Pirin/03.Saturday/04.EdgeBSD,%20a%20year%20later%20-%20%20Pierre%20Pronchery.mp4) Peter Hessler, Using routing domains or tables in a production network (https://va.ludost.net/files/eurobsdcon/2014/Pirin/03.Saturday/05.Using%20routing%20domains%20or%20tables%20in%20a%20production%20network%20-%20%20Peter%20Hessler.mp4) Sean Bruno, QEMU user mode on FreeBSD (https://va.ludost.net/files/eurobsdcon/2014/Pirin/03.Saturday/06.QEMU%20user%20mode%20on%20FreeBSD%20-%20%20Sean%20Bruno.mp4) Kristaps Dzonsons, Bugs Ex Ante (https://va.ludost.net/files/eurobsdcon/2014/Pirin/04.Sunday/01.Bugs%20Ex%20Ante%20-%20Kristaps%20Dzonsons.mp4) Yann Sionneau, Porting NetBSD to the LatticeMico32 open source CPU (https://va.ludost.net/files/eurobsdcon/2014/Pirin/04.Sunday/02.Porting%20NetBSD%20to%20the%20LatticeMico32%20open%20source%20CPU%20-%20Yann%20Sionneau.mp4) Alexander Nasonov, JIT Code Generator for NetBSD (https://va.ludost.net/files/eurobsdcon/2014/Pirin/04.Sunday/03.JIT%20Code%20Generator%20for%20NetBSD%20-%20Alexander%20Nasonov.mp4) Masao Uebayashi, Porting Valgrind to NetBSD and OpenBSD (https://va.ludost.net/files/eurobsdcon/2014/Pirin/04.Sunday/04.Porting%20Valgrind%20to%20NetBSD%20and%20OpenBSD%20-%20Masao%20Uebayashi.mp4) Marc Espie, parallel make, working with legacy code (https://va.ludost.net/files/eurobsdcon/2014/Pirin/04.Sunday/05.parallel%20make:%20working%20with%20legacy%20code%20-%20Marc%20Espie.mp4) Francois Tigeot, Porting the drm-kms graphic drivers to DragonFly (https://va.ludost.net/files/eurobsdcon/2014/Pirin/04.Sunday/06.Porting%20the%20drm-kms%20graphic%20drivers%20to%20DragonFly%20-%20Francois%20Tigeot.mp4) The following talks (from the Vitosha track room) are all currently missing: Jordan Hubbard, FreeBSD, Looking forward to another 10 years (but we have another recording) Theo de Raadt, Randomness, how arc4random has grown since 1998 (but we have another recording) Kris Moore, Snapshots, Replication, and Boot-Environments Kirk McKusick, An Introduction to the Implementation of ZFS John-Mark Gurney, Optimizing GELI Performance Emmanuel Dreyfus, FUSE and beyond, bridging filesystems Lourival Vieira Neto, NPF scripting with Lua Andy Tanenbaum, A Reimplementation of NetBSD Based on a Microkernel Stefano Garzarella, Software segmentation offloading for FreeBSD Ted Unangst, LibreSSL Shawn Webb, Introducing ASLR In FreeBSD Ed Maste, The LLDB Debugger in FreeBSD Philip Guenther, Secure lazy binding *** OpenBSD adopts SipHash (https://www.marc.info/?l=openbsd-tech&m=141614801713457&w=2) Even more DJB crypto somehow finds its way into OpenBSD's base system This time it's SipHash (https://131002.net/siphash/), a family of pseudorandom functions that's resistant to hash bucket flooding attacks while still providing good performance After an initial import (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/siphash.c?rev=1.1&content-type=text/x-cvsweb-markup) and some clever early usage (https://www.marc.info/?l=openbsd-cvs&m=141604896822253&w=2), a few developers agreed that it would be better to use it in a lot more places It will now be used in the filesystem, and the plan is to utilize it to protect all kernel hash functions Some other places (http://www.bsdnow.tv/episodes/2013_12_18-cryptocrystalline) that Bernstein's work can be found in OpenBSD include the ChaCha20-Poly1305 authenticated stream cipher and Curve25519 KEX used in SSH, ChaCha20 used in the RNG, and Ed25519 keys used in signify (http://www.bsdnow.tv/episodes/2014_02_05-time_signatures) and SSH *** FreeBSD 10.1-RELEASE (https://www.freebsd.org/releases/10.1R/announce.html) FreeBSD's release engineering team (http://www.bsdnow.tv/episodes/2013-09-11_engineering_powder_kegs) likes to troll us by uploading new versions just a few hours after we finish recording an episode The first maintenance update for the 10.x branch is out, improving upon a lot of things found in 10.0-RELEASE The vt driver was merged from -CURRENT and can now be enabled with a loader.conf switch (and can even be used on a PlayStation 3) Bhyve has gotten quite a lot of fixes and improvements from its initial debut in 10.0, including boot support for ZFS Lots of new ARM hardware is supported now, including SMP support for most of them A new kernel selection menu was added to the loader, so you can switch between newer and older kernels at boot time 10.1 is the first to support UEFI booting on amd64, which also has serial console support now Lots of third party software (OpenSSH, OpenSSL, Unbound..) and drivers have gotten updates to newer versions It's a worthy update from 10.0, or a good time to try the 10.x branch if you were avoiding the first .0 release, so grab an ISO (http://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/10.1/) or upgrade (https://www.freebsd.org/cgi/man.cgi?query=freebsd-update) today Check the detailed release notes (https://www.freebsd.org/releases/10.1R/relnotes.html) for more information on all the changes Also take a look at some of the known problems (https://www.freebsd.org/releases/10.1R/errata.html#open-issues) to see if (https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/) you'll (https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080599.html) be (https://forums.freebsd.org/threads/10-0-10-1-diocaddrule-operation-not-supported-by-device.49016/) affected (https://www.reddit.com/r/freebsd/comments/2mmzzy/101release_restart_problems_anyone/) by any of them PC-BSD was also updated accordingly (http://wiki.pcbsd.org/index.php/What%27s_New/10.1) with some of their own unique features and changes *** arc4random - Randomization for All Occasions (https://www.youtube.com/watch?v=aWmLWx8ut20) Theo de Raadt gave an updated version of his EuroBSDCon presentation at Hackfest 2014 in Quebec The presentation is mainly about OpenBSD's arc4random function, and outlines the overall poor state of randomization in the 90s and how it has evolved in OpenBSD over time It begins with some interesting history on OpenBSD and how it became a security-focused OS - in 1996, their syslogd got broken into and "suddenly we became interested in security" The talk also touches on how low-level changes can shake up the software ecosystem and third party packages that everyone uses There's some funny history on the name of the function (being called arc4random despite not using RC4 anymore) and an overall status update on various platforms' usage of it Very detailed and informative presentation, and the slides can be found here (http://www.openbsd.org/papers/hackfest2014-arc4random/index.html) A great quote from the beginning: "We consider ourselves a community of (probably rather strange) people who work on software specifically for the purpose of trying to make it better. We take a 'whole-systems' approach: trying to change everything in the ecosystem that's under our control, trying to see if we can make it better. We gain a lot of strength by being able to throw backwards compatibility out the window. So that means that we're able to do research and the minute that we decide that something isn't right, we'll design an alternative for it and push it in. And if it ends up breaking everybody's machines from the previous stage to the next stage, that's fine because we'll end up in a happier place." *** Interview - Justin Cormack - justin@netbsd.org (mailto:justin@netbsd.org) / @justincormack (https://twitter.com/justincormack) NetBSD on Xen, rump kernels, various topics News Roundup The FreeBSD foundation's biggest donation (http://freebsdfoundation.blogspot.com/2014/11/freebsd-foundation-announces-generous.html) The FreeBSD foundation has a new blog post about the largest donation they've ever gotten From the CEO of WhatsApp comes a whopping one million dollars in a single donation It also has some comments from the donor about why they use BSD and why it's important to give back Be sure to donate to the foundation of whatever BSD you use when you can - every little bit helps, especially for OpenBSD (http://www.openbsd.org/donations.html), NetBSD (https://www.netbsd.org/donations/) and DragonFly (http://www.dragonflybsd.org/donations/) who don't have huge companies supporting them regularly like FreeBSD does *** OpenZFS Dev Summit 2014 videos (http://open-zfs.org/wiki/OpenZFS_Developer_Summit) Videos from the recent OpenZFS developer summit are being uploaded, with speakers from different represented platforms and companies Matt Ahrens (http://www.bsdnow.tv/episodes/2014_05_14-bsdcanned_goods), opening keynote (https://www.youtube.com/watch?v=XnTzbisLYzg) Raphael Carvalho, Platform Overview: ZFS on OSv (https://www.youtube.com/watch?v=TJLOBLSRoHE) Brian Behlendorf, Platform Overview: ZFS on Linux (https://www.youtube.com/watch?v=_MVOpMNV7LY) Prakash Surya, Platform Overview: illumos (https://www.youtube.com/watch?v=UtlGt3ag0o0) Xin Li, Platform Overview: FreeBSD (https://www.youtube.com/watch?v=xO0x5_3A1X4) All platforms, Group Q&A Session (https://www.youtube.com/watch?v=t4UlT0RmSCc) Dave Pacheco, Manta (https://www.youtube.com/watch?v=BEoCMpdB8WU) Saso Kiselkov, Compression (https://www.youtube.com/watch?v=TZF92taa_us) George Wilson (http://www.bsdnow.tv/episodes/2013_12_04-zettabytes_for_days), Performance (https://www.youtube.com/watch?v=deJc0EMKrM4) Tim Feldman, Host-Aware SMR (https://www.youtube.com/watch?v=b1yqjV8qemU) Pavel Zakharov, Fast File Cloning (https://www.youtube.com/watch?v=-4c4gsLi1LI) The audio is pretty poor (https://twitter.com/OpenZFS/status/534005125853888512) on all of them unfortunately *** BSDTalk 248 (http://bsdtalk.blogspot.com/2014/11/bsdtalk248-dragonflybsd-with-matthew.html) Our friend Will Backman is still busy getting BSD interviews as well This time he sits down with Matthew Dillon, the lead developer of DragonFly BSD We've never had Dillon on the show, so you'll definitely want to give this one a listen They mainly discuss all the big changes coming in DragonFly's upcoming 4.0 release *** MeetBSD 2014 videos (https://www.meetbsd.com/) The presentations from this year's MeetBSD conference are starting to appear online as well Kirk McKusick (http://www.bsdnow.tv/episodes/2013-10-02_stacks_of_cache), A Narrative History of BSD (https://www.youtube.com/watch?v=DEEr6dT-4uQ) Jordan Hubbard (http://www.bsdnow.tv/episodes/2013_11_27-bridging_the_gap), FreeBSD: The Next 10 Years (https://www.youtube.com/watch?v=Mri66Uz6-8Y) Brendan Gregg, Performance Analysis (https://www.youtube.com/watch?v=uvKMptfXtdo) The slides can be found here (https://www.meetbsd.com/agenda/) *** Feedback/Questions Dominik writes in (http://slexy.org/view/s20PXjp55N) Steven writes in (http://slexy.org/view/s2LwEYT3bA) Florian writes in (http://slexy.org/view/s2ubK8vQVt) Richard writes in (http://slexy.org/view/s216Eq8nFG) Kevin writes in (http://slexy.org/view/s21D2ugDUy) *** Mailing List Gold Contributing without code (https://www.marc.info/?t=141600819500004&r=1&w=2) Compression isn't a CRIME (https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033176.html) Securing web browsers (https://www.marc.info/?t=141616714600001&r=1&w=2) ***

ceo interview guide performance current transition crime tool os networking software whatsapp playstation secure presentation arm how to securing implementation sd tutorials linux iso bernstein randomness unbound hydra cpu fuse dragonfly compression subversion snapshots manta smp replication ssh rng postgresql rump bsd osv kernels npf openstack hostile environment dj b xen freebsd openssl uefi porting performance analysis openssh zfs george wilson randomization openbsd qemu peter hessler 1r pirin brian behlendorf openzfs iscsi hackfest all occasions raadt developing software rc4 netbsd allan jude matthew dillon ixsystems kris moore tarsnap vitosha dave pacheco matt ahrens openbgpd meetbsd bsd now eurobsdcon dragonflybsd

44: Base ISO 100

external bytes vulnerabilities ssl rc4

Play Episode Listen Later Jul 2, 2014 105:04

This time on the show, we'll be sitting down to talk with Craig Rodrigues about Jenkins and the FreeBSD testing infrastructure. Following that, we'll show you how to roll your own OpenBSD ISOs with all the patches already applied... ISO can't wait! This week's news and answers to all your emails, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines pfSense 2.1.4 released (https://blog.pfsense.org/?p=1377) The pfSense team (http://www.bsdnow.tv/episodes/2014_02_19-a_sixth_pfsense) has released 2.1.4, shortly after 2.1.3 - it's mainly a security release Included within are eight security fixes, most of which are pfSense-specific OpenSSL, the WebUI and some packages all need to be patched (and there are instructions on how to do so) It also includes a large number of various other bug fixes Update all your routers! *** DragonflyBSD's pf gets SMP (http://lists.dragonflybsd.org/pipermail/commits/2014-June/270300.html) While we're on the topic of pf... Dragonfly patches their old[er than even FreeBSD's] pf to support multithreading in many areas Stemming from a user's complaint (http://lists.dragonflybsd.org/pipermail/users/2014-June/128664.html), Matthew Dillon did his own work on pf to make it SMP-aware Altering your configuration (http://lists.dragonflybsd.org/pipermail/users/2014-June/128671.html)'s ruleset can also help speed things up, he found When will OpenBSD, the source of pf, finally do the same? *** ChaCha usage and deployment (http://ianix.com/pub/chacha-deployment.html) A while back, we talked to djm (http://www.bsdnow.tv/episodes/2013_12_18-cryptocrystalline) about some cryptography changes in OpenBSD 5.5 and OpenSSH 6.5 This article is sort of an interesting follow-up to that, showing which projects have adopted ChaCha20 OpenSSH offers it as a stream cipher now, OpenBSD uses it for it's random number generator, Google offers it in TLS for Chromium and some of their services and lots of other projects seem to be adopting it Both Google's fork of OpenSSL and LibReSSL have upcoming implementations, while vanilla OpenSSL does not Unfortunately, this article has one mistake: FreeBSD does not use it (https://lists.freebsd.org/pipermail/freebsd-bugs/2013-October/054018.html) - they still use the broken RC4 algorithm *** BSDMag June 2014 issue (http://bsdmag.org/magazine/1864-tls-hardening-june-bsd-magazine-issue) The monthly online BSD magazine releases their newest issue This one includes the following articles: TLS hardening, setting up a package cluster in MidnightBSD, more GIMP tutorials, "saving time and headaches using the robot framework for testing," an interview and an article about the increasing number of security vulnerabilities The free pdf file is available for download as always *** Interview - Craig Rodrigues - rodrigc@freebsd.org (mailto:rodrigc@freebsd.org) FreeBSD's continuous (https://wiki.freebsd.org/Jenkins) testing (https://docs.google.com/presentation/d/1yBiPxS1nKnVwRlAEsYeAOzYdpG5uzXTv1_7i7jwVCfU/edit#slide=id.p) infrastructure (https://jenkins.freebsd.org/jenkins/) Tutorial Creating pre-patched OpenBSD ISOs (http://www.bsdnow.tv/tutorials/stable-iso) News Roundup Preauthenticated decryption considered harmful (http://www.tedunangst.com/flak/post/preauthenticated-decryption-considered-harmful) Responding to a post (https://www.imperialviolet.org/2014/06/27/streamingencryption.html) from Adam Langley, Ted Unangst (http://www.bsdnow.tv/episodes/2014_02_05-time_signatures) talks a little more about how signify and pkg_add handle signatures In the past, the OpenBSD installer would pipe the output of ftp straight to tar, but then verify the SHA256 at the end - this had the advantage of not requiring any extra disk space, but raised some security concerns With signify, now everything is fully downloaded and verified before tar is even invoked The pkg_add utility works a little bit differently, but it's also been improved in this area - details in the post Be sure to also read the original post from Adam, lots of good information *** FreeBSD 9.3-RC2 is out (https://lists.freebsd.org/pipermail/freebsd-stable/2014-June/079092.html) As the -RELEASE inches closer, release candidate 2 is out and ready for testing Since the last one, it's got some fixes for NIC drivers, the latest file and libmagic security fixes, some serial port workarounds and various other small things The updated bsdconfig will use pkgng style packages now too A lesser known fact: there are also premade virtual machine images you can use too *** pkgsrcCon 2014 wrap-up (http://saveosx.org/pkgsrcCon/) In what may be the first real pkgsrcCon article we've ever had! Includes wrap-up discussion about the event, the talks, the speakers themselves, what they use pkgsrc for, the hackathon and basically the whole event Unfortunately no recordings to be found... *** PostgreSQL FreeBSD performance and scalability (https://kib.kiev.ua/kib/pgsql_perf.pdf) FreeBSD developer kib@ writes a report on PostgreSQL on FreeBSD, and how it scales On his monster 40-core box with 1TB of RAM, he runs lots of benchmarks and posts the findings Lots of technical details if you're interested in getting the best performance out of your hardware It also includes specific kernel options he used and the rest of the configuration If you don't want to open the pdf file, you can use this link (https://docs.google.com/viewer?url=https%3A%2F%2Fkib.kiev.ua%2Fkib%2Fpgsql_perf.pdf) too *** Feedback/Questions James writes in (http://slexy.org/view/s24pFjUPe4) Klemen writes in (http://slexy.org/view/s21OogIgTu) John writes in (http://slexy.org/view/s21rLcemNN) Brad writes in (http://slexy.org/view/s203Qsx6CZ) Adam writes in (http://slexy.org/view/s2eBj0FfSL) ***

google interview guide performance security testing magazine cd dvd responding base ram includes jenkins nic how to sd patch stable tutorials applied databases iso pf sql dragonfly encryption scalability firewalls ssl cha cha hardening cdr tls hardened mysql chromium gimp smp postgresql signify bsd 1tb freebsd openssl gcm openssh decryption openbsd pfsense rc2 web ui freenas multithreading sha256 rc4 netbsd allan jude matthew dillon ixsystems kris moore tarsnap midnightbsd bsd now dragonflybsd

7MS #7: External Vulnerabilities that Byte (audio)

7 Minute Security

Play Episode Listen Later Mar 15, 2014 7:15

Episode lucky #7!!! In this episode I talk about external network vulnerabilities that we see in many of our assessments – some of which are pretty easy to clear up. Download: Episode 7: External Vulnerabilities that Byte (audio) Show notes: RC4 – a risk that we find just about anywhere SSL is used, but in…

22: Journaled News-Updates

Play Episode Listen Later Jan 29, 2014 90:12

This time on the show, we'll be talking with George Neville-Neil about the brand new FreeBSD Journal and what it's all about. After that, we've got a tutorial on how to track the -stable and -current branches of OpenBSD. Answers to all your BSD questions and the latest headlines, only on BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD quarterly status report (https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/077085.html) Gabor Pali sent out the October-December 2013 status report to get everyone up to date on what's going on The report contains 37 entries and is very very long... various reports from all the different teams under the FreeBSD umbrella, probably too many to even list in the show notes Lots of work going on in the ARM world, EC2/Xen and Google Compute Engine are also improving Secure boot support hopefully coming by mid-year (www.itwire.com/business-it-news/open-source/62855-freebsd-to-support-secure-boot-by-mid-year) There's quite a bit going on in the FreeBSD world, many projects happening at the same time *** n2k14 OpenBSD Hackathon Report (http://undeadly.org/cgi?action=article&sid=20140124142027) Recently, OpenBSD held one of their hackathons (http://www.openbsd.org/hackathons.html) in New Zealand 15 developers gathered there to sit in a room and write code for a few days Philip Guenther brings back a nice report of the event If you've been watching the -current CVS logs, you've seen the flood of commits just from this event alone Fixes with threading, Linux compat, ACPI, and various other things - some will make it into 5.5 and others need more testing Another report from Theo (http://undeadly.org/cgi?action=article&sid=20140127083112) details his work Updates to the random subsystem, some work-in-progress pf fixes, suspend/resume fixes and more signing stuff *** Four new NetBSD releases (https://blog.netbsd.org/tnf/entry/netbsd_6_1_3_netbsd) NetBSD released versions 6.1.3, 6.0.4, 5.2.2 and 5.1.4 These updates include lots of bug fixes and some security updates, not focused on new features You can upgrade depending on what branch you're currently on Confused about the different branches? See this graph. (https://www.netbsd.org/releases/release-map.html#graph1) *** The future of open source ZFS development (http://sites.ieee.org/scv-cs/archives/openzfs-future-open-source-zfs-development) On February 11, 2014, Matt Ahrens will be giving a presentation about ZFS The talk will be about the future of ZFS and the open source development since Oracle closed the code It's in San Jose, California - go if you can! *** Interview - George Neville-Neil - gnn@freebsd.org (mailto:gnn@freebsd.org) / @gvnn3 (https://twitter.com/gvnn3) The FreeBSD Journal (http://freebsdjournal.com/) Tutorial Tracking -STABLE and -CURRENT (OpenBSD) (http://www.bsdnow.tv/tutorials/stable-current-obsd) News Roundup pfSense news and 2.1.1 snapshots (https://doc.pfsense.org/index.php/2.1.1_New_Features_and_Changes) pfSense has some snapshots available for the upcoming 2.1.1 release They include FreeBSD security fixes as well as some other updates There are recordings posted (https://blog.pfsense.org/?p=1198) of some of the previous hangouts Unfortunately they're only for subscribers, so you'll have to wait until next month when we have Chris on the show to talk about pfSense! *** FreeBSD on Google Compute Engine (https://groups.google.com/forum/#!msg/gce-discussion/YWoa3Aa_49U/FYAg9oiRlLUJ) Recently we mentioned some posts about getting OpenBSD to run on GCE, here's the FreeBSD version Nice big fat warning: "The team has put together a best-effort posting that will get most, if not all, of you up and running. That being said, we need to remind you that FreeBSD is being supported on Google Compute Engine by the community. The instructions are being provided as-is and without warranty." Their instructions are a little too Linuxy (assuming wget, etc.) for our taste, someone should probably get it updated! Other than that it's a pretty good set of instructions on how to get up and running *** Dragonfly ACPI update (http://www.shiningsilence.com/dbsdlog/2014/01/22/13225.html) Sascha Wildner committed some new ACPI code (http://lists.dragonflybsd.org/pipermail/commits/2014-January/199071.html) There's also a "heads up" to update your BIOS (http://lists.dragonflybsd.org/pipermail/users/2014-January/090504.html) if you experience problems Check the mailing list post for all the details *** PCBSD weekly digest (http://blog.pcbsd.org/2014/01/pc-bsd-weekly-feature-digest-6/) 10.0-RC4 users need to upgrade all their packages for 10.0-RC5 PBIs needed to be rebuilt.. actually everything did Help test GNOME 3 so we can get it in the official ports tree By the way, I think Kris has an announcement - PCBSD 10.0 is out! *** Feedback/Questions Tony writes in (http://slexy.org/view/s21ZlfOdTt) Jeff writes in (http://slexy.org/view/s2BFZ68Na5) Remy writes in (http://slexy.org/view/s20epArsQI) Nils writes in (http://slexy.org/view/s213CoNvLt) Solomon writes in (http://slexy.org/view/s21XWnThNS) ***

california new york city interview guide news new zealand current conference journal oracle upgrade convention arm san jose branch how to sd stable tutorials linux cvs binary gnome hackathons bios news updates ffs bsd new features efi freebsd uefi ufs zfs secure boot openbsd gce pfsense gnn openzfs rc4 netbsd allan jude ixsystems kris moore acpi matt ahrens george neville neil bsd now dragonflybsd freebsd journal

21: Tendresse for Ten

Play Episode Listen Later Jan 22, 2014 107:05

This time on the show, we've got some great news for OpenBSD, as well as the scoop on FreeBSD 10.0-RELEASE - yes it's finally here! We're gonna talk to Colin Percival about running FreeBSD 10 on EC2 and lots of other interesting stuff. After that, we'll be showing you how to do some bandwidth monitoring and network performance testing in a combo tutorial. We've got a round of your questions and the latest news, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD 10.0-RELEASE is out (https://www.freebsd.org/releases/10.0R/announce.html) The long awaited, giant release of FreeBSD is now official and ready to be downloaded (http://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/10.0/) One of the biggest releases in FreeBSD history, with tons of new updates Some features include: LDNS/Unbound replacing BIND, Clang by default (no GCC anymore), native Raspberry Pi support and other ARM improvements, bhyve, hyper-v support, AMD KMS, VirtIO, Xen PVHVM in GENERIC, lots of driver updates, ZFS on root in the installer, SMP patches to pf that drastically improve performance, Netmap support, pkgng by default, wireless stack improvements, a new iSCSI stack, FUSE in the base system... the list goes on and on (https://www.freebsd.org/releases/10.0R/relnotes.html) Start up your freebsd-update or do a source-based upgrade *** OpenSSH 6.5 CFT (https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031987.html) Our buddy Damien Miller (http://www.bsdnow.tv/episodes/2013_12_18-cryptocrystalline) announced a Call For Testing for OpenSSH 6.5 Huge, huge release, focused on new features rather than bugfixes (but it includes those too) New ciphers, new key formats, new config options, see the mailing list for all the details Should be in OpenBSD 5.5 in May, look forward to it - but also help test on other platforms! *** DIY NAS story, FreeNAS 9.2.1-BETA (http://blog.brianmoses.net/2014/01/diy-nas-2014-edition.html) Another new blog post about FreeNAS! Instead of updating the older tutorials, the author started fresh and wrote a new one for 2014 "I did briefly consider suggesting nas4free for the EconoNAS blog, since it's essentially a fork off the FreeNAS tree but may run better on slower hardware, but ultimately I couldn't recommend anything other than FreeNAS" Really long article with lots of nice details about his setup, why you might want a NAS, etc. Speaking of FreeNAS, they released 9.2.1-BETA (http://www.freenas.org/whats-new/2014/01/freenas-9-2-1-beta-now-ready-for-download.html) with lots of bugfixes *** OpenBSD needed funding for electricity.. and they got it (https://news.ycombinator.com/item?id=7069889) Briefly mentioned at the end of last week's show, but has blown up over the internet since OpenBSD in the headlines of major tech news sites: slashdot, zdnet, the register, hacker news, reddit, twitter.. thousands of comments They needed about $20,000 to cover electric costs for the server rack in Theo's basement (http://www.openbsd.org/images/rack2009.jpg) Lots of positive reaction from the community helping out so far, and it appears they have reached their goal (http://www.openbsdfoundation.org/campaign2104.html) and got $100,000 in donations From Bob Beck: "we have in one week gone from being in a dire situation to having a commitment of approximately $100,000 in donations to the foundation" This is a shining example of the BSD community coming together, and even the Linux people realizing how critical BSD is to the world at large *** Interview - Colin Percival - cperciva@freebsd.org (mailto:cperciva@freebsd.org) / @cperciva (https://twitter.com/cperciva) FreeBSD on Amazon EC2 (http://www.daemonology.net/freebsd-on-ec2/), backups with Tarsnap (https://www.tarsnap.com/), 10.0-RELEASE, various topics Tutorial Bandwidth monitoring and testing (http://www.bsdnow.tv/tutorials/vnstat-iperf) News Roundup pfSense talk at Tokyo FreeBSD Benkyoukai (https://blog.pfsense.org/?p=1176) Isaac Levy will be presenting "pfSense Practical Experiences: from home routers, to High-Availability Datacenter Deployments" He's also going to be looking for help to translate the pfSense documentation into Japanese The event is on February 17, 2014 if you're in the Tokyo area *** m0n0wall 1.8.1 released (http://m0n0.ch/wall/downloads.php) For those who don't know, m0n0wall is an older BSD-based firewall OS that's mostly focused on embedded applications pfSense was forked from it in 2004, and has a lot more active development now They switched to FreeBSD 8.4 for this new version Full list of updates in the changelog This version requires at least 128MB RAM and a disk/CF size of 32MB or more, oh no! *** Ansible and PF, plus NTP (http://blather.michaelwlucas.com/archives/1933) Another blog post from our buddy Michael Lucas (http://www.bsdnow.tv/episodes/2013_11_06-year_of_the_bsd_desktop) There've been some NTP amplification attacks recently (https://www.freebsd.org/security/advisories/FreeBSD-SA-14:02.ntpd.asc) in the news The post describes how he configured ntpd on a lot of servers without a lot of work He leverages pf and ansible for the configuration OpenNTPD is, not surprisingly, unaffected - use it *** ruBSD videos online (http://undeadly.org/cgi?action=article&sid=20140115054839) Just a quick followup from a few weeks ago Theo and Henning's talks from ruBSD are now available for download There's also a nice interview with Theo *** PCBSD weekly digest (http://blog.pcbsd.org/2014/01/pc-bsd-weekly-feature-digest-5/) 10.0-RC4 images are available Wine PBI is now available for 10 9.2 systems will now be able to upgrade to version 10 and keep their PBI library *** Feedback/Questions Sha'ul writes in (http://slexy.org/view/s2WQXwMASZ) Kjell-Aleksander writes in (http://slexy.org/view/s2H0FURAtZ) Mike writes in (http://slexy.org/view/s21eKKPgqh) Charlie writes in (and gets a reply) (http://slexy.org/view/s21UMLnV0G) Kevin writes in (http://slexy.org/view/s2SuazcfoR) ***

amazon interview guide speaking performance network tokyo os speed cloud vulnerability beta nas backup arm how to sd tutorials aws dropbox linux upload vm cf bind henning pf fuse generic raspberry pi backups gcc smp offsite encrypted ntp bsd ansible virtual machines throughput cft xen ec2 freebsd pbi clang tendresse instance openssh zfs amazon ec2 openbsd michael lucas crashplan hypervisor pfsense vfs freenas iscsi in the clouds rc4 netbsd 32mb allan jude ixsystems kris moore tarsnap bsd now dragonflybsd

16: Cryptocrystalline

Play Episode Listen Later Dec 18, 2013 110:21

This time on the show, we'll be showing you how to do a fully-encrypted installation of FreeBSD and OpenBSD. We also have an interview with Damien Miller - one of the lead developers of OpenSSH - about some recent crypto changes in the project. If you're into data security, today's the show for you. The latest news and all your burning questions answered, right here on BSD Now - the place to B.. SD. This episode was brought to you by Headlines Secure communications with OpenBSD and OpenVPN (http://johnchapin.boostrot.net/blog/2013/12/07/secure-comms-with-openbsd-and-openvpn-part-1/) Starting off today's theme of encryption... A new blog series about combining OpenBSD and OpenVPN to secure your internet traffic Part 1 covers installing OpenBSD with full disk encryption (which we'll be doing later on in the show) Part 2 covers the initial setup of OpenVPN certificates and keys Parts 3 and 4 are the OpenVPN server and client configuration Part 5 is some updates and closing remarks *** FreeBSD Foundation Newsletter (https://www.freebsdfoundation.org/press/2013Dec-newsletter) The December 2013 semi-annual newsletter was sent out from the foundation In the newsletter you will find the president's letter, articles on the current development projects they sponsor and reports from all the conferences and summits they sponsored The president's letter alone is worth the read, really amazing Really long, with lots of details and stories from the conferences and projects *** Use of NetBSD with Marvell Kirkwood Processors (http://evertiq.com/design/33394) Article that gives a brief history of NetBSD and how to use it on an IP-Plug computer The IP-Plug is a "multi-functional mini-server was developed by Promwad engineers by the order of AK-Systems. It is designed for solving a wide range of tasks in IP networks and can perform the functions of a computer or a server. The IP-Plug is powered from a 220V network and has low power consumption, as well as a small size (which can be compared to the size of a mobile phone charger)." Really cool little NetBSD ARM project with lots of graphs, pictures and details *** Experimenting with zero-copy network IO (http://adrianchadd.blogspot.com/2013/12/experimenting-with-zero-copy-network-io.html) Long blog post from Adrian Chadd about zero-copy network IO on FreeBSD Discusses the different OS' implementations and options He's able to get 35 gbit/sec out of 70,000 active TCP sockets, but isn't stopping there Tons of details, check the full post *** Interview - Damien Miller - djm@openbsd.org (mailto:djm@openbsd.org) / @damienmiller (https://twitter.com/damienmiller) Cryptography in OpenBSD and OpenSSH Tutorial Full disk encryption in FreeBSD & OpenBSD (http://www.bsdnow.tv/tutorials/fde) News Roundup OpenZFS office hours (https://www.youtube.com/watch?v=wWmVW2R_uz8) Our buddy George Wilson (http://www.bsdnow.tv/episodes/2013_12_04-zettabytes_for_days) sat down to take some ZFS questions from the community You can see more info about it here (http://open-zfs.org/wiki/OpenZFS_Office_Hours) *** License summaries in pkgng (http://www.shiningsilence.com/dbsdlog/2013/12/09/12934.html) A discussion between Justin Sherill (http://www.bsdnow.tv/episodes/2013_11_13-the_gateway_drug) and some NYCBUG guys about license frameworks in pkgng Similar to pkgsrc's "ACCEPTABLE_LICENSES" setting, pkgng could let the user decide which software licenses he wants to allow Maybe we could get a "pkg licenses" command to display the license of all installed packages Ok bapt, do it *** The FreeBSD challenge continues (http://thelinuxcauldron.com/2013/12/08/freebsd-challenge/) Checking in with our buddy from the Linux foundation... The switching from Linux to FreeBSD blog series continues for his month-long trial Follow up from last week: "As a matter of fact, I did check out PC-BSD, and wanted the challenge. Call me addicted to pain and suffering, but the pride and accomplishment you feel from diving into FreeBSD is quite rewarding." Since we last mentioned it, he's decided to go from a VM to real hardware, got all of his common software installed, experimented with the Linux emulation, set up virtualbox, learned about slices/partitions/disk management, found BSD alternatives to his regularly-used commands and lots more *** Ports gets a stable branch (https://svnweb.freebsd.org/ports?view=revision&revision=336615) For the first time ever, FreeBSD's ports tree will have a maintained "stable" branch This is similar to how pkgsrc does things, with a rolling release for updated software and stable branch for only security and big fixes All commits to this branch require approval of portmgr, looks like it'll start in 2014Q1 *** Feedback/Questions John writes in (http://slexy.org/view/s2iRV1tOzB) Spencer writes in (http://slexy.org/view/s21gAR5lgf) Campbell writes in (http://slexy.org/view/s203iOnFh1) Sha'ul writes in (http://slexy.org/view/s2yUqj3vKW) Clint writes in (http://slexy.org/view/s2egcTPBXH) ***

starting interview guide foundation keys security os crypto salt mac checking newsletter ip tap arm tunnel how to sd io passwords tutorials linux vpn vm installation experimenting tun ports hash rsa encryption office hours dsa decode ssl vps ecc aes cryptography cipher ssh tcp dj m bsd freebsd encode openssh zfs md5 george wilson openvpn openbsd sftp 220v base64 openzfs sha256 ecdsa fde rc4 bcrypt netbsd hmac allan jude ixsystems kris moore bsd now pc bsd dragonflybsd freebsd journal

14: Zettabytes for Days